Cloud SQL Auth Proxy o una rotta VPN diretta al database
L'Auth Proxy e una rotta VPN diretta risolvono due metà diverse dello stesso problema. Confrontate prima l'autorizzazione del connettore, le porte e l'accesso al database.
Ci sono due modi sensati per raggiungere un'istanza Cloud SQL privata da un portatile sulla VPN. Uno è una connessione diretta all'indirizzo privato dell'istanza attraverso la rotta che avete già. L'altro è il Cloud SQL Auth Proxy, che ascolta su loopback e apre lui stesso la connessione verso Cloud SQL. Non sono tanto prodotti concorrenti quanto due risposte diverse alla domanda su chi detiene la credenziale e chi detiene la rotta. Una scelta sbagliata di solito si manifesta come un errore di autorizzazione che si legge come un errore di rete.
Ecco il confronto che metterei davanti a un team, seguito dai controlli che lo decidono davvero.
Due percorsi verso la stessa istanza
Il percorso diretto usa la rotta private-services-access dalla vostra rete verso la VPC del progetto. Il vostro client parla PostgreSQL con l'indirizzo privato dell'istanza, e la connessione vive o muore sull'instradamento, sulle regole del firewall e sulle credenziali del database.
Il percorso tramite proxy usa la stessa rotta ma aggiunge un processo locale. Il proxy si autentica all'API di Google con le credenziali predefinite dell'applicazione, apre una connessione all'istanza tramite il connettore ed espone una porta loopback che il vostro client tratta come PostgreSQL. Due salti diventano tre, e quello centrale porta l'autorizzazione IAM. La rotta VPN resta a voi da mantenere, e il proxy non la considera mai un sostituto di quel controllo.
Che cosa autorizza davvero ciascun percorso
La distinzione che conta di più è che cosa ciascuna opzione può autorizzare per voi:
| 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 |
Il controllo IAM del proxy e l'accesso al database sono due porte separate, e passare l'una non apre l'altra. Un team che abilita il proxy e dà per scontato che l'account dell'applicazione non serva più passerà un pomeriggio su errori di password che non hanno nulla a che vedere con la rete.
Porte e rotte, fianco a fianco
Il proxy ha bisogno di TCP 443 in uscita per l'API e di TCP 3307 per la connessione all'istanza, entrambi descritti nella panoramica di Auth Proxy. La vostra rotta VPN copre il secondo; il primo di solito esce dal percorso abituale.
Una connessione diretta richiede che la porta PostgreSQL dell'istanza sia raggiungibile sulla rotta privata, che è un'altra conversazione sul firewall. Se il vostro team di rete consente solo il 443 in uscita dalle sottoreti dei client, il proxy si adatta senza cambiare regole e il percorso diretto no. Questo unico fatto decide la scelta più spesso di qualsiasi preferenza architetturale.
Nessuno dei due percorsi richiede che l'istanza abbia un indirizzo pubblico, e nessuno giustifica aggiungerne uno.
Dove il proxy non aiuta
Il proxy non ripara una rotta mancante. Se la rotta private-services-access è assente, o la VPN non la trasporta, il connettore fallisce mentre il listener locale resta lì ad ascoltare, ed è questa la parte confusa.
Non protegge nemmeno il tratto tra l'applicazione e il proxy. Su un portatile quel tratto è loopback e va bene. Se legate il listener a un indirizzo wildcard perché un collega lo raggiunga, avete costruito un gateway del database senza autenticazione e lo avete chiamato comodità. Tenetelo su loopback e lasciate che il collega ottenga la propria credenziale.
E non rende Private Service Connect e private services access intercambiabili. Un'istanza PSC ha bisogno della propria disposizione DNS e della chiamata --psc invece della forma --private-ip.
Scegliere, poi verificare in ogni caso
Scegliete il proxy quando volete IAM nel percorso, credenziali di breve durata e nessuna modifica al firewall in ingresso.
Scegliete la rotta diretta quando un client supportato detiene già credenziali solide del database e il team di rete accetta di aprire la porta. In ogni caso verificate con una query vera invece che con una connessione riuscita: connettetevi, eseguite una lettura su una tabella nota e controllate che cosa vede il server della vostra sessione.
Dopo una riconnessione VPN, trattate una credenziale scaduta, una rotta privata mancante e un rifiuto dell'accesso al database come tre guasti diversi. Solo uno è un problema di rete, e solo uno dovrebbe mai portare a modificare una regola del firewall.