Cloud SQL Auth Proxy sau o rută VPN directă către baza de date
Auth Proxy și o rută VPN directă rezolvă jumătăți diferite ale aceleiași probleme. Comparați mai întâi autorizarea conectorului, porturile și autentificarea în baza de date.
Există două moduri rezonabile de a ajunge la o instanță privată Cloud SQL de pe un laptop aflat în VPN. Unul este o conexiune directă la adresa privată a instanței prin ruta pe care o aveți deja. Celălalt este Cloud SQL Auth Proxy, care ascultă pe loopback și deschide el însuși conexiunea către Cloud SQL. Nu sunt atât produse concurente, cât două răspunsuri diferite la întrebarea cine deține acreditarea și cine deține ruta. O alegere greșită apare de obicei ca o eroare de autorizare care se citește ca o eroare de rețea.
Iată comparația pe care aș pune-o în fața unei echipe, urmată de verificările care o decid cu adevărat.
Două căi către aceeași instanță
Calea directă folosește ruta private-services-access din rețeaua dumneavoastră în VPC-ul proiectului. Clientul dumneavoastră vorbește PostgreSQL cu adresa privată a instanței, iar conexiunea trăiește sau moare pe rutare, reguli de firewall și acreditările bazei de date.
Calea prin proxy folosește aceeași rută dar adaugă un proces local. Proxy-ul se autentifică la Google API cu default credentials ale aplicației, deschide o conexiune la instanță prin conector și expune un port loopback pe care clientul dumneavoastră îl tratează ca PostgreSQL. Două salturi devin trei, iar cel din mijloc poartă autorizarea IAM. Ruta VPN rămâne a dumneavoastră de întreținut, iar proxy-ul nu o vede niciodată ca înlocuitor pentru acea verificare.
Ce autorizează de fapt fiecare cale
Cea mai importantă distincție este ce poate autoriza fiecare opțiune în locul dumneavoastră:
| 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 |
Verificarea IAM a proxy-ului și autentificarea în baza de date sunt două porți separate, iar trecerea prin una nu o deschide pe cealaltă. O echipă care activează proxy-ul și presupune că contul aplicației nu mai este necesar va petrece o după-amiază cu eșecuri de parolă care nu au nimic de-a face cu rețeaua.
Porturi și rute, alături
Proxy-ul are nevoie de TCP 443 de ieșire pentru API și TCP 3307 pentru conexiunea la instanță, ambele descrise în prezentarea generală a Auth Proxy Google. Ruta dumneavoastră VPN acoperă a doua; prima iese de obicei pe calea obișnuită.
O conexiune directă necesită ca portul PostgreSQL al instanței să fie accesibil prin ruta privată, ceea ce este o cu totul altă discuție despre firewall. Dacă echipa de rețea permite doar 443 de ieșire din subrețelele clienților, proxy-ul se potrivește fără schimbarea vreunei reguli, iar calea directă nu. Acest singur fapt decide alegerea mai des decât orice preferință arhitecturală.
Niciuna dintre căi nu cere ca instanța să aibă o adresă publică și niciuna nu justifică adăugarea uneia.
Unde proxy-ul nu ajută
Proxy-ul nu repară o rută lipsă. Dacă ruta private-services-access lipsește, sau VPN-ul nu o transportă, conectorul eșuează în timp ce ascultătorul local stă în continuare acolo și ascultă, iar aceasta este partea derutantă.
De asemenea, nu protejează segmentul dintre aplicația dumneavoastră și proxy. Pe un singur laptop acel segment este loopback și este în regulă. Dacă legați ascultătorul la o adresă wildcard ca un coleg să ajungă la el, ați construit o poartă de acces la baza de date fără autentificare și ați numit-o comoditate. Țineți-o pe loopback și lăsați colegul să obțină propria acreditare.
Și nu face Private Service Connect și private services access interschimbabile. O instanță PSC are nevoie de propria aranjare DNS și de apelul --psc în locul formei --private-ip.
Alegerea și apoi verificarea în orice caz
Alegeți proxy-ul când doriți IAM pe cale, acreditări de scurtă durată și nicio modificare a firewall-ului de intrare.
Alegeți ruta directă când un client acceptat are deja acreditări puternice pentru baza de date, iar echipa de rețea este dispusă să deschidă portul. În orice caz, verificați cu o interogare reală, nu cu o conexiune reușită: conectați-vă, rulați o citire pe un tabel cunoscut și verificați ce vede serverul despre sesiunea dumneavoastră.
După o reconectare VPN, tratați o acreditare expirată, o rută privată lipsă și un refuz de autentificare în baza de date ca trei defecțiuni diferite. Doar una este o problemă de rețea și doar una ar trebui să ducă vreodată la modificarea unei reguli de firewall.