Cloud SQL Auth Proxy edo VPN bide zuzena datu-basera
Auth Proxy-ak eta VPN bide zuzenak arazo beraren erdi desberdinak konpontzen dituzte. Konparatu lehenengo konektorearen baimena, portuak eta datu-basera sartzeko saioa.
Bi modu zentzuzko daude VPN-an dagoen eramangarri batetik Cloud SQL instantzia pribatu batera heltzeko. Bata instantziaren helbide pribaturako konexio zuzena da, jada duzun bidearen bidez. Bestea Cloud SQL Auth Proxy da, loopback-en entzuten duena eta Cloud SQL-rako konexioa berak irekitzen duena. Ez dira hainbeste produktu lehiakideak nork gordetzen duen kredentziala eta nork bidea galderari emandako bi erantzun desberdin baizik. Aukera txarra autorizazio-errore gisa agertzen da normalean, sare-errore gisa irakurtzen dena.
Hauxe da talde baten aurrean jarriko nukeen konparazioa, eta ondoren benetan erabakitzen duten egiaztapenak.
Bi bide instantzia berera
Bide zuzenak zure saretik proiektuaren VPC-ra doan private-services-access bidea erabiltzen du. Zure bezeroak PostgreSQL hizkuntzan hitz egiten du instantziaren helbide pribatuarekin, eta konexioa bideratzean, firewall arauetan eta datu-baseko kredentzialetan bizi edo hiltzen da.
Proxy bideak bide bera erabiltzen du, baina tokiko prozesu bat gehitzen du. Proxyak Google API-rekin autentifikatzen da zure aplikazioaren default credentials erabiliz, konektorearen bidez instantziarako konexioa irekitzen du eta zure bezeroak PostgreSQL gisa tratatzen duen loopback portu bat erakusten du. Bi jauzi hiru bihurtzen dira, eta erdikoak IAM autorizazioa darama. VPN bidea zurea da oraindik mantentzeko, eta proxyak ez du inoiz egiaztapen horren ordezko gisa hartzen.
Zer baimendu egiten duen bide bakoitzak
Diferentziarik garrantzitsuena da zer baimendu dezakeen aukera bakoitzak zure ordez:
| 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 |
Proxyaren IAM egiaztapena eta datu-basera sartzeko saioa ate bereiziak dira, eta batetik igarotzeak ez du bestea irekitzen. Proxy-a piztu eta aplikazioaren kontua orain beharrezkoa ez dela uste duen talde batek arratsalde bat emango du sarearekin zerikusirik ez duten pasahitz hutsegiteekin.
Portuak eta bideak, alboz albo
Proxyak TCP 443 irteera behar du APIrako eta TCP 3307 instantziaren konexiorako, biak Google-ren Auth Proxy-ren ikuspegi orokorra atalean deskribatuta. Zure VPN bideak bigarrena hartzen du; lehenengoa bide arruntetik ateratzen da normalean.
Konexio zuzenak instantziaren PostgreSQL portua bide pribatuaren bidez irisgarria izatea behar du, eta hori firewall elkarrizketa guztiz bestelakoa da. Zure sare-taldeak bezeroen azpisareetatik 443 irteera soilik onartzen badu, proxy-a arau aldaketarik gabe egokitzen da eta bide zuzena ez. Gertaera bakar horrek erabakitzen du aukera edozein lehentasun arkitektonikok baino sarriago.
Bi bideetako batek ere ez du eskatzen instantziak helbide publikoa izatea, eta batek ere ez du bat gehitzea justifikatzen.
Proxyak laguntzen ez duen tokia
Proxyak ez du falta den bidea konpontzen. private-services-access bidea falta bada, edo VPN-ak ez badu eramaten, konektoreak huts egiten du tokiko entzulea oraindik han eserita entzuten ari den bitartean, eta hori da nahasgarria den zatia.
Ez du babesten, halaber, zure aplikazioaren eta proxyaren arteko zatia. Eramangarri batean zati hori loopback da eta ondo dago. Entzulea wildcard helbide batera lotzen baduzu lankideak hara iritsi ahal izateko, autentifikaziorik gabeko datu-base atebide bat eraiki duzu eta erosotasuna deitu diozu. Eutsi loopback-en eta utzi lankideari bere kredentzialak lortzen.
Eta ez ditu Private Service Connect eta private services access trukagarri egiten. PSC instantzia batek bere DNS antolamendua eta --psc deialdia behar ditu, --private-ip formaren ordez.
Aukeratu eta gero egiaztatu, edonola ere
Aukeratu proxy-a IAM bidean nahi duzunean, iraupen laburreko kredentzialak eta sarrerako firewallean aldaketarik ez.
Aukeratu bide zuzena onartutako bezero batek jada datu-baseko kredentzial sendoak dituenean eta sare-taldea portua irekitzeko prest dagoenean. Edonola ere, egiaztatu benetako kontsulta batekin, konexio arrakastatsu batekin baino: konektatu, exekutatu irakurketa bat ezagutzen duzun taula baten aurka, eta ikusi zer ikusten duen zerbitzariak zure saioaz.
VPN berriro konektatu ondoren, tratatu iraungitako kredentziala, falta den bide pribatua eta datu-basera sartzeko ukoa hiru hutsegite desberdin gisa. Horietako bat bakarrik da sare-arazoa, eta batek bakarrik ekarri beharko luke firewall arau bat aldatzea.