Cloud SQL Auth Proxy teenoor 'n direkte VPN-roete na die databasis
Die Auth Proxy en 'n direkte VPN-roete los verskillende helftes van dieselfde probleem op. Vergelyk eers connector-magtiging, poorte en databasis-aanmelding.
Daar is twee sinvolle maniere om 'n private Cloud SQL-instansie vanaf 'n skootrekenaar op die VPN te bereik. Die een is 'n direkte verbinding na die instansie se private adres oor die roete wat jy reeds het. Die ander is die Cloud SQL Auth Proxy, wat op loopback luister en die verbinding na Cloud SQL self oopmaak. Hulle is minder mededingende produkte as verskillende antwoorde op die vraag wie die geloofsbriewe hou en wie die roete hou. 'n Verkeerde keuse kom gewoonlik na vore as 'n magtigingsfout wat soos 'n netwerkfout lees.
Hier is die vergelyking wat ek voor 'n span sou sit, gevolg deur die kontroles wat dit werklik beslis.
Twee paaie na dieselfde instansie
Die direkte pad gebruik die private-services-access-roete van jou netwerk na die projek se VPC. Jou kliënt praat PostgreSQL met die instansie se private adres, en die verbinding leef of sterf op roetering, firewall-reels en databasis-geloofsbriewe.
Die proxy-pad gebruik dieselfde roete maar voeg 'n plaaslike proses by. Die proxy verifieer by Google se API met jou application default credentials, maak 'n verbinding na die instansie oor die connector oop, en stel 'n loopback-poort beskikbaar wat jou kliënt as PostgreSQL behandel. Twee spronge word drie, en die middelste een dra IAM-magtiging. Die VPN-roete bly joune om te onderhou, en die proxy beskou dit nooit as 'n plaasvervanger vir daardie kontrole nie.
Wat elke pad werklik magtig
Die onderskeid wat die meeste saak maak, is wat elke opsie vir jou kan magtig:
| 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 proxy se IAM-kontrole en die databasis-aanmelding is aparte hekke, en om een oor te steek maak nie die ander oop nie. 'n Span wat die proxy aktiveer en aanneem die toepassing-rekening is nou onnodig, sal 'n middag spandeer op wagwoordfoute wat niks met netwerking te doen het nie.
Poorte en roetes, langs mekaar
Die proxy benodig uitgaande TCP 443 vir die API en TCP 3307 vir die instansieverbinding, albei beskryf in Google se Auth Proxy-oorsig. Jou VPN-roete dek die tweede; die eerste verlaat gewoonlik via die gewone pad.
’n Direkte verbinding benodig dat die instansie se PostgreSQL-poort oor die private roete bereikbaar is, wat 'n ander firewall-gesprek is. As jou netwerkspan slegs 443 uitgaande van kliënt-subnette toelaat, pas die proxy sonder 'n reëlverandering en die direkte pad nie. Daardie enkele feit beslis die keuse meer dikwels as enige argitektoniese voorkeur.
Nie een van die twee paaie vereis dat die instansie 'n publieke adres het nie, en nie een regverdig dit om een by te voeg nie.
Waar die proxy nie help nie
Die proxy maak nie 'n ontbrekende roete reg nie. As die private-services-access-roete afwesig is, of die VPN dit nie dra nie, misluk die connector terwyl die plaaslike luisteraar steeds daar sit en luister, wat die verwarrende deel is.
Dit beskerm ook nie die been tussen jou toepassing en die proxy nie. Op een skootrekenaar is daardie been loopback en heeltemal in orde. As jy die luisteraar aan 'n wildcard-adres bind sodat 'n kollega dit kan bereik, het jy 'n ongemagtigde databasis-gateway gebou en dit 'n gerief genoem. Hou dit op loopback en laat die kollega hul eie geloofsbrief kry.
En dit maak nie Private Service Connect en private services access uitruilbaar nie. 'n PSC-instansie benodig sy eie DNS-reëling en die --psc-aanroep eerder as die --private-ip-vorm.
Kies, en verifieer dan in elk geval
Kies die proxy wanneer jy IAM in die pad wil hê, kortstondige geloofsbriewe en geen inkomende firewall-verandering nie.
Kies die direkte roete wanneer 'n ondersteunde kliënt reeds sterk databasis-geloofsbriewe het en die netwerkspan gemaklik is om die poort oop te maak. Verifieer in elk geval met 'n werklike navraag eerder as 'n suksesvolle verbinding: verbind, hardloop een lees teen 'n bekende tabel, en kyk wat die bediener vir jou sessie sien.
Ná 'n VPN-herverbinding, behandel 'n vervalde geloofsbrief, 'n ontbrekende private roete en 'n databasis-aanmelding-weiering as drie verskillende mislukkings. Slegs een van hulle is 'n netwerkprobleem, en slegs een behoort ooit te lei tot die verandering van 'n firewall-reël.