Visão geral do acesso a serviços particulares no Cloud SQL

Este documento explica como o acesso a serviços particulares oferece conectividade de IP particular para o Cloud SQL e aborda a alocação de endereços IP, considerações sobre rede e segurança e conectividade de várias VPCs.

O acesso a serviços particulares é implementado como uma conexão de peering de rede VPC entre a rede VPC e a rede VPC do provedor de serviços em que a instância do Cloud SQL reside. Essa conexão de rede particular permite que as instâncias de VM na sua rede VPC e os Google Cloud serviços que você acessa se comuniquem exclusivamente usando endereços IP particulares com a instância do Cloud SQL. As instâncias de VM não precisam de acesso à Internet ou de endereços IP externo para alcançar serviços disponíveis por meio do acesso a serviços particulares.

Endereços IP

Para usar o acesso a serviços particulares em uma rede VPC, é necessário que um ou mais intervalos de endereços IP estejam disponíveis para a VPC (para mais informações sobre endereços IP, consulte Endereços IP). Esses intervalos precisam ser grandes o suficiente para o Cloud SQL e outros Google Cloud serviços gerenciados que você planeja usar. O Cloud SQL e outros Google Cloud serviços exigem blocos de IP dedicados dos intervalos alocados. O tamanho mínimo para esses blocos é de 256 endereços (comprimento do prefixo /24), embora o tamanho recomendado seja de 65.536 endereços (comprimento do prefixo /16).

Para criar instâncias em várias regiões ou para diferentes tipos de banco de dados, é preciso ter um intervalo mínimo /24 de endereços IP disponíveis para cada região ou tipo de banco de dados. Isso inclui outros aplicativos, como Filestore ou Memorystore.

Ao configurar o acesso a serviços particulares, você pode selecionar um intervalo existente ou alocar um novo. Se você permitir que Google Cloud alocar o intervalo para você, conforme descrito na próxima seção, então Google Cloud aloca um intervalo de comprimento de prefixo /24 com o nome default-ip-range.

Quando usar intervalos CIDR separados

Como o Cloud SQL usa intervalos CIDR /24 como uma unidade de intervalo de IP, há várias condições em que intervalos /24 separados são necessários.

  • Separação regional: se você criar duas instâncias do Cloud SQL em duas regiões separadas, será necessário alocar pelo menos dois intervalos CIDR /24 separados. Cada unidade de intervalo de IP só pode ser usada para instâncias do Cloud SQL em uma única região.
  • Separação forçada da arquitetura de rede: as instâncias criadas usando a flag --enforce-new-sql-network-architecture (ou o campo de API equivalente) não podem compartilhar a mesma unidade de intervalo de IP com instâncias no mesmo projeto que usam a arquitetura de rede antiga. As instâncias criadas com a nova arquitetura de rede exigem intervalos /24 dedicados em todas as regiões.

Exemplo de acesso a serviços particulares

Neste exemplo, a rede VPC alocou o intervalo de endereços 10.240.0.0/16 para Google Cloud serviços e estabeleceu uma conexão particular usando esse intervalo. Cada Google Cloud serviço (por exemplo, o Cloud SQL) cria uma sub-rede com base no bloco alocado para provisionar novos recursos em uma determinada região, como as instâncias do Cloud SQL.

Visão geral do diagrama da configuração de IP privado.

