Cloud SQL Auth Proxy mot en direkte VPN-rute til databasen
Auth Proxy og en direkte VPN-rute løser ulike halvdeler av samme problem. Sammenlign først connector-autorisasjon, porter og databaselogginn.
Det finnes to fornuftige måter å nå en privat Cloud SQL-instans fra en laptop på VPN-et. Den ene er en direkte tilkobling til instansens private adresse over ruten du allerede har. Den andre er Cloud SQL Auth Proxy, som lytter på loopback og åpner tilkoblingen til Cloud SQL selv. De er mindre konkurrerende produkter enn to forskjellige svar på hvem som holder legitimasjonen og hvem som holder ruten. Et dårlig valg viser seg vanligvis som en autorisasjonsfeil som leses som en nettverksfeil.
Her er sammenligningen jeg ville lagt foran et team, etterfulgt av kontrollene som faktisk avgjør den.
To veier til samme instans
Den direkte veien bruker private-services-access-ruten fra nettverket ditt inn i prosjektets VPC. Klienten din snakker PostgreSQL med instansens private adresse, og tilkoblingen lever eller dør på ruting, brannmurregler og databasens legitimasjon.
Proxy-veien bruker samme rute, men legger til en lokal prosess. Proxyen autentiserer seg mot Google API med applikasjonens default credentials, åpner en tilkobling til instansen over connectoren og eksponerer en loopback-port som klienten din behandler som PostgreSQL. To hopp blir tre, og det midterste bærer IAM-autorisasjon. VPN-ruten er fortsatt din å vedlikeholde, og proxyen ser den aldri som en erstatning for den kontrollen.
Hva hver vei faktisk autoriserer
Den viktigste forskjellen er hva hvert alternativ 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-kontroll og databaselogginnet er to separate porter, og å passere den ene åpner ikke den andre. Et team som aktiverer proxyen og antar at applikasjonskontoen nå er unødvendig, bruker en ettermiddag på passordfeil som ikke har noe med nettverk å gjøre.
Porter og ruter side om side
Proxyen trenger utgående TCP 443 for API-et og TCP 3307 for instansforbindelsen, begge beskrevet i Googles oversikt over Auth Proxy. VPN-ruten din dekker den andre; den første går normalt ut den vanlige veien.
En direkte tilkobling krever at instansens PostgreSQL-port er nåbar over den private ruten, noe som er en helt annen brannmursamtale. Hvis nettverksteamet ditt bare tillater utgående 443 fra klient-subnett, passer proxyen uten regelendring og den direkte veien gjør det ikke. Det ene faktumet avgjør valget oftere enn noen arkitektonisk preferanse.
Ingen av veiene krever at instansen har en offentlig adresse, og ingen av dem rettferdiggjør å legge til en.
Der proxyen ikke hjelper
Proxyen reparerer ikke en manglende rute. Hvis private-services-access-ruten mangler, eller VPN-et ikke bærer den, feiler connectoren mens den lokale lytteren fortsatt sitter der og lytter, og det er den forvirrende delen.
Den beskytter heller ikke strekket mellom applikasjonen din og proxyen. På én laptop er det strekket loopback og helt greit. Hvis du binder lytteren til en wildcard-adresse slik at en kollega kan nå den, har du bygget en uautentisert databaseport og kalt det en bekvemmelighet. Hold den på loopback og la kollegaen skaffe sin egen legitimasjon.
Og den gjør ikke Private Service Connect og private services access utbyttbare. En PSC-instans trenger sitt eget DNS-oppsett og --psc-kallet i stedet for --private-ip-formen.
Velge, og deretter verifisere uansett
Velg proxyen når du vil ha IAM i veien, kortlivede legitimasjoner og ingen endring av inngående brannmur.
Velg den direkte ruten når en støttet klient allerede har sterke databaselegitimasjoner og nettverksteamet er komfortabelt med å åpne porten. Uansett bør du verifisere med en ekte spørring i stedet for en vellykket tilkobling: koble til, kjør én lesing mot en kjent tabell og sjekk hva serveren ser om økten din.
Etter en VPN-gjenoppkobling bør du behandle utløpt legitimasjon, en manglende privat rute og en avvist databaselogginn som tre forskjellige feil. Bare én av dem er et nettverksproblem, og bare én bør noen gang føre til at en brannmurregel endres.