Cloud SQL Auth Proxy mot ein direkte VPN-rute til databasen
Auth Proxy og ein direkte VPN-rute løyser ulike halvdelar av same problem. Samanlikn først connector-autorisasjon, portar og databaselogginn.
Det finst to fornuftige måtar å nå ein privat Cloud SQL-instans frå ein laptop på VPN-et. Den eine er ei direkte tilkopling til den private adressa til instansen over ruta du allereie har. Den andre er Cloud SQL Auth Proxy, som lyttar på loopback og opnar tilkoplinga til Cloud SQL sjølv. Dei er mindre konkurrerande produkt enn to ulike svar på kven som held legitimasjonen og kven som held ruta. Eit dårleg val viser seg vanlegvis som ein autorisasjonsfeil som blir lesen som ein nettverksfeil.
Her er samanlikninga eg ville lagt framfor eit team, etterfølgd av kontrollane som faktisk avgjer ho.
To vegar til same instans
Den direkte vegen brukar private-services-access-ruta frå nettverket ditt inn i VPC-en til prosjektet. Klienten din snakkar PostgreSQL med den private adressa til instansen, og tilkoplinga lever eller døyr på ruting, brannmurreglar og databasens legitimasjon.
Proxy-vegen brukar same ruta, men legg til ein lokal prosess. Proxyen autentiserer seg mot Google API med applikasjonen sin default credentials, opnar ei tilkopling til instansen over connectoren og eksponerer ein loopback-port som klienten din behandlar som PostgreSQL. To hopp blir tre, og det midtarste ber IAM-autorisasjon. VPN-ruta er framleis di å vedlikehalde, og proxyen ser ho aldri som ei erstatning for den kontrollen.
Kva kvar veg faktisk autoriserer
Den viktigaste skilnaden er kva kvart alternativ kan autorisere på dine vegner:
| 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 |
IAM-kontrollen til proxyen og databaselogginnet er to separate portar, og å passere den eine opnar ikkje den andre. Eit team som slår på proxyen og reknar med at applikasjonskontoen no er overflødig, brukar ein ettermiddag på passordfeil som ikkje har noko med nettverk å gjere.
Portar og ruter side om side
Proxyen treng utgåande TCP 443 for API-et og TCP 3307 for instanstilkoplinga, begge skildra i Google sin oversikt over Auth Proxy. VPN-ruta di dekkjer den andre; den første går normalt ut den vanlege vegen.
Ei direkte tilkopling krev at PostgreSQL-porten til instansen er nåbar over den private ruta, noko som er ein heilt annan brannmursamtale. Viss nettverksteamet ditt berre tillèt utgåande 443 frå klient-subnett, passar proxyen utan regelendring og den direkte vegen gjer det ikkje. Det eine faktumet avgjer valet oftare enn noka arkitektonisk preferanse.
Ingen av vegane krev at instansen har ei offentleg adresse, og ingen av dei rettferdiggjer å leggje til ei.
Der proxyen ikkje hjelper
Proxyen reparerer ikkje ei manglande rute. Viss private-services-access-ruta manglar, eller VPN-et ikkje ber ho, feilar connectoren medan den lokale lyttaren framleis sit der og lyttar, og det er den forvirrande delen.
Han vernar heller ikkje strekket mellom applikasjonen din og proxyen. På éin laptop er det strekket loopback og heilt greitt. Viss du bind lyttaren til ei wildcard-adresse slik at ein kollega kan nå han, har du bygd ein uautentisert databaseport og kalla det ei bekvemmelegheit. Hald han på loopback og lat kollegaen skaffe sin eigen legitimasjon.
Og han gjer ikkje Private Service Connect og private services access utbyttbare. Ein PSC-instans treng sitt eige DNS-oppsett og --psc-kallet i staden for --private-ip-forma.
Velje, og deretter stadfeste uansett
Vel proxyen når du vil ha IAM i vegen, kortliva legitimasjon og inga endring av inngåande brannmur.
Vel den direkte ruta når ein støtta klient allereie har sterk databaselegitimasjon og nettverksteamet er komfortabelt med å opne porten. Uansett bør du stadfeste med ei ekte spørjing i staden for ei vellukka tilkopling: kople til, køyr éi lesing mot ein kjend tabell og sjå kva tenaren ser om økta di.
Etter ein VPN-gjenoppkopling bør du handsame utlopen legitimasjon, ei manglande privat rute og eit avvist databaselogginn som tre ulike feil. Berre éin av dei er eit nettverksproblem, og berre éin bør nokosinne føre til at ein brannmurregel blir endra.