Cloud SQL Auth Proxy versus otsene VPN-marsruut andmebaasini
Auth Proxy ja otsene VPN-marsruut lahendavad sama probleemi eri pooli. Kõigepealt võrrelge konnektori autoriseerimist, porte ja andmebaasi sisselogimist.
Privaatse Cloud SQL-i eksemplarini on VPN-is olevast sülearvutist kaks mõistlikku teed. Üks on otsene ühendus eksemplari privaatse aadressiga marsruudil, mis teil juba olemas on. Teine on Cloud SQL Auth Proxy, mis kuulab loopbackil ja avab ise ühenduse Cloud SQL-iga. Need pole niivõrd konkureerivad tooted kuivõrd kaks erinevat vastust küsimusele, kes hoiab mandaate ja kes hoiab marsruuti. Halb valik ilmneb tavaliselt autoriseerimisveana, mida loetakse võrguveana.
Siin on võrdlus, mille ma meeskonna ette paneksin, millele järgnevad kontrollid, mis selle tegelikult otsustavad.
Kaks teed sama eksemplarini
Otsene tee kasutab private-services-access marsruuti teie võrgust projekti VPC-sse. Teie klient räägib PostgreSQL-i eksemplari privaatse aadressiga ning ühendus elab või sureb marsruutimise, firewall-reeglite ja andmebaasi mandaatide peal.
Puhverserveri tee kasutab sama marsruuti, kuid lisab kohaliku protsessi. Puhverserver autendib end Google API ees rakenduse default credentials abil, avab konnektori kaudu ühenduse eksemplariga ja pakub loopback-porti, mida teie klient käsitleb PostgreSQL-ina. Kaks hüpet saavad kolmeks ja keskmine kannab IAM-autoriseerimist. VPN-marsruut jääb endiselt teie hooldada ning puhverserver ei pea seda kunagi selle kontrolli asendajaks.
Mida kumbki tee tegelikult autoriseerib
Kõige olulisem erinevus on see, mida kumbki valik teie eest autoriseerida suudab:
| 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 |
Puhverserveri IAM-kontroll ja andmebaasi sisselogimine on eraldi väravad ning ühest läbiminek ei ava teist. Meeskond, kes lülitab puhverserveri sisse ja eeldab, et rakenduse konto pole enam vajalik, veedab pärastlõuna paroolitõrgetega, millel pole võrguga mingit pistmist.
Pordid ja marsruudid kõrvuti
Puhverserver vajab väljuvat TCP 443 API jaoks ja TCP 3307 eksemplari ühenduse jaoks, mõlemad on kirjeldatud Google'i Auth Proxy ülevaates. Teie VPN-marsruut katab teise; esimene lahkub tavaliselt tavalisel teel.
Otsene ühendus nõuab, et eksemplari PostgreSQL port oleks privaatse marsruudi kaudu kättesaadav, mis on hoopis teine firewalli vestlus. Kui teie võrgumeeskond lubab kliendi alamvõrkudest ainult väljuvat 443, sobib puhverserver ilma reegli muutmata ja otsene tee mitte. See üks fakt otsustab valiku sagedamini kui ükskõik milline arhitektuuriline eelistus.
Kumbki tee ei nõua, et eksemplaril oleks avalik aadress, ja kumbki ei õigusta selle lisamist.
Kus puhverserver ei aita
Puhverserver ei paranda puuduvat marsruuti. Kui private-services-access marsruut puudub või VPN seda ei kanna, nurjub konnektor, samal ajal kui kohalik kuulaja istub endiselt seal ja kuulab, ja see ongi segane osa.
See ei kaitse ka lõiku teie rakenduse ja puhverserveri vahel. Ühel sülearvutil on see lõik loopback ja korras. Kui seote kuulaja wildcard-aadressiga, et kolleeg sellele ligi pääseks, olete ehitanud autentimata andmebaasi värava ja nimetanud selle mugavuseks. Hoidke seda loopbackil ja laske kolleegil hankida enda mandaadid.
Ja see ei tee Private Service Connecti ja private services accessi vahetatavaks. PSC-eksemplar vajab oma DNS-korraldust ja --psc kutset, mitte --private-ip kuju.
Valimine ja seejärel kontrollimine igal juhul
Valige puhverserver, kui soovite IAM-i teele, lühiajalisi mandaate ja muudatusteta sissetulevat firewalld.
Valige otsene marsruut, kui toetatud kliendil on juba tugevad andmebaasi mandaadid ja võrgumeeskond on valmis pordi avama. Mõlemal juhul kontrollige tõelise päringuga, mitte õnnestunud ühendusega: ühenduge, käivitage üks lugemine tuntud tabeli vastu ja vaadake, mida server teie sessiooni kohta näeb.
Pärast VPN-i uuesti ühendamist käsitlege aegunud mandaate, puuduvat privaatset marsruuti ja andmebaasi sisselogimise tagasilükkamist kolme erineva rikkena. Ainult üks neist on võrguprobleem ja ainult üks peaks kunagi viima firewall-reegli muutmiseni.