Cloud SQL Auth Proxy nasuprot direktnoj VPN ruti do baze podataka
Auth Proxy i direktna VPN ruta rješavaju različite polovine istog problema. Prvo uporedite autorizaciju konektora, portove i prijavu na bazu podataka.
Postoje dva razumna načina da sa laptopa na VPN-u dođete do privatne Cloud SQL instance. Jedan je direktna veza na privatnu adresu instance preko rute koju već imate. Drugi je Cloud SQL Auth Proxy, koji sluša na loopback-u i sam otvara vezu prema Cloud SQL-u. Oni nisu toliko konkurentski proizvodi koliko dva različita odgovora na pitanje ko drži akreditive, a ko drži rutu. Loš izbor se obično pojavi kao greška autorizacije koja se čita kao mrežna greška.
Evo poređenja koje bih stavio pred tim, a zatim provjera koje zaista odlučuju.
Dva puta do iste instance
Direktan put koristi rutu private-services-access iz vaše mreže u VPC projekta. Vaš klijent govori PostgreSQL sa privatnom adresom instance, a veza živi ili umire na rutiranju, firewall pravilima i akreditivima baze podataka.
Put preko proxyja koristi istu rutu, ali dodaje lokalni proces. Proxy se autentifikuje na Google API sa default akreditivima vaše aplikacije, otvara vezu prema instanci preko konektora i izlaže loopback port koji vaš klijent tretira kao PostgreSQL. Dva skoka postaju tri, a srednji nosi IAM autorizaciju. VPN ruta i dalje ostaje vaša za održavanje, a proxy je nikada ne smatra zamjenom za tu provjeru.
Šta svaki put zaista autorizuje
Najvažnija razlika je šta svaka opcija može autorizovati umjesto vas:
| 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 |
Proxy IAM provjera i prijava na bazu podataka su odvojene kapije i prolaz kroz jednu ne otvara drugu. Tim koji uključi proxy i pretpostavi da račun aplikacije više nije potreban potrošiće popodne na greške s lozinkama koje nemaju nikakve veze s mrežom.
Portovi i rute, jedno uz drugo
Proxyju treba odlazni TCP 443 za API i TCP 3307 za vezu s instancom, a oboje je opisano u Google-ovom pregledu Auth Proxyja. Vaša VPN ruta pokriva drugo; prvo obično izlazi uobičajenim putem.
Direktna veza traži da PostgreSQL port instance bude dostupan preko privatne rute, što je sasvim drugi firewall razgovor. Ako vaš mrežni tim dozvoljava samo odlazni 443 sa klijentskih podmreža, proxy se uklapa bez promjene pravila, a direktan put ne. Ta jedna činjenica odlučuje izbor češće od bilo koje arhitektonske preferencije.
Nijedan put ne traži da instanca ima javnu adresu, i nijedan ne opravdava dodavanje iste.
Gdje proxy ne pomaže
Proxy ne ispravlja rutu koja nedostaje. Ako ruta private-services-access nedostaje ili je VPN ne prenosi, konektor pada dok lokalni slušalac i dalje sjedi i sluša, i to je zbunjujući dio.
On takođe ne štiti dio između vaše aplikacije i proxyja. Na jednom laptopu taj dio je loopback i to je u redu. Ako slušalac vežete na wildcard adresu da bi kolega mogao do njega, napravili ste neautentifikovani gateway do baze podataka i nazvali ga pogodnošću. Držite ga na loopback-u i pustite kolegu da pribavi sopstvene akreditive.
I ne čini Private Service Connect i private services access zamjenjivim. PSC instanca treba sopstveni DNS raspored i poziv --psc umjesto oblika --private-ip.
Izbor, a zatim provjera u svakom slučaju
Izaberite proxy kada želite IAM u putu, kratkotrajne akreditive i nikakvu promjenu dolaznog firewall-a.
Izaberite direktnu rutu kada podržani klijent već ima jake akreditive baze i mrežni tim je spreman otvoriti port. U svakom slučaju provjerite pravim upitom, a ne uspješnom vezom: povežite se, izvršite jedno čitanje nad poznatom tabelom i provjerite šta server vidi za vašu sesiju.
Nakon ponovnog povezivanja VPN-a tretirajte istekle akreditive, rutu koja nedostaje i odbijanje prijave na bazu kao tri različita kvara. Samo jedan od njih je mrežni problem, i samo jedan bi ikada trebao dovesti do promjene firewall pravila.