Cloud SQL Auth Proxy vai suora VPN-reitti tietokantaan
Auth Proxy ja suora VPN-reitti ratkaisevat saman ongelman eri puoliskot. Vertaa ensin konnektorin valtuutusta, portteja ja tietokantakirjautumista.
Yksityiseen Cloud SQL -instanssiin on kaksi järkevää tapaa VPN:ssä olevalta kannettavalta. Toinen on suora yhteys instanssin yksityiseen osoitteeseen reittiä, joka sinulla jo on. Toinen on Cloud SQL Auth Proxy, joka kuuntelee loopbackissa ja avaa yhteyden Cloud SQL:ään itse. Ne eivät ole niinkään kilpailevia tuotteita kuin kaksi eri vastausta siihen, kuka pitää tunnukset ja kuka pitää reitin. Huono valinta näkyy yleensä valtuutusvirheenä, joka luetaan verkkovirheeksi.
Tässä on vertailu, jonka laittaisin tiimin eteen, ja sen perässä tarkistukset, jotka sen todella ratkaisevat.
Kaksi polkua samaan instanssiin
Suora polku käyttää private-services-access-reittiä verkostasi projektin VPC:hen. Asiakkaasi puhuu PostgreSQL:ää instanssin yksityisen osoitteen kanssa, ja yhteys elää tai kuolee reitityksen, firewall-sääntöjen ja tietokannan tunnusten varassa.
Proxy-polku käyttää samaa reittiä mutta lisää paikallisen prosessin. Proxy todentaa itsensä Google API:in sovelluksesi default credentials -tunnuksilla, avaa yhteyden instanssiin konnektorin kautta ja tarjoaa loopback-portin, jota asiakkaasi käsittelee PostgreSQL:nä. Kahdesta hypystä tulee kolme, ja keskimmäinen kantaa IAM-valtuutuksen. VPN-reitti on edelleen sinun ylläpidettäväsi, eikä proxy koskaan pidä sitä tuon tarkistuksen korvaajana.
Mitä kukin polku todella valtuuttaa
Tärkein ero on se, mitä kukin vaihtoehto voi valtuuttaa puolestasi:
| 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 |
Proxyn IAM-tarkistus ja tietokantakirjautuminen ovat erilliset portit, eikä yhdestä läpi pääseminen avaa toista. Tiimi, joka ottaa proxyn käyttöön ja olettaa, ettei sovellustunnusta enää tarvita, viettää iltapäivän salasanavirheiden parissa, joilla ei ole mitään tekemistä verkon kanssa.
Portit ja reitit rinnakkain
Proxy tarvitsee lähtevän TCP 443:n API:lle ja TCP 3307:n instanssiyhteydelle, molemmat kuvattu Googlen Auth Proxy -yleiskatsauksessa. VPN-reittisi kattaa jälkimmäisen; ensimmäinen lähtee yleensä tavallista polkua.
Suora yhteys vaatii, että instanssin PostgreSQL-portti on tavoitettavissa yksityisen reitin kautta, mikä on aivan toinen firewall-keskustelu. Jos verkkotiimisi sallii asiakasaliverkoista vain lähtevän 443:n, proxy sopii ilman säännön muutosta eikä suora polku sovi. Tämä yksi seikka ratkaisee valinnan useammin kuin mikään arkkitehtoninen mieltymys.
Kumpikaan polku ei vaadi, että instanssilla on julkinen osoite, eikä kumpikaan perustele sellaisen lisäämistä.
Missä proxystä ei ole apua
Proxy ei korjaa puuttuvaa reittiä. Jos private-services-access-reitti puuttuu tai VPN ei kuljeta sitä, konnektori epäonnistuu, kun taas paikallinen kuuntelija istuu edelleen siinä kuuntelemassa, ja se on se hämmentävä osa.
Se ei myöskään suojaa osuutta sovelluksesi ja proxyn välillä. Yhdellä kannettavalla tuo osuus on loopback ja kunnossa. Jos sitot kuuntelijan wildcard-osoitteeseen, jotta kollega pääsee siihen, olet rakentanut todentamattoman tietokantayhdyskäytävän ja kutsunut sitä mukavuudeksi. Pidä se loopbackissa ja anna kollegan hankkia omat tunnuksensa.
Eikä se tee Private Service Connectista ja private services accessista keskenään vaihdettavia. PSC-instanssi tarvitsee oman DNS-järjestelynsä ja --psc-kutsun --private-ip-muodon sijaan.
Valinta ja sitten varmistus kummassakin tapauksessa
Valitse proxy, kun haluat IAM:n polulle, lyhytikäiset tunnukset eikä muutosta saapuvaan firewallsä.
Valitse suora reitti, kun tuettu asiakas pitää jo hallussaan vahvat tietokantatunnukset ja verkkotiimi on valmis avaamaan portin. Varmista kummassakin tapauksessa oikealla kyselyllä eikä onnistuneella yhteydellä: yhdistä, aja yksi luku tunnettua taulua vastaan ja katso, mitä palvelin näkee istunnostasi.
Kun VPN yhdistetään uudelleen, käsittele vanhentunut tunnus, puuttuva yksityinen reitti ja tietokantakirjautumisen hylkäys kolmena eri vikana. Vain yksi niistä on verkko-ongelma, ja vain yhden pitäisi koskaan johtaa firewall-säännön muuttamiseen.