Cloud SQL Auth Proxy enfront d'una ruta VPN directa a la base de dades
L'Auth Proxy i una ruta VPN directa resolen meitats diferents del mateix problema. Compareu primer l'autorització del connector, els ports i l'inici de sessió a la base de dades.
Hi ha dues maneres sensates d'arribar a una instància privada de Cloud SQL des d'un portàtil a la VPN. Una és una connexió directa a l'adreça privada de la instància per la ruta que ja teniu. L'altra és el Cloud SQL Auth Proxy, que escolta al loopback i obre ell mateix la connexió cap a Cloud SQL. No són tant productes competidors com dues respostes diferents a qui té la credencial i qui té la ruta. Una tria dolenta sol aparèixer com un error d'autorització que es llegeix com un error de xarxa.
Aquesta és la comparació que posaria davant d'un equip, seguida de les comprovacions que realment ho decideixen.
Dos camins cap a la mateixa instància
El camí directe utilitza la ruta de private-services-access des de la vostra xarxa fins al VPC del projecte. El client parla PostgreSQL amb l'adreça privada de la instància, i la connexió viu o mor segons l'encaminament, les regles de firewall i les credencials de la base de dades.
El camí del proxy utilitza la mateixa ruta però afegeix un procés local. El proxy s'autentica a l'API de Google amb les credencials predeterminades de l'aplicació, obre una connexió a la instància a través del connector i exposa un port de loopback que el client tracta com a PostgreSQL. Dos salts passen a ser tres, i el del mig porta l'autorització IAM. La ruta VPN continua sent vostra de mantenir, i el proxy mai no la considera un substitut d'aquesta comprovació.
Què autoritza realment cada camí
La distinció que més importa és què pot autoritzar cada opció per vosaltres:
| 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 |
La comprovació IAM del proxy i l'inici de sessió a la base de dades són portes separades, i passar-ne una no obre l'altra. Un equip que activa el proxy i assumeix que el compte de l'aplicació ja no caldrà passarà una tarda amb errors de contrasenya que no tenen res a veure amb la xarxa.
Ports i rutes, costat a costat
El proxy necessita TCP 443 de sortida per a l'API i TCP 3307 per a la connexió a la instància, tots dos descrits a la visió general d'Auth Proxy. La vostra ruta VPN cobreix el segon; el primer normalment surt pel camí habitual.
Una connexió directa necessita que el port PostgreSQL de la instància sigui abastable per la ruta privada, que és una conversa de firewall diferent. Si el vostre equip de xarxa només permet 443 de sortida des de les subxarxes de clients, el proxy encaixa sense cap canvi de regla i el camí directe no. Aquest sol fet decideix la tria més sovint que qualsevol preferència arquitectònica.
Cap dels dos camins no requereix que la instància tingui una adreça pública, i cap dels dos justifica afegir-ne una.
On el proxy no ajuda
El proxy no arregla una ruta que falta. Si la ruta de private-services-access no hi és, o la VPN no la transporta, el connector falla mentre l'oient local continua allà escoltant, i aquesta és la part confusa.
També no protegeix el tram entre l'aplicació i el proxy. En un portàtil aquest tram és loopback i va bé. Si lligueu l'oient a una adreça wildcard perquè un company hi pugui arribar, heu construït una passarel·la de base de dades sense autenticació i l'heu anomenada comoditat. Manteniu-lo al loopback i deixeu que el company obtingui la seva pròpia credencial.
I no fa intercanviables Private Service Connect i private services access. Una instància PSC necessita la seva pròpia disposició de DNS i la invocació --psc en lloc de la forma --private-ip.
Triar i després verificar de qualsevol manera
Trieu el proxy quan vulgueu IAM al camí, credencials de curta durada i cap canvi de firewall d'entrada.
Trieu la ruta directa quan un client compatible ja tingui credencials fortes de base de dades i l'equip de xarxa es trobi còmode obrint el port. De qualsevol manera, verifiqueu amb una consulta real i no amb una connexió correcta: connecteu-vos, executeu una lectura contra una taula coneguda i comproveu què veu el servidor de la vostra sessió.
Després de reconnectar la VPN, tracteu una credencial caducada, una ruta privada que falta i un rebuig d'inici de sessió a la base de dades com tres fallades diferents. Només una és un problema de xarxa, i només una hauria de portar mai a canviar una regla de firewall.