Cloud SQL apenas com IP privado: o Bom, o ruim e o feio

Os dados são a nova mina de ouro de todas as empresas, e este tesouro deve ser mantido seguro e protegido . É por isso que, por muitos anos, uma boa prática comum de qualquer administrador de banco de dados é remover todo o acesso público ao banco de dados , especialmente o IP público e para conceder acesso apenas do IP privado.
Esta regra “dourada” é aplicada por todos equipes de segurança e exigem o mesmo padrão para qualquer implantação de nuvem.

O serviço Cloud SQL , o serviço de banco de dados gerenciado no Google Cloud, permite que você:

Graças a esses recursos, você pode aplicar os requisitos da equipe de segurança .

Mas, é um problema quando trabalhamos da dia a dia não ter IP público nas instâncias do Cloud SQL?

Vamos verificar isso em três casos de uso:

  1. Compute Engine conectividade
  2. Serviços sem servidor conectividade
  3. Ambiente local conectividade

Binário de proxy do Cloud SQL

Antes de nos aprofundar nos casos de uso, gostaria de fazer um rápido enfoque no recurso principal de Proxy do Cloud SQL

  • Este binário abre um túnel criptografado de ponta a ponta e seguro . Em resumo, mesmo se seu banco de dados não tiver certificado SSL, os dados são criptografados em trânsito.
  • Antes de abrir o túnel, o binário verifica o API de serviço IAM se a credencial atual estiver autorizada a acessar a instância do Cloud SQL . Esta é uma camada adicional de segurança, além da autenticação de banco de dados padrão por usuário / senha.
  • O túnel pode ser aberto em uma porta local (modo de conexão TCP) ou em um soquete Unix (não é possível em Ambiente Windows)

O bom: conectividade do Compute Engine

Porque esse “padrão de segurança de IP privado” foi criado para arquitetura legada (ou seja, VM local e rede privada), a restrição se encaixa perfeitamente no mundo IaaS (ou seja, Compute Engine + VPC).
Menciono o Compute Engine, mas também é verdade com todos os serviços que usam instâncias do Compute Engine: Dataflow, Dataproc, GKE,…

  • Implante sua VM no mesmo VPC que o IP privado das instâncias do Cloud SQL.
  • Use o IP privado da instância do Cloud SQL para acessá-lo a partir do seu aplicativo, que é implantado no Compute Engine.
  • Abra as regras de firewall necessárias se necessário.

Isso é “bom” !!

Observação: o uso do proxy do Cloud SQL neste caso pode ser discutido. Ele adiciona uma camada de segurança adicional verificando a autorização em relação aos serviços IAM e a comunicação criptografada, mas também adiciona latência adicional e ponto potencial de falha. É uma questão de compensações.

O ruim: conectividade de serviços sem servidor

Quando estamos usando o “novo mundo” da nuvem, o paradigma sem servidor , as coisas não são tão boas com o Cloud Run , Cloud Functions e App Engine .

Na verdade, quando você implanta em plataformas sem servidor , por definição, você não precisa gerenciar os servidores e, portanto, o os servidores não estão em seu VPC . E, portanto, não é possível, pronto para uso, acessar o IP privado do Cloud SQL conectado ao VPC do seu projeto.

Se você se aprofundar em Cloud Run , Cloud Functions e App Engine , você pode encontrar como conectar sua instância do Cloud SQL ao serviço sem servidor graças a um recurso integrado:

Adicione o nome da conexão da instância do Cloud SQL à sua configuração e automaticamente um túnel é criado com o início da instância.

Na realidade, é uma conexão aberta pelo binário do Cloud SQL proxy no modo de soquete Unix . Mas esta solução funciona apenas se a instância do Cloud SQL tiver um IP público .
No caso de apenas IP privado , e mesmo se um o modo de conexão de IP privado existe com o proxy do Cloud SQL , ele não funciona!

Conecte os serviços sem servidor ao IP privado do Cloud SQL

Esperançosamente, existe uma solução. Você pode clicar em private IP nos tutoriais de conexão do Cloud SQL para isso ( exemplo para Cloud Functions ).

Em resumo, você precisa:

  • Criar um conector VPC sem servidor , na mesma região do serviço sem servidor. E, é claro, conectado ao mesmo VPC que sua instância do Cloud SQL.
    Observe que hoje todas as regiões são compatíveis com o conector VPC sem servidor, mas não foi o caso por um tempo.
  • Implante seu serviço sem servidor com este conector VPC , compatível com Cloud Run , Cloud Functions e App Engine
  • Em seu aplicativo, use o IP privado do Cloud SQL (em vez da conexão de soquete Unix)

Esta solução funciona, mas introduz um novo elemento de rede , um custo adicional e um possível novo ponto de falha na cadeia de conectividade.

Isso é “ruim” !!

O feio: conectividade do ambiente local

Quando você deseja consultar seu banco de dados , em algum momento da produção, por meio de seu IDE de banco de dados preferido instalado em seu computador , você precisa conectar seu ambiente local à nuvem Instância SQL e, portanto, por meio do IP privado.

Como a instância do Cloud SQL não tem um IP público, você não pode alcançá-la diretamente do a internet (seu computador) e Cloud SQL proxy também não . A solução aqui é criar um bastion host : uma VM de ponte entre o mundo externo (IP público) e o mundo interno (IP privado).

Para isso, crie uma pequena instância do Compute Engine , um f1-micro por exemplo ( muito acessível, menos de US $ 5 por mês), para conseguir isso.

Requisito da equipe de segurança : Todas as VMs não devem ter um IP público. Claro, regras de firewall 0.0.0.0/0 não são permitidas, especialmente na porta 22 (ssh)

Host Bastion sem IP público

Novas restrições para lidar ! Mas é consistente: se você fechar a porta, é para deixar a janela abrir !!
Então, sem problemas, o Google Cloud oferece uma solução excelente e fácil para isso: Identity-Aware Proxy (IAP)

Com IAP, você só precisa conceder um Google Cloud IAP Intervalo de IP

35.235.240.0/20 para acessar seu Compute Engine na porta 22 em suas regras de firewall . E, portanto, não é necessário abrir 0.0.0.0/0 (toda a Internet) para alcance a porta ssh do Compute Engine!

Em seguida, use o SDK do gcloud para se conectar ao seu Bastion Host Compute Instância do motor
gcloud compute ssh --zone=
E a mágica acontece! O gcloud SDK detecta automaticamente a falta de IP público do Compute Engine instância e abre automaticamente um túnel IAP para conectar em SSH a instância . É invisível para o usuário!

A credencial (aqui, a conta do usuário, mas pode ser uma conta de serviço) precisa ter permissão suficiente para criar um túnel IAP . As funções são roles / iap.tunnelResourceAccessor para criar o túnel e roles / compute.instanceAdmin.v1 para acessar a VM

Agora, você é conectado ao Bastion Host, mas ainda não conectou a instância do Cloud SQL

Tunelamento IAP, encaminhamento de porta SSL e Proxy Cloud SQL

E aí, a parte “feio” começa . Temos duas coisas a alcançar

  1. Conecte o host bastião à instância do Cloud SQL via o IP privado
  2. Encaminhe a solicitação de conexão do banco de dados do ambiente local para o host bastião para alcance a instância do Cloud SQL por meio do túnel do Cloud SQL Proxy

1. Conectividade da instância do Cloud SQL do Bastion Host
Para isso, precisamos do proxy Cloud SQL para abrir um túnel entre o Bastion Host e a instância do Cloud SQL.

Primeiro problema: Porque você não tem um IP público, você não consegue acessar a internet!
Você pode escolher criar um Cloud NAT em seu host bastião Compute intervalo de IP da instância. Mas, a maneira mais fácil é baixá-lo em seu ambiente local e depois para copie-o no host bastião . Para fazer isso, você pode usar este comando.
gcloud compute scp /local/path/to/cloud_sql_proxy :/tmp
Como você pode abrir uma conexão SSH por meio do IAP, também pode usar scp protocolo (cópia ssh) para copiar arquivos através do IAP! Mágico !!

Ótimo, agora você tem o binário na instância do Compute Engine do host bastião e deseja testar se a conexão funciona . Você pode executar os comandos

#Connect to bastion host
gcloud compute ssh --zone=
#Change the permission of the Cloud SQL proxy binary (do it only once)
chmod +x /tmp/cloud_sql_proxy
#Connect to your Cloud SQL instance
/tmp/cloud_sql_proxy --instances==tcp:3306

Você pode encontrar o connection_name na página da sua instância do Cloud SQL

Segundo problema: não funciona! E há muitos motivos!

  • Se você criou seu Bastion Host Compute Engine com os parâmetros padrão , especialmente a parte do escopo da API, você não tem escopo suficiente para alcançar as APIs do Cloud SQL.
    Para resolver isso, você precisa parar seu Compute Engine , editá-lo e personalize os escopos
  • Quando o túnel do Cloud SQL é criado, as permissões IAM das credenciais atuais (aqui as credenciais do Compute Engine ) são verificadas . A conta de serviço do Compute Engine não pode ter permissões suficientes.
    Para resolver isso, certifique-se de que as funções mínimas sejam concedidas na conta de serviço: Cloud SQL client, Cloud SQL editor ou Cloud SQL admin
    A conta de serviço padrão do Compute Engine tem funções / editor Função. Muito amplo, mas o suficiente para nosso caso de uso.
  • Finalmente, por padrão, quando você solicita uma API do Google Cloud, o DNS público é solicitado . Ocorre quando o proxy do Cloud SQL solicita a API Cloud SQL ou o serviço IAM quando o túnel é criado. E, como o host bastião Compute Engine não tem um IP público, ele pode acessar a Internet e o googleapis.com DNS público.
    Para resolver isso, você tem 2 soluções. configure um Cloud NAT conforme proposto antes ou use um recurso complicado do Google Cloud VPC: Permitir a sub-rede atual do Compute Engine atual para chamar o

    googleapis.com DNS . Para fazer isso, vá para seu VPC, selecione a sub-rede correta e edite-a. Em seguida, selecione On para o botão de opção Acesso privado do Google e salve.

Ótimo !! Agora, o host bastião Compute Engine pode usar o proxy do Cloud SQL para abrir um túnel da porta local 3306 para a instância do Cloud SQL, por meio do IP privado.

2. Encaminhe o tráfego do ambiente local para a instância do Cloud SQL
Para conseguir isso, não usaremos o gcloud ssh recurso integrado, mas uma solução alternativa . Além de uma conexão direta com ssh para instâncias de computação, gcloud SDK permite criar um túnel em qualquer porta .

Então, vamos criar um túnel na porta 22 do host bastião instância do Compute Engine e defina uma porta local arbitrária (aqui 4226)

gcloud compute start-iap-tunnel  22 \
--zone= --local-host-port=localhost:4226

Ótimo, um túnel é aberto e podemos usá-lo para conectar a instância do Compute Engine do host bastião em ssh.

Deixe o túnel aberto e em execução em um terminal e abra um novo.

Agora, vamos conectar em ssh para ele . Em um comando, você alcançará várias coisas obrigatórias para estabelecer a conexão :

  • Crie um encaminhamento de porta de seu ambiente local para o host bastião mecanismo de computação
    -L 3306:localhost:3306
    “minha porta local 3306 é encaminhado na VM de destino (aqui, o host bastião) para alcançar a porta 3306 aberto no localhost (ou seja, a VM de destino) ”
  • Reutilize a chave ssh criada automaticamente pelo Google durante o primeiro ssh conexão com o host bastião Compute Engine (ou scp). Esta chave privada é armazenada no diretório home do usuário atual ~/.ssh
    -i ~/.ssh/google_compute_engine
  • Abra um ssh conexão através do túnel IAP existente no ambiente localhost e encaminhamento do ssh tráfego da porta local 4226
    -p 4226 localhost
  • Quando conectado ao host bastião Compute Engine, você deseja executar o proxy do Cloud SQL para criar o túnel para a instância do Cloud SQL , na porta 3306. Para isso, execute o comando que você deseja no remoto (o host bastião) após um --
    -- /tmp/cloud_sql_proxy instances==tcp:3306

E coloque tudo isso junto

ssh -L 3306:localhost:3306 \
-i ~/.ssh/google_compute_engine \
-p 4226 localhost \
-- /tmp/cloud_sql_proxy instances==tcp:3306

Agora, você tem! Use seu IDE de banco de dados favorito, conecte-o em localhost:3306 e faça login em seu banco de dados com o usuário / senha.

Uau !! Tudo isso para estar em conformidade com um padrão de segurança ! Aqui está um esquema do que construímos

Isso é “ugly” !!

Efeito colateral adicional

Usando O Cloud SQL com um IP privado apenas adiciona ressalvas . Na verdade, um peering é criado entre o VPC do projeto e a rede Cloud SQL (gerenciada pelo Google Cloud).
E o peering vem com 2 limitações:

Este último ponto é muito importante e pode ser um bloqueador se você quiser acessar a instância do banco de dados de outro projeto . Na verdade, a partir do VPC de outro projeto, você gostaria de criar um peering com o projeto que tem a instância do Cloud SQL para alcançar, por meio do IP privado.

Mas, por causa da limitação de transitividade, você pode t: o IP privado do Cloud SQL não é visto do VPC do outro projeto.
A solução aqui é criar uma VPN para fazer peering de 2 VPCs .
Isso é euh… “mais feio” ??

Um efeito colateral adicional é a incapacidade dos aplicativos do App Script de usarem instâncias do Cloud SQL se nenhum IP público for definido.

O padrão de segurança “inteligente” é importante

A segurança é importante e os padrões existentes para bancos de dados funciona muito bem … no mundo legado.
Agora, com o Cloud SQL e o proxy do Cloud SQL, camadas de segurança adicionais existem e anulam os padrões antigos.

Qual é o problema de ter um IP público se nenhum intervalo de IP for permitido para se conectar a ele ?

É a definição de uma regra de firewall no mundo legado, isn t é? Negar que todos os IPs acessem este intervalo / IP onde estão hospedados meus bancos de dados

Preocupação da equipe de segurança : Como ter certeza de que nenhum intervalo de IP é permitido?

Esta pergunta é legítima e é por isso que você pode aplicar uma política da organização ( Restringir Redes autorizadas em instâncias do Cloud SQL ) para impedir a adição de intervalo de IP público em instâncias do Cloud SQL , e isso, em toda a empresa.

Eventualmente, permitir um IP público em instâncias do Cloud SQL evita muitas soluções alternativas e designs estranhos para lidar e sem diminuir o nível de segurança.
Além disso, o túnel criado é criptografado e garante um alto nível de segurança e confidencialidade.

A nuvem muda os paradigmas (consulte Beyond Corp ) e o padrão de segurança precisa ser atualizado para estar em conformidade com eles.
Os padrões de segurança inteligentes são melhores do que os padrões de segurança legados!

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *