Cloud SQL Auth Proxy fronte a unha ruta VPN directa á base de datos

Hai dúas formas sensatas de chegar a unha instancia privada de Cloud SQL desde un portátil na VPN. Unha é unha conexión directa ao enderezo privado da instancia pola ruta que xa ten. A outra é o Cloud SQL Auth Proxy, que escoita en loopback e abre el mesmo a conexión cara a Cloud SQL. Non son tanto produtos competidores como dúas respostas distintas a quen ten a credencial e quen ten a ruta. Unha mala elección adoita aparecer como un erro de autorización que se le como un erro de rede.

Esta é a comparación que poñería diante dun equipo, seguida das comprobacións que realmente a deciden.

Dous camiños cara á mesma instancia

O camiño directo usa a ruta private-services-access desde a súa rede cara á VPC do proxecto. O seu cliente fala PostgreSQL co enderezo privado da instancia, e a conexión vive ou morre segundo o encamiñamento, as regras de firewall e as credenciais da base de datos.

O camiño do proxy usa a mesma ruta pero engade un proceso local. O proxy autentícase na API de Google coas credenciais predeterminadas da aplicación, abre unha conexión á instancia a través do conector e expón un porto de loopback que o seu cliente trata como PostgreSQL. Dous saltos pasan a tres, e o do medio leva a autorización IAM. A ruta VPN segue a ser súa de manter, e o proxy nunca a considera un substituto desa comprobación.

Que autoriza realmente cada camiño

A distinción que máis importa é que pode autorizar cada opción por vostede:

A comprobación IAM do proxy e o inicio de sesión na base de datos son portas separadas, e pasar unha non abre a outra. Un equipo que activa o proxy e dá por feito que a conta da aplicación xa non fai falta pasará unha tarde con fallos de contrasinal que non teñen nada que ver coa rede.

Portos e rutas, lado a lado

O proxy necesita TCP 443 de saída para a API e TCP 3307 para a conexión á instancia, ambos descritos na visión xeral de Auth Proxy. A súa ruta VPN cobre o segundo; o primeiro normalmente sae polo camiño habitual.

Unha conexión directa necesita que o porto PostgreSQL da instancia sexa alcanzable pola ruta privada, que é outra conversa de firewall. Se o seu equipo de rede só permite 443 de saída desde as subredes de clientes, o proxy encaixa sen cambiar ningunha regra e o camiño directo non. Ese único feito decide a elección máis a miúdo que calquera preferencia arquitectónica.

Ningún dos dous camiños esixe que a instancia teña un enderezo público, e ningún xustifica engadir un.

Onde o proxy non axuda

O proxy non arranxa unha ruta que falta. Se a ruta private-services-access non existe, ou a VPN non a transporta, o conector falla mentres o oínte local segue alí escoitando, e esa é a parte confusa.

Tampouco protexe o tramo entre a súa aplicación e o proxy. Nun portátil ese tramo é loopback e está ben. Se ata o oínte a un enderezo wildcard para que un compañeiro chegue a el, construíu unha pasarela de base de datos sen autenticación e chamoulle comodidade. Mantéñao en loopback e deixe que o compañeiro obteña a súa propia credencial.

E non fai intercambiables Private Service Connect e private services access. Unha instancia PSC necesita a súa propia disposición de DNS e a invocación --psc en lugar da forma --private-ip.

Escoller e despois verificar de calquera xeito

Escolla o proxy cando queira IAM no camiño, credenciais de curta duración e ningún cambio de firewall de entrada.

Escolla a ruta directa cando un cliente compatible xa teña credenciais fortes de base de datos e o equipo de rede estea cómodo abrindo o porto. De calquera xeito, verifique cunha consulta real en lugar de cunha conexión correcta: concéctese, execute unha lectura contra unha táboa coñecida e comprobe que ve o servidor da súa sesión.

Despois de reconectar a VPN, trate unha credencial caducada, unha ruta privada que falta e un rexeitamento de inicio de sesión na base de datos como tres fallos distintos. Só un é un problema de rede, e só un debería levar algunha vez a cambiar unha regra de firewall.