Cloud SQL Auth Proxy eller en direkt VPN-rutt till databasen
Auth Proxy och en direkt VPN-rutt löser olika halvor av samma problem. Jämför först anslutningsautentiseringen, portarna och databasinloggningen.
Det finns två rimliga sätt att nå en privat Cloud SQL-instans från en laptop på VPN:et. Det ena är en direkt anslutning till instansens privata adress över rutten du redan har. Det andra är Cloud SQL Auth Proxy, som lyssnar på loopback och själv öppnar anslutningen till Cloud SQL. De är mindre konkurrerande produkter än två olika svar på frågan vem som håller uppgifterna och vem som håller rutten. Ett dåligt val visar sig oftast som ett auktoriseringsfel som läses som ett nätverksfel.
Här är jämförelsen jag skulle lägga fram för ett team, följd av de kontroller som faktiskt avgör den.
Två vägar till samma instans
Den direkta vägen använder private-services-access-rutten från ditt nätverk in i projektets VPC. Din klient talar PostgreSQL med instansens privata adress, och anslutningen lever eller dör på routing, brandväggsregler och databasens inloggningsuppgifter.
Proxyvägen använder samma rutt men lägger till en lokal process. Proxyn autentiserar mot Google API med applikationens default credentials, öppnar en anslutning till instansen via connectorn och exponerar en loopback-port som din klient behandlar som PostgreSQL. Två hopp blir tre, och det mittersta bär IAM-auktorisering. VPN-rutten är fortfarande din att underhålla, och proxyn ser den aldrig som en ersättning för den kontrollen.
Vad varje väg faktiskt auktoriserar
Den viktigaste skillnaden är vad varje alternativ kan auktorisera åt dig:
| 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 |
Proxyns IAM-kontroll och databasinloggningen är två separata portar, och att passera den ena öppnar inte den andra. Ett team som aktiverar proxyn och antar att applikationskontot nu är onödigt spenderar en eftermiddag på lösenordsfel som inte har något med nätverk att göra.
Portar och rutter sida vid sida
Proxyn behöver utgående TCP 443 för API:et och TCP 3307 för instansanslutningen, båda beskrivna i Googles översikt över Auth Proxy. Din VPN-rutt täcker den andra; den första går normalt ut den vanliga vägen.
En direkt anslutning kräver att instansens PostgreSQL-port går att nå över den privata rutten, vilket är ett helt annat brandväggssamtal. Om ditt nätverksteam bara tillåter utgående 443 från klientsubnät passar proxyn utan regeländring och den direkta vägen gör det inte. Det enda faktumet avgör valet oftare än någon arkitektonisk preferens.
Ingen av vägarna kräver att instansen har en offentlig adress, och ingen av dem motiverar att lägga till en.
Där proxyn inte hjälper
Proxyn reparerar inte en saknad rutt. Om private-services-access-rutten saknas, eller VPN:et inte bär den, misslyckas connectorn medan den lokala lyssnaren fortfarande sitter där och lyssnar, och det är den förvirrande delen.
Den skyddar inte heller sträckan mellan din applikation och proxyn. På en laptop är den sträckan loopback och det är bra. Om du binder lyssnaren till en wildcard-adress så att en kollega kan nå den har du byggt en oautentiserad databasport och kallat det en bekvämlighet. Håll den på loopback och låt kollegan skaffa sina egna uppgifter.
Och den gör inte Private Service Connect och private services access utbytbara. En PSC-instans behöver sitt eget DNS-arrangemang och --psc-anropet i stället för --private-ip-formen.
Välja och sedan verifiera oavsett
Välj proxyn när du vill ha IAM i vägen, kortlivade uppgifter och ingen ändring av den ingående brandväggen.
Välj den direkta rutten när en klient som stöds redan har starka databasuppgifter och nätverksteamet är bekvämt med att öppna porten. Verifiera oavsett med en riktig fråga i stället för en lyckad anslutning: anslut, kör en läsning mot en känd tabell och kontrollera vad servern ser om din session.
Efter en VPN-återanslutning ska du behandla utgångna uppgifter, en saknad privat rutt och ett avvisat databasinlogg som tre olika fel. Bara ett av dem är ett nätverksproblem, och bara ett borde någonsin leda till att en brandväggsregel ändras.