Cloud SQL Auth Proxy kontraŭ rekta VPN-itinero al la datumbazo
La Auth Proxy kaj rekta VPN-itinero solvas malsamajn duonojn de la sama problemo. Unue komparu la rajtigon de la konektilo, la pordojn kaj la datumbazan salutong.
Estas du prudentaj manieroj atingi privatan Cloud SQL-instancon de tekkomputilo en la VPN. Unu estas rekta konekto al la privata adreso de la instanco laŭ la itinero, kiun vi jam havas. La alia estas Cloud SQL Auth Proxy, kiu aŭskultas sur loopback kaj mem malfermas la konekton al Cloud SQL. Ili estas malpli konkurantaj produktoj ol du malsamaj respondoj al la demando, kiu tenas la akreditaĵojn kaj kiu tenas la itineron. Malbona elekto kutime aperas kiel rajtiga eraro, kiu legeblas kiel reta eraro.
Jen la komparo, kiun mi metus antaŭ teamon, sekvata de la kontroloj, kiuj efektive decidas ĝin.
Du vojoj al la sama instanco
La rekta vojo uzas la itineron private-services-access de via reto en la VPC de la projekto. Via kliento parolas PostgreSQL kun la privata adreso de la instanco, kaj la konekto vivas aŭ mortas laŭ enrutigo, firewall-reguloj kaj datumbazaj akreditaĵoj.
La vojo tra la prokuro uzas la saman itineron sed aldonas lokan procezon. La prokuro aŭtentikigas sin al la Google API per la default credentials de via aplikaĵo, malfermas konekton al la instanco tra la konektilo kaj elmetas loopback-pordon, kiun via kliento traktas kiel PostgreSQL. Du saltoj fariĝas tri, kaj la meza portas IAM-rajtigon. La VPN-itinero restas via por prizorgi, kaj la prokuro neniam konsideras ĝin anstataŭaĵo por tiu kontrolo.
Kion ĉiu vojo efektive rajtigas
La plej grava distingo estas, kion ĉiu opcio povas rajtigi por vi:
| 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 |
La IAM-kontrolo de la prokuro kaj la datumbaza saluto estas apartaj pordegoj, kaj trapasi unu ne malfermas la alian. Teamo, kiu ŝaltas la prokuron kaj supozas, ke la aplikaĵa konto nun estas superflua, pasigos posttagmezon ĉe pasvortaj malsukcesoj, kiuj havas nenion komunan kun retoj.
Pordoj kaj itineroj, flanko ĉe flanko
La prokuro bezonas elirantan TCP 443 por la API kaj TCP 3307 por la instanca konekto, ambaŭ priskribitaj en la superrigardo de Auth Proxy. Via VPN-itinero kovras la duan; la unua kutime eliras la ordinaran vojon.
Rekta konekto bezonas, ke la PostgreSQL-pordo de la instanco estu atingebla tra la privata itinero, kio estas tute alia firewall-interparolo. Se via reta teamo permesas nur elirantan 443 el klientaj subretoj, la prokuro taŭgas sen ŝanĝo de regulo kaj la rekta vojo ne. Tiu ununura fakto decidas la elekton pli ofte ol iu ajn arkitektura prefero.
Neniu el la du vojoj postulas, ke la instanco havu publikan adreson, kaj neniu pravigas aldoni tian.
Kie la prokuro ne helpas
La prokuro ne riparas mankantan itineron. Se la itinero private-services-access mankas, aŭ la VPN ne portas ĝin, la konektilo malsukcesas dum la loka aŭskultanto ankoraŭ sidas tie kaj aŭskultas, kaj tio estas la konfuza parto.
Ĝi ankaŭ ne protektas la parton inter via aplikaĵo kaj la prokuro. Sur unu tekkomputilo tiu parto estas loopback kaj en ordo. Se vi ligas la aŭskultanton al wildcard-adreso por ke kolego povu atingi ĝin, vi konstruis neaŭtentikigitan datumbazan pordegon kaj nomis ĝin oportuneco. Tenu ĝin sur loopback kaj lasu la kolegon akiri proprajn akreditaĵojn.
Kaj ĝi ne faras Private Service Connect kaj private services access interŝanĝeblaj. PSC-instanco bezonas sian propran DNS-aranĝon kaj la --psc-alvokon anstataŭ la formo --private-ip.
Elekti, poste kontroli ĉiuokaze
Elektu la prokuron, kiam vi volas IAM en la vojo, mallongdaŭrajn akreditaĵojn kaj neniun ŝanĝon de envenanta firewall.
Elektu la rektan itineron, kiam subtenata kliento jam havas fortajn datumbazajn akreditaĵojn kaj la reta teamo pretas malfermi la pordon. Ĉiuokaze kontrolu per vera peto anstataŭ per sukcesa konekto: konektiĝu, plenumu unu legon kontraŭ konata tabelo kaj kontrolu, kion la servilo vidas por via sesio.
Post rekonekto de VPN, traktu eksvalidiĝintajn akreditaĵojn, mankantan privatan itineron kaj rifuzon de datumbaza saluto kiel tri malsamajn fiaskojn. Nur unu el ili estas reta problemo, kaj nur unu devus iam konduki al ŝanĝo de firewall-regulo.