Cloud SQL Auth Proxy ou uma rota VPN direta para o banco de dados
O Auth Proxy e uma rota VPN direta resolvem metades diferentes do mesmo problema. Compare primeiro a autorização do conector, as portas e o login no banco de dados.
Existem duas formas sensatas de chegar a uma instância privada do Cloud SQL a partir de um portátil na VPN. Uma é uma conexão direta ao endereço privado da instância pela rota que já tem. A outra é o Cloud SQL Auth Proxy, que escuta em loopback e abre ele próprio a conexão para o Cloud SQL. Não são tanto produtos concorrentes como duas respostas diferentes à pergunta sobre quem detém a credencial e quem detém a rota. Uma escolha errada costuma aparecer como um erro de autorização que se lê como um erro de rede.
Eis a comparação que eu colocaria à frente de uma equipa, seguida das verificações que realmente a decidem.
Dois caminhos para a mesma instância
O caminho direto usa a rota private-services-access da sua rede para a VPC do projeto. O seu cliente fala PostgreSQL com o endereço privado da instância, e a conexão vive ou morre no encaminhamento, nas regras de firewall e nas credenciais da base de dados.
O caminho pelo proxy usa a mesma rota mas acrescenta um processo local. O proxy autentica-se na API da Google com as credenciais predefinidas da aplicação, abre uma conexão à instância através do conector e expõe uma porta de loopback que o seu cliente trata como PostgreSQL. Dois saltos passam a três, e o do meio transporta a autorização IAM. A rota VPN continua a ser sua para manter, e o proxy nunca a considera um substituto dessa verificação.
O que cada caminho autoriza de facto
A distinção que mais importa é o que cada opção pode autorizar por si:
| Question | Direct private IP | Auth Proxy |
|---|---|---|
| Who proves identity to the network | Your client, through the VPN and a database login | The proxy, through IAM to Google's API |
| IAM role needed for the connector | None | Cloud SQL Client or equivalent |
| Database user authentication | Always required | Still required unless IAM database authentication is enabled |
| Shape of the local leg | Client to instance | Client to loopback, proxy to instance |
A verificação IAM do proxy e o login na base de dados são duas portas separadas, e passar uma não abre a outra. Uma equipa que ativa o proxy e assume que a conta da aplicação já é desnecessária passará uma tarde com falhas de palavra-passe que não têm nada a ver com a rede.
Portas e rotas, lado a lado
O proxy precisa de TCP 443 de saída para a API e TCP 3307 para a ligação à instância, ambos descritos na visão geral do Auth Proxy da Google. A sua rota VPN cobre o segundo; o primeiro normalmente sai pelo caminho habitual.
Uma conexão direta exige que a porta PostgreSQL da instância esteja acessível pela rota privada, o que é uma conversa de firewall completamente diferente. Se a sua equipa de rede só permite 443 de saída a partir das sub-redes de clientes, o proxy encaixa sem alterar regras e o caminho direto não. Esse único facto decide a escolha mais vezes do que qualquer preferência arquitetural.
Nenhum dos caminhos exige que a instância tenha um endereço público, e nenhum justifica acrescentar um.
Onde o proxy não ajuda
O proxy não corrige uma rota em falta. Se a rota private-services-access não existir, ou a VPN não a transportar, o conector falha enquanto o ouvinte local continua ali sentado a escutar, e é essa a parte confusa.
Também não protege o troço entre a aplicação e o proxy. Num portátil esse troço é loopback e está bem. Se ligar o ouvinte a um endereço wildcard para que um colega o alcance, construiu uma porta de acesso à base de dados sem autenticação e chamou-lhe comodidade. Mantenha-o em loopback e deixe o colega obter a sua própria credencial.
E não torna o Private Service Connect e o private services access intercambiáveis. Uma instância PSC precisa do seu próprio arranjo de DNS e da invocação --psc em vez da forma --private-ip.
Escolher e depois verificar de qualquer forma
Escolha o proxy quando quiser IAM no caminho, credenciais de curta duração e nenhuma alteração à firewall de entrada.
Escolha a rota direta quando um cliente suportado já tiver credenciais fortes da base de dados e a equipa de rede estiver confortável em abrir a porta. De qualquer forma, verifique com uma consulta real em vez de uma conexão bem-sucedida: ligue-se, execute uma leitura numa tabela conhecida e veja o que o servidor percebe da sua sessão.
Depois de reconectar a VPN, trate uma credencial expirada, uma rota privada em falta e uma recusa de login na base de dados como três falhas diferentes. Apenas uma é um problema de rede, e apenas uma deveria alguma vez levar a alterar uma regra de firewall.