Cloud SQL Auth Proxy verzus priama VPN trasa k databáze
Auth Proxy a priama VPN trasa riešia rôzne polovice toho istého problému. Najprv porovnajte autorizáciu konektora, porty a prihlásenie do databázy.
K súkromnej inštancii Cloud SQL sa z notebooku na VPN dá rozumne dostať dvoma spôsobmi. Jeden je priame pripojenie na súkromnú adresu inštancie po trase, ktorú už máte. Druhý je Cloud SQL Auth Proxy, ktorý načúva na loopbacku a spojenie do Cloud SQL otvára sám. Nie sú to ani tak konkurenčné produkty ako dve rôzne odpovede na otázku, kto drží prihlasovacie údaje a kto drží trasu. Nesprávna voľba sa zvyčajne prejaví ako chyba autorizácie, ktorá sa číta ako chyba siete.
Toto je porovnanie, ktoré by som položil pred tím, a za ním kontroly, ktoré to skutočne rozhodnú.
Dve cesty k tej istej inštancii
Priama cesta používa trasu private-services-access z vašej siete do VPC projektu. Váš klient hovorí PostgreSQL so súkromnou adresou inštancie a spojenie žije alebo umiera na routingu, pravidlách firewallu a prihlasovacích údajoch databázy.
Cesta cez proxy používa rovnakú trasu, ale pridáva lokálny proces. Proxy sa autentizuje voči Google API pomocou predvolených prihlasovacích údajov aplikácie, otvorí spojenie s inštanciou cez konektor a vystaví port loopbacku, ktorý váš klient považuje za PostgreSQL. Dva skoky sa stanú tromi a ten prostredný nesie autorizáciu IAM. Trasu VPN si stále musíte udržiavať sami a proxy ju nikdy nepovažuje za náhradu tejto kontroly.
Čo ktorá cesta skutočne autorizuje
Najviac záleží na tom, čo za vás ktorá voľba môže autorizovať:
| 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 |
Kontrola IAM na proxy a prihlásenie do databázy sú oddelené brány a prechod jednou neotvorí druhú. Tím, ktorý proxy zapne a predpokladá, že účet aplikácie už nie je potrebný, strávi popoludnie na chybách hesiel, ktoré so sieťou nemajú nič spoločné.
Porty a trasy vedľa seba
Proxy potrebuje odchádzajúci TCP 443 pre API a TCP 3307 pre spojenie s inštanciou, oboje je opísané v prehľade Auth Proxy. Vaša trasa VPN pokrýva druhé; prvé zvyčajne odchádza bežnou cestou.
Priame pripojenie potrebuje, aby bol port PostgreSQL inštancie dostupný cez súkromnú trasu, čo je iná firewallová debata. Ak váš sieťový tím povoľuje len odchádzajúci 443 z klientskych podsietí, proxy sa vmestí bez zmeny pravidla a priama cesta nie. Tento jediný fakt rozhoduje voľbu častejšie než akákoľvek architektonická preferencia.
Ani jedna cesta nevyžaduje, aby inštancia mala verejnú adresu, a ani jedna neodôvodňuje jej pridanie.
Kde proxy nepomôže
Proxy neopraví chýbajúcu trasu. Ak trasa private-services-access chýba alebo ju VPN neprenáša, konektor zlyhá, zatiaľ čo lokálny poslucháč tam stále sedí a načúva, a to je tá mätúca časť.
Nechráni ani úsek medzi vašou aplikáciou a proxy. Na jednom notebooku je tento úsek loopback a je to v poriadku. Ak poslucháč naviažete na adresu wildcard, aby sa k nemu kolega dostal, postavili ste neautentizovanú bránu k databáze a nazvali to pohodlím. Nechajte ho na loopbacku a nechajte kolegu získať vlastné prihlasovacie údaje.
A nerobí z Private Service Connect a private services access zameniteľné veci. Inštancia PSC potrebuje vlastné usporiadanie DNS a volanie --psc namiesto podoby --private-ip.
Vybrať a potom tak či tak overiť
Zvoľte proxy, keď chcete IAM v ceste, krátkodobé prihlasovacie údaje a žiadnu zmenu prichádzajúceho firewallu.
Zvoľte priamu trasu, keď podporovaný klient už má silné prihlasovacie údaje k databáze a sieťový tím je ochotný port otvoriť. V oboch prípadoch overujte skutočnou požiadavkou, nie úspešným pripojením: pripojte sa, spustite jedno čítanie nad známou tabuľkou a skontrolujte, čo server o vašej relácii vidí.
Po opätovnom pripojení VPN berte prepísané prihlasovacie údaje, chýbajúcu súkromnú trasu a odmietnutie prihlásenia do databázy ako tri rôzne poruchy. Iba jedna z nich je sieťový problém a iba jedna by niekedy mala viesť k zmene pravidla firewallu.