Cloud SQL Auth Proxy oder eine direkte VPN-Route zur Datenbank
Auth Proxy und eine direkte VPN-Route lösen unterschiedliche Hälften desselben Problems. Vergleichen Sie zuerst Connector-Autorisierung, Ports und Datenbank-Login.
Es gibt zwei vernünftige Wege, eine private Cloud SQL-Instanz von einem Laptop im VPN aus zu erreichen. Der eine ist eine direkte Verbindung zur privaten Adresse der Instanz über die Route, die Sie bereits haben. Der andere ist der Cloud SQL Auth Proxy, der auf Loopback lauscht und die Verbindung zu Cloud SQL selbst öffnet. Sie sind weniger konkurrierende Produkte als zwei verschiedene Antworten auf die Frage, wer die Anmeldedaten hält und wer die Route hält. Eine schlechte Wahl zeigt sich meist als Autorisierungsfehler, der wie ein Netzwerkfehler klingt.
Hier ist der Vergleich, den ich einem Team vorlegen würde, gefolgt von den Prüfungen, die ihn tatsächlich entscheiden.
Zwei Wege zur selben Instanz
Der direkte Weg nutzt die private-services-access-Route aus Ihrem Netzwerk in die VPC des Projekts. Ihr Client spricht PostgreSQL mit der privaten Adresse der Instanz, und die Verbindung lebt oder stirbt an Routing, Firewall-Regeln und Datenbank-Anmeldedaten.
Der Proxy-Weg nutzt dieselbe Route, fügt aber einen lokalen Prozess hinzu. Der Proxy authentifiziert sich mit den default credentials Ihrer Anwendung an der Google API, öffnet eine Verbindung zur Instanz über den Connector und stellt einen Loopback-Port bereit, den Ihr Client als PostgreSQL behandelt. Aus zwei Hops werden drei, und der mittlere trägt die IAM-Autorisierung. Die VPN-Route bleibt Ihre Pflegeaufgabe, und der Proxy sieht sie nie als Ersatz für diese Prüfung.
Was jeder Weg tatsächlich autorisiert
Der wichtigste Unterschied ist, was jede Option für Sie autorisieren kann:
| 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 |
Die IAM-Prüfung des Proxys und der Datenbank-Login sind getrennte Tore, und der Durchgang durch das eine öffnet das andere nicht. Ein Team, das den Proxy aktiviert und annimmt, das Anwendungskonto sei nun überflüssig, verbringt einen Nachmittag mit Passwortfehlern, die nichts mit Netzwerk zu tun haben.
Ports und Routen im Vergleich
Der Proxy braucht ausgehendes TCP 443 für die API und TCP 3307 für die Instanzverbindung, beides in Googles Überblick zum Auth Proxy beschrieben. Ihre VPN-Route deckt die zweite ab; die erste verlässt normalerweise den gewohnten Weg.
Eine direkte Verbindung braucht den PostgreSQL-Port der Instanz erreichbar über die private Route, was ein anderes Firewall-Gespräch ist. Wenn Ihr Netzwerkteam nur ausgehendes 443 aus Client-Subnetzen erlaubt, passt der Proxy ohne Regeländerung und der direkte Weg nicht. Diese eine Tatsache entscheidet die Wahl häufiger als jede Architekturvorliebe.
Keiner der Wege verlangt, dass die Instanz eine öffentliche Adresse hat, und keiner rechtfertigt es, eine hinzuzufügen.
Wo der Proxy nicht hilft
Der Proxy behebt keine fehlende Route. Fehlt die private-services-access-Route oder trägt das VPN sie nicht, scheitert der Connector, während der lokale Listener weiter dort sitzt und lauscht, und das ist der verwirrende Teil.
Er schützt auch nicht das Teilstück zwischen Ihrer Anwendung und dem Proxy. Auf einem Laptop ist dieses Teilstück Loopback und in Ordnung. Wenn Sie den Listener an eine Wildcard-Adresse binden, damit ein Kollege ihn erreicht, haben Sie ein nicht authentifiziertes Datenbank-Gateway gebaut und es Bequemlichkeit genannt. Halten Sie ihn auf Loopback und lassen Sie den Kollegen eigene Anmeldedaten besorgen.
Und er macht Private Service Connect und private services access nicht austauschbar. Eine PSC-Instanz braucht ihre eigene DNS-Regelung und den --psc-Aufruf statt der --private-ip-Form.
Wählen und dann so oder so prüfen
Wählen Sie den Proxy, wenn Sie IAM im Pfad, kurzlebige Anmeldedaten und keine Änderung der eingehenden Firewall wollen.
Wählen Sie die direkte Route, wenn ein unterstützter Client bereits starke Datenbank-Anmeldedaten hat und das Netzwerkteam den Port öffnet. Prüfen Sie in beiden Fällen mit einer echten Abfrage statt mit einer erfolgreichen Verbindung: verbinden, eine Leseabfrage gegen eine bekannte Tabelle ausführen und nachsehen, was der Server für Ihre Sitzung sieht.
Nach einer VPN-Wiederverbindung behandeln Sie abgelaufene Anmeldedaten, eine fehlende private Route und eine abgelehnte Datenbank-Anmeldung als drei verschiedene Fehler. Nur einer davon ist ein Netzwerkproblem, und nur einer sollte je dazu führen, eine Firewall-Regel zu ändern.