Cloud SQL Auth Proxy eða bein VPN-leið að gagnagrunninum

Það eru tveir skynsamlegir vegir að einkareknri Cloud SQL-tilviki frá fartölvu á VPN. Annar er bein tenging við einkaaðsetur tilviksins um leiðina sem þú hefur þegar. Hinn er Cloud SQL Auth Proxy, sem hlustar á loopback og opnar sjálft tenginguna við Cloud SQL. Þetta eru síður keppinautar en tvö mismunandi svör við þeirri spurningu hver heldur skírteininu og hver heldur leiðinni. Röng ákvörðun kemur yfirleitt fram sem heimildarvilla sem lesin er sem netvilla.

Hér er samanburðurinn sem ég myndi leggja fyrir teymi, og á eftir honum prófanirnar sem ráða honum í raun.

Tveir vegir að sama tilviki

Beina leiðin notar private-services-access-leiðina frá netinu þínu inn í VPC verkefnisins. Biðlarinn þinn talar PostgreSQL við einkaaðsetur tilviksins, og tengingin lifir eða deyr á leiðsögn, firewall-reglum og skírteinum gagnagrunnsins.

Proxy-leiðin notar sömu leið en bætir við staðbundnu ferli. Proxy-ið auðkennir sig við Google API með default credentials forritsins þíns, opnar tengingu við tilvikið um tengið og birtir loopback-port sem biðlarinn þinn meðhöndlar sem PostgreSQL. Tvö stökk verða þrjú, og hið miðju ber IAM-heimild. VPN-leiðin er áfram þín til að viðhalda, og proxy-ið lítur aldrei á hana sem staðgengil fyrir þá prófun.

Hvað hvor leiðin heimilar í raun

Mikilvægasti munurinn er hvað hvor valkosturinn getur heimilað fyrir þína hönd:

IAM-prófun proxy-sins og innskráningin í gagnagrunninn eru aðskilin hlið, og að komast í gegnum annað opnar ekki hitt. Teymi sem kveikir á proxy-inu og gerir ráð fyrir að forritareikningurinn sé nú óþarfur eyðir síðdegi í lykilorðsvillum sem hafa ekkert með netkerfi að gera.

Port og leiðir, hlið við hlið

Proxy-ið þarf útleið TCP 443 fyrir API-ið og TCP 3307 fyrir tengingu tilviksins, bæði lýst í yfirliti Google yfir Auth Proxy. VPN-leiðin þín nær yfir hina seinni; hin fyrri fer venjulega venjulegu leiðina.

Bein tenging krefst þess að PostgreSQL-port tilviksins sé aðgengilegt um einkaleiðina, sem er allt önnur firewall-samtal. Ef netteymið þitt leyfir aðeins útleið 443 frá biðlarakvótum passar proxy-ið án reglubreytingar og beina leiðin ekki. Þessi eina staðreynd ræður valinu oftar en nokkur arkitektúrleg tilhneiging.

Hvorug leiðin krefst þess að tilvikið hafi opinbert vistfang, og hvorug réttlætir að bæta slíku við.

Þar sem proxy-ið hjálpar ekki

Proxy-ið lagar ekki leið sem vantar. Ef private-services-access-leiðin vantar, eða VPN-ið flytur hana ekki, bregst tengið en staðbundni hlustandinn situr enn þar og hlustar, og það er hið ruglandi atriði.

Það verndar heldur ekki kaflann milli forritsins þíns og proxy-sins. Á einni fartölvu er sá kafli loopback og í lagi. Ef þú bindur hlustandann við wildcard-vistfang svo kollega komist að honum hefurðu byggt óauðkennda gagnagrunshlið og kallað það þægindi. Haltu honum á loopback og láttu kollegann afla sér eigin skírteinis.

Og það gerir Private Service Connect og private services access ekki skiptanleg. PSC-tilvik þarf eigin DNS-fyrirkomulag og --psc-kallið í stað --private-ip-formsins.

Velja, og sannreyna svo hvort sem er

Veldu proxy-ið þegar þú vilt IAM á leiðinni, skammtíma skírteini og enga breytingu á innleið firewall.

Veldu beinu leiðina þegar studdur biðlari hefur þegar sterk gagnagrunnsskírteini og netteymið er reiðubúið að opna portið. Sannreyndu hvort sem er með alvöru fyrirspurn frekar en farsælli tengingu: tengstu, keyrðu eina lestur á þekkta töflu og skoðaðu hvað þjónninn sér um setuna þína.

Eftir endurtengingu VPN skaltu meðhöndla útrunnið skírteini, leið sem vantar og synjun á innskráningu í gagnagrunninn sem þrjár mismunandi bilanir. Aðeins ein þeirra er netvandamál, og aðeins ein ætti nokkurn tíma að leiða til að breyta firewall-reglu.