Cloud SQL Auth Proxy kumpara sa direktang ruta ng VPN patungo sa database
Ang Auth Proxy at direktang ruta ng VPN ay nag-aayos ng magkaibang kalahati ng parehong problema. Ihambing muna ang awtorisasyon ng connector, mga port at pag-login sa database.
May dalawang makatwirang paraan upang maabot ang isang pribadong Cloud SQL instance mula sa laptop na nasa VPN. Ang isa ay direktang koneksyon sa pribadong address ng instance sa rutang mayroon ka na. Ang isa pa ay ang Cloud SQL Auth Proxy, na nakikinig sa loopback at siya mismo ang nagbubukas ng koneksyon sa Cloud SQL. Hindi sila gaanong magkaribal na produkto kundi dalawang magkaibang sagot sa tanong kung sino ang may hawak ng kredensyal at sino ang may hawak ng ruta. Ang maling pagpili ay karaniwang lumalabas bilang error sa awtorisasyon na binabasa na parang error sa network.
Narito ang paghahambing na ilalagay ko sa harap ng isang team, kasunod ang mga pagsusuring talagang nagpapasya.
Dalawang landas patungo sa parehong instance
Ginagamit ng direktang landas ang rutang private-services-access mula sa iyong network papunta sa VPC ng proyekto. Ang iyong kliyente ay nagsasalita ng PostgreSQL sa pribadong address ng instance, at ang koneksyon ay nabubuhay o namamatay sa routing, mga patakaran ng firewall at mga kredensyal ng database.
Ginagamit ng landas ng proxy ang parehong ruta ngunit nagdaragdag ng lokal na proseso. Nagpapatotoo ang proxy sa Google API gamit ang default credentials ng iyong aplikasyon, nagbubukas ng koneksyon sa instance sa pamamagitan ng connector, at naglalantad ng port ng loopback na itinuturing ng iyong kliyente na PostgreSQL. Dalawang pagtalon ang nagiging tatlo, at ang nasa gitna ang nagdadala ng awtorisasyong IAM. Ang ruta ng VPN ay para pa rin sa iyong pagpapanatili, at hindi ito itinuturing ng proxy na kapalit ng pagsusuring iyon.
Ano ang aktuwal na awtorisasyon ng bawat landas
Ang pinakamahalagang pagkakaiba ay kung ano ang maaaring awtorisahan ng bawat opsyon para sa iyo:
| 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 |
Ang pagsusuri ng IAM ng proxy at ang pag-login sa database ay dalawang magkaibang pintuan, at ang pagdaan sa isa ay hindi nagbubukas ng isa pa. Ang team na magbukas ng proxy at mag-akalang hindi na kailangan ang account ng aplikasyon ay gugugol ng isang hapon sa mga pagkabigo sa password na walang kinalaman sa networking.
Mga port at ruta, magkatabi
Kailangan ng proxy ng palabas na TCP 443 para sa API at TCP 3307 para sa koneksyon ng instance, parehong inilarawan sa pangkalahatang-tanaw ng Auth Proxy ng Google. Sinasaklaw ng iyong ruta ng VPN ang pangalawa; ang una ay karaniwang lumalabas sa karaniwang landas.
Kailangan ng direktang koneksyon na maabot ang port ng PostgreSQL ng instance sa pribadong ruta, na isang ganap na ibang usapan sa firewall. Kung pinapayagan lamang ng iyong team sa network ang palabas na 443 mula sa mga subnet ng kliyente, kasya ang proxy nang walang pagbabago sa patakaran at hindi kasya ang direktang landas. Ang nag-iisang katotohanang iyon ang nagpapasya sa pagpili nang mas madalas kaysa sa anumang kagustuhang arkitektural.
Wala sa dalawang landas ang nangangailangan na ang instance ay may pampublikong address, at wala sa kanila ang nagbibigay-katwiran na magdagdag ng isa.
Kung saan hindi tumutulong ang proxy
Hindi inaayos ng proxy ang nawawalang ruta. Kung wala ang rutang private-services-access, o hindi ito dinadala ng VPN, nabibigo ang connector habang ang lokal na tagapakinig ay nakaupo pa rin doon at nakikinig, at iyon ang nakakalitong bahagi.
Hindi rin nito pinoprotektahan ang bahagi sa pagitan ng iyong aplikasyon at ng proxy. Sa isang laptop, ang bahaging iyon ay loopback at ayos lang. Kung itatali mo ang tagapakinig sa isang wildcard address upang maabot ito ng kasamahan, nakagawa ka ng gateway ng database na walang pagpapatotoo at tinawag itong kaginhawahan. Panatilihin ito sa loopback at hayaang ang kasamahan ang kumuha ng sarili nitong kredensyal.
At hindi nito ginagawang mapagpapalit ang Private Service Connect at private services access. Kailangan ng PSC instance ang sarili nitong kaayusan sa DNS at ang tawag na --psc sa halip na ang anyo ng --private-ip.
Pumili, pagkatapos ay i-verify sa alinmang paraan
Piliin ang proxy kapag gusto mo ng IAM sa landas, panandaliang kredensyal at walang pagbabago sa papasok na firewall.
Piliin ang direktang ruta kapag ang isang sinusuportahang kliyente ay may matibay nang kredensyal sa database at komportable ang team sa network na buksan ang port. Sa alinmang paraan, i-verify gamit ang tunay na query sa halip na matagumpay na koneksyon: kumonekta, magpatakbo ng isang pagbasa sa isang kilalang table at tingnan kung ano ang nakikita ng server tungkol sa iyong session.
Pagkatapos ng muling pagkonekta ng VPN, ituring ang nag-expire na kredensyal, nawawalang pribadong ruta at pagtanggi sa pag-login sa database bilang tatlong magkaibang pagkabigo. Isa lamang sa kanila ang problema sa network, at isa lamang ang dapat kailanman humantong sa pagbabago ng patakaran ng firewall.