Cloud SQL Auth Proxy proti neposredni poti VPN do podatkovne baze
Auth Proxy in neposredna pot VPN rešujeta različni polovici iste težave. Najprej primerjajte avtorizacijo konektorja, vrata in prijavo v podatkovno bazo.
Do zasebnega primerka Cloud SQL lahko s prenosnega računalnika v VPN pridete na dva smiselna načina. Eden je neposredna povezava na zasebni naslov primerka po poti, ki jo že imate. Drugi je Cloud SQL Auth Proxy, ki posluša na loopback in sam odpre povezavo do Cloud SQL. To nista toliko konkurenčna izdelka kot dva različna odgovora na vprašanje, kdo ima poverilnice in kdo ima pot. Napačna izbira se običajno pokaže kot napaka avtorizacije, ki se bere kot omrežna napaka.
Tu je primerjava, ki bi jo postavil pred ekipo, za njo pa preverjanja, ki jo resnično odločijo.
Dve poti do istega primerka
Neposredna pot uporablja pot private-services-access iz vašega omrežja v VPC projekta. Vaš odjemalec govori PostgreSQL z zasebnim naslovom primerka, povezava pa živi ali umre na usmerjanju, pravilih firewall in poverilnicah podatkovne baze.
Pot prek proxyja uporablja isto pot, vendar doda krajevni proces. Proxy se overi pri Google API s privzetimi poverilnicami vaše aplikacije, odpre povezavo do primerka prek konektorja in izpostavi vrata loopback, ki jih vaš odjemalec obravnava kot PostgreSQL. Dva skoka postaneta trije, srednji pa nosi avtorizacijo IAM. Pot VPN še vedno vzdržujete sami in proxy je nikoli ne šteje za nadomestilo tega preverjanja.
Kaj vsaka pot dejansko avtorizira
Najpomembnejša razlika je, kaj lahko posamezna možnost avtorizira namesto 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 |
Preverjanje IAM v proxyju in prijava v podatkovno bazo sta ločeni vrati in prehod skozi ena ne odpre drugih. Ekipa, ki vklopi proxy in domneva, da račun aplikacije ni več potreben, bo popoldne porabila za napake z gesli, ki nimajo nič skupnega z omrežjem.
Vrata in poti, drugo ob drugem
Proxy potrebuje odhodni TCP 443 za API in TCP 3307 za povezavo s primerkom, oboje je opisano v Googlovem pregledu Auth Proxy. Vaša pot VPN pokriva drugo; prvo običajno odide po običajni poti.
Neposredna povezava zahteva, da je vrata PostgreSQL primerka dosegljiva po zasebni poti, kar je povsem druga razprava o firewallu. Če vaša omrežna ekipa dovoljuje le odhodni 443 iz odjemalskih podomrežij, se proxy vklopi brez spremembe pravila, neposredna pot pa ne. To eno dejstvo odloči izbiro pogosteje kot kakršna koli arhitekturna preferenca.
Nobena od poti ne zahteva, da ima primerka javni naslov, in nobena ne opravičuje dodajanja takega.
Kjer proxy ne pomaga
Proxy ne popravi manjkajoče poti. Če pot private-services-access manjka ali je VPN ne prenaša, konektor odpove, medtem ko krajevni poslušalec še vedno sedi tam in posluša, in to je zmedeni del.
Prav tako ne ščiti odseka med vašo aplikacijo in proxyjem. Na enem prenosnem računalniku je ta odsek loopback in je v redu. Če poslušalec privežete na naslov wildcard, da ga lahko doseže sodelavec, ste zgradili neoverjeno prehod v podatkovno bazo in to poimenovali udobje. Ohranite ga na loopback in pustite sodelavcu, da pridobi svoje poverilnice.
In ne dela Private Service Connect in private services access medsebojno zamenljivih. Primerek PSC potrebuje svojo ureditev DNS in klic --psc namesto oblike --private-ip.
Izbrati in nato v vsakem primeru preveriti
Izberite proxy, ko želite IAM na poti, kratkotrajne poverilnice in nobene spremembe dohodnega firewalla.
Izberite neposredno pot, ko ima podprt odjemalec že močne poverilnice podatkovne baze in je omrežna ekipa pripravljena odpreti vrata. V vsakem primeru preverite s pravo poizvedbo, ne z uspešno povezavo: povežite se, izvedite eno branje na znani tabeli in poglejte, kaj strežnik vidi o vaši seji.
Po ponovnem povezovanju VPN obravnavajte potekle poverilnice, manjkajočo zasebno pot in zavrnitev prijave v podatkovno bazo kot tri različne okvare. Samo ena od njih je omrežna težava in samo ena bi kdaj morala privesti do spremembe pravila firewall.