Cloud SQL Auth Proxy versus een directe VPN-route naar de database
De Auth Proxy en een directe VPN-route lossen verschillende helften van hetzelfde probleem op. Vergelijk eerst de autorisatie van de connector, de poorten en de databaselogin.
Er zijn twee verstandige manieren om een private Cloud SQL-instantie te bereiken vanaf een laptop op de VPN. De ene is een directe verbinding naar het private adres van de instantie via de route die u al heeft. De andere is de Cloud SQL Auth Proxy, die op loopback luistert en zelf de verbinding naar Cloud SQL opent. Het zijn minder concurrerende producten dan twee verschillende antwoorden op de vraag wie de referentie heeft en wie de route heeft. Een verkeerde keuze komt meestal naar voren als een autorisatiefout die als netwerkfout leest.
Hier is de vergelijking die ik voor een team zou leggen, gevolgd door de controles die het echt beslissen.
Twee paden naar dezelfde instantie
Het directe pad gebruikt de private-services-access-route van uw netwerk naar de VPC van het project. Uw client spreekt PostgreSQL met het private adres van de instantie, en de verbinding leeft of sterft op routing, firewallregels en databasereferenties.
Het proxypad gebruikt dezelfde route maar voegt een lokaal proces toe. De proxy authenticeert bij de Google API met de default credentials van uw applicatie, opent een verbinding naar de instantie via de connector en stelt een loopback-poort beschikbaar die uw client als PostgreSQL behandelt. Twee hops worden er drie, en de middelste draagt de IAM-autorisatie. De VPN-route blijft van u om te onderhouden, en de proxy ziet die nooit als vervanging van die controle.
Wat elk pad feitelijk autoriseert
Het belangrijkste onderscheid is wat elke optie voor u kan autoriseren:
| 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 |
De IAM-controle van de proxy en de databaselogin zijn twee aparte poorten, en door de ene gaan opent de andere niet. Een team dat de proxy aanzet en aanneemt dat het applicatieaccount nu overbodig is, besteedt een middag aan wachtwoordfouten die niets met netwerk te maken hebben.
Poorten en routes naast elkaar
De proxy heeft uitgaand TCP 443 nodig voor de API en TCP 3307 voor de verbinding met de instantie, beide beschreven in Google's overzicht van Auth Proxy. Uw VPN-route dekt de tweede; de eerste verlaat normaal gesproken het gewone pad.
Een directe verbinding vereist dat de PostgreSQL-poort van de instantie bereikbaar is via de private route, wat een heel ander firewallgesprek is. Als uw netwerkteam alleen uitgaand 443 vanaf clientsubnetten toestaat, past de proxy zonder regelwijziging en het directe pad niet. Dat ene feit beslist de keuze vaker dan enige architectonische voorkeur.
Geen van beide paden vereist dat de instantie een openbaar adres heeft, en geen van beide rechtvaardigt er een toe te voegen.
Waar de proxy niet helpt
De proxy repareert geen ontbrekende route. Als de private-services-access-route ontbreekt, of de VPN die niet vervoert, faalt de connector terwijl de lokale listener daar nog steeds zit te luisteren, en dat is het verwarrende deel.
Hij beschermt ook het stuk tussen uw applicatie en de proxy niet. Op één laptop is dat stuk loopback en prima. Als u de listener aan een wildcard-adres bindt zodat een collega hem kan bereiken, heeft u een niet-geauthenticeerde databasegateway gebouwd en dat gemak genoemd. Houd hem op loopback en laat de collega zijn eigen referentie halen.
En hij maakt Private Service Connect en private services access niet uitwisselbaar. Een PSC-instantie heeft zijn eigen DNS-regeling nodig en de --psc-aanroep in plaats van de --private-ip-vorm.
Kiezen en dan hoe dan ook verifiëren
Kies de proxy als u IAM in het pad wilt, kortlevende referenties en geen wijziging van de inkomende firewall.
Kies de directe route als een ondersteunde client al sterke databasereferenties heeft en het netwerkteam de poort wil openen. Verifieer hoe dan ook met een echte query in plaats van met een geslaagde verbinding: verbind, voer één leesbewerking uit op een bekende tabel en kijk wat de server van uw sessie ziet.
Na een VPN-herverbinding behandelt u een verlopen referentie, een ontbrekende private route en een afgewezen databaselogin als drie verschillende storingen. Slechts één ervan is een netwerkprobleem, en slechts één zou ooit moeten leiden tot het wijzigen van een firewallregel.