Cloud SQL Auth Proxy kontra en direkte VPN-rute til databasen
Auth Proxy og en direkte VPN-rute løser forskellige halvdele af det samme problem. Sammenlign først connector-autorisering, porte og databaselogin.
Der er to fornuftige måder at nå en privat Cloud SQL-instans fra en laptop på VPN-forbindelsen. Den ene er en direkte forbindelse til instansens private adresse over den rute, du allerede har. Den anden er Cloud SQL Auth Proxy, som lytter på loopback og selv åbner forbindelsen til Cloud SQL. De er mindre konkurrerende produkter end to forskellige svar på, hvem der holder legitimationsoplysningerne, og hvem der holder ruten. Et dårligt valg viser sig oftest som en autorisationsfejl, der læses som en netværksfejl.
Her er sammenligningen, jeg ville lægge foran et team, efterfulgt af de kontroller, der faktisk afgør sagen.
To veje til den samme instans
Den direkte vej bruger private-services-access-ruten fra dit netværk ind i projektets VPC. Din klient taler PostgreSQL med instansens private adresse, og forbindelsen lever eller dør på routing, firewallregler og databaselegitimationsoplysninger.
Proxyvejen bruger samme rute, men tilføjer en lokal proces. Proxyen autentificerer sig mod Googles API med applikationens default credentials, åbner en forbindelse til instansen over connectoren og eksponerer en loopback-port, som din klient behandler som PostgreSQL. To hop bliver tre, og det midterste bærer IAM-autorisering. VPN-ruten er stadig din at vedligeholde, og proxyen ser den aldrig som en erstatning for den kontrol.
Hvad hver vej egentlig autoriserer
Den vigtigste forskel er, hvad hver mulighed kan autorisere på dine vegne:
| 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 |
Proxyens IAM-kontrol og databaseloginnet er to separate porte, og adgang gennem den ene åbner ikke den anden. Et team, der aktiverer proxyen og antager, at applikationskontoen nu er overflødig, bruger en eftermiddag på adgangskodefejl, der intet har med netværk at gøre.
Porte og ruter side om side
Proxyen har brug for udgående TCP 443 til API'et og TCP 3307 til instansforbindelsen, begge beskrevet i Googles oversigt over Auth Proxy. Din VPN-rute dækker det andet; det første forlader normalt ad den almindelige vej.
En direkte forbindelse kræver, at instansens PostgreSQL-port kan nås over den private rute, hvilket er en helt anden firewall-samtale. Hvis dit netværksteam kun tillader udgående 443 fra klient-subnet, passer proxyen uden en regelændring, og den direkte vej gør ikke. Den ene kendsgerning afgør valget oftere end nogen arkitektonisk præference.
Ingen af vejene kræver, at instansen har en offentlig adresse, og ingen af dem retfærdiggør at tilføje en.
Hvor proxyen ikke hjælper
Proxyen retter ikke en manglende rute. Hvis private-services-access-ruten mangler, eller VPN-forbindelsen ikke bærer den, fejler connectoren, mens den lokale listener stadig sidder der og lytter, og det er den forvirrende del.
Den beskytter heller ikke benet mellem din applikation og proxyen. På en enkelt laptop er det ben loopback og fint. Hvis du binder listeneren til en wildcard-adresse, så en kollega kan nå den, har du bygget en uautentificeret databasegateway og kaldt det en bekvemmelighed. Hold den på loopback, og lad kollegaen skaffe sine egne legitimationsoplysninger.
Og den gør ikke Private Service Connect og private services access udskiftelige. En PSC-instans har brug for sit eget DNS-arrangement og --psc-kaldet i stedet for --private-ip-formen.
Vælg, og verificér så under alle omstændigheder
Vælg proxyen, når du vil have IAM i vejen, kortlivede legitimationsoplysninger og ingen ændring af indgående firewall.
Vælg den direkte rute, når en understøttet klient allerede har stærke databaselegitimationsoplysninger, og netværksteamet er trygt ved at åbne porten. Under alle omstændigheder skal du verificere med en rigtig forespørgsel i stedet for en vellykket forbindelse: forbind, kør en enkelt læsning mod en kendt tabel, og kontroller, hvad serveren ser for din session.
Efter en VPN-genopkobling skal du behandle udløbne legitimationsoplysninger, en manglende privat rute og en afvist databaselogin som tre forskellige fejl. Kun én af dem er et netværksproblem, og kun én bør nogensinde føre til at ændre en firewallregel.