Cloud SQL Auth Proxy nasuprot izravnoj VPN ruti do baze podataka
Auth Proxy i izravna VPN ruta rješavaju različite polovice istog problema. Najprije usporedite autorizaciju konektora, portove i prijavu u bazu podataka.
Postoje dva razumna načina da s prijenosnog računala na VPN-u dođete do privatne Cloud SQL instance. Jedan je izravna veza na privatnu adresu instance preko rute koju već imate. Drugi je Cloud SQL Auth Proxy, koji sluša na loopbacku i sam otvara vezu prema Cloud SQL-u. Oni nisu toliko konkurentski proizvodi koliko dva različita odgovora na pitanje tko drži vjerodajnice, a tko drži rutu. Loš odabir obično se pojavi kao pogreška autorizacije koja se čita kao mrežna pogreška.
Ovo je usporedba koju bih stavio pred tim, a zatim provjere koje je doista odlučuju.
Dva puta do iste instance
Izravni put koristi rutu private-services-access iz vaše mreže u VPC projekta. Vaš klijent govori PostgreSQL s privatnom adresom instance, a veza živi ili umire na usmjeravanju, firewall pravilima i vjerodajnicama baze podataka.
Put preko proxyja koristi istu rutu ali dodaje lokalni proces. Proxy se autentificira na Google API s default vjerodajnicama 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.
Što svaki put zapravo autorizira
Najvažnija je razlika što koja opcija može autorizirati 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 |
Proxyjeva IAM provjera i prijava u bazu podataka dvije 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šit će poslijepodne na pogreš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 Googleovom pregledu Auth Proxyja. Vaša VPN ruta pokriva drugo; prvo obično izlazi uobičajenim putem.
Izravna veza zahtijeva da PostgreSQL port instance bude dostupan preko privatne rute, što je sasvim drugi firewall razgovor. Ako vaš mrežni tim dopušta samo odlazni 443 s klijentskih podmreža, proxy se uklapa bez promjene pravila, a izravni put ne. Ta jedna činjenica odlučuje odabir češće od bilo koje arhitektonske preferencije.
Nijedan put ne zahtijeva da instanca ima javnu adresu i nijedan ne opravdava dodavanje iste.
Gdje proxy ne pomaže
Proxy ne popravlja rutu koja nedostaje. Ako ruta private-services-access nedostaje ili je VPN ne prenosi, konektor pada dok lokalni slušatelj i dalje sjedi i sluša, i to je zbunjujući dio.
On također ne štiti dio između vaše aplikacije i proxyja. Na jednom prijenosnom računalu taj je dio loopback i u redu je. Ako slušatelj vežete na wildcard adresu da bi kolega mogao do njega, izgradili ste neautentificirani pristupnik baze podataka i nazvali ga pogodnošću. Držite ga na loopbacku i pustite kolegu da pribavi vlastite vjerodajnice.
I ne čini Private Service Connect i private services access međusobno zamjenjivima. PSC instanca treba vlastiti DNS raspored i poziv --psc umjesto oblika --private-ip.
Odabir, a zatim provjera u svakom slučaju
Odaberite proxy kada želite IAM na putu, kratkotrajne vjerodajnice i nikakvu promjenu dolaznog firewalla.
Odaberite izravnu rutu kada podržani klijent već ima jake vjerodajnice baze podataka 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 tablicom i provjerite što poslužitelj vidi za vašu sesiju.
Nakon ponovnog povezivanja VPN-a tretirajte istekle vjerodajnice, rutu koja nedostaje i odbijanje prijave u bazu kao tri različita kvara. Samo je jedan od njih mrežni problem i samo bi jedan ikada trebao dovesti do promjene firewall pravila.