O diagrama ilustra os seguintes aspectos da configuração de acesso a serviços particulares:

  • A conexão particular é atribuída ao intervalo alocado 10.240.0.0/16. Usando essa alocação, Google Cloud serviços podem criar sub-redes em que novos recursos são provisionados.
  • No lado doserviços da conexão particular, Google Cloud Google Cloud cria um projeto para o cliente. O projeto é isolado, o que significa que ele não é compartilhado com nenhum outro cliente e o cliente é cobrado apenas pelos recursos fornecidos.
  • Cada Google Cloud serviço cria uma sub-rede em que provisionar recursos. O intervalo de endereços IP da sub-rede é normalmente um bloco de roteamento entre domínios sem classe (CIDR, na sigla em inglês) /24 escolhido pelo serviço e vem do intervalo de endereços IP alocado. Não é possível modificar a sub-rede do produtor de serviços. Um serviço provisiona novos recursos em sub-redes regionais atuais que foram criadas anteriormente por esse serviço. Se uma sub-rede estiver cheia, o serviço criará uma nova sub-rede na mesma região.
  • As instâncias de VM na rede do cliente podem acessar recursos de serviço em qualquer região quando o serviço é compatível. No entanto, alguns serviços podem não aceitar a comunicação entre regiões. Consulte a documentação do serviço relevante para mais informações.
  • Os custos de transferência de dados de saída para tráfego entre regiões, onde uma instância de VM se comunica com recursos em uma região diferente, continuam sendo aplicáveis.
  • A instância do Cloud SQL recebe o endereço IP 10.240.0.2. Na rede VPC do cliente, as solicitações com o destino 10.240.0.2 são roteadas para a conexão particular na rede do produtor de serviços. Depois que a solicitação chega à rede de serviços, ela contém rotas que direcionam a solicitação para o recurso correto.
  • O tráfego entre redes VPC viaja internamente na Google Cloud rede, não pela Internet pública.

Considerações sobre redes

O Cloud SQL aloca uma sub-rede /24 do intervalo de IP de acesso a serviços particulares para cada região. Por exemplo, para colocar instâncias do MySQL em duas regiões, é necessário que o intervalo de endereços IP alocado contenha pelo menos duas sub-redes disponíveis de tamanho /24.

As conexões com uma instância do Cloud SQL usando um endereço IP privado são autorizadas automaticamente para intervalos de endereços RFC 1918. Dessa forma, todos os clientes particulares podem acessar o banco de dados sem passar pelo proxy de autenticação do Cloud SQL.

Por padrão, o Cloud SQL não aprende as rotas de sub-rede não RFC 1918 da sua VPC. É necessário atualizar o peering de rede para o Cloud SQL para exportar rotas que não sejam RFC 1918.

Considerações sobre segurança

O tráfego por acesso a serviços particulares é fornecido com um determinado nível de criptografia. Para mais informações, consulte Google Cloud Criptografia e autenticação de rede virtual.

É possível configurar o proxy de autenticação do Cloud SQL para se conectar usando o acesso a serviços particulares. Além disso, ele fornece autenticação com credenciais do IAM e criptografia de ponta a ponta usando um certificado SSL/TLS com alternância.

Se os requisitos de segurança exigirem certificados SSL/TLS gerenciados por você, consulte as instruções em Como configurar o SSL/TLS.

A criação de uma rede VPC para cada instância com um endereço IP privado fornece um isolamento de rede melhor do que colocar todas as instâncias na rede VPC "padrão".

Várias conectividade de VPCs

O Cloud SQL oferece suporte a endereços IP particulares por meio do acesso a serviços particulares. Quando você cria uma instância do Cloud SQL, ela é criada na própria rede VPC, chamada de VPC do Cloud SQL. Ativar o IP privado requer a configuração de uma conexão de peering entre a VPC do Cloud SQL e sua rede VPC. Isso permite que os recursos na rede VPC acessem os endereços IP internos dos recursos do Cloud SQL na rede VPC do Cloud SQL.

Usando Peering de rede VPC, o Cloud SQL implementa o acesso a serviços particulares internamente, o que permite que os endereços IP internos se conectem entre duas redes VPC, independentemente de pertencerem ao mesmo projeto ou organização. No entanto, como o peering de rede VPC não é transitivo, ele só transmite rotas entre as duas VPCs com peering direto. Se você tiver uma VPC adicional, ela não poderá acessar os recursos do Cloud SQL usando a conexão configurada com a VPC original.

Para atenuar essa limitação e conectar sua instância do Cloud SQL a várias VPCs usando endereços IP privados, use as seguintes opções de conexão:

  • Conectar usando rotas anunciadas personalizadas
  • Conectar usando um proxy intermediário (SOCKS5)
  • Conectar usando o proxy de autenticação do Cloud SQL como serviço

Para mais informações sobre como conectar várias VPCs, consulte Conectar sua instância a várias redes VPC.

A seguir