Cloud SQL Auth Proxy versus přímá VPN trasa k databázi
Auth Proxy a přímá VPN trasa řeší různé poloviny stejného problému. Nejprve porovnejte autorizaci konektoru, porty a přihlášení k databázi.
K soukromé instanci Cloud SQL se z notebooku na VPN dá rozumně dostat dvěma způsoby. Jeden je přímé připojení na soukromou adresu instance po trase, kterou už máte. Druhý je Cloud SQL Auth Proxy, který naslouchá na loopbacku a spojení do Cloud SQL otevírá sám. Nejsou to ani tak konkurenční produkty jako dvě různé odpovědi na otázku, kdo drží přihlašovací údaje a kdo drží trasu. Špatná volba se obvykle projeví jako chyba autorizace, která se čte jako chyba sítě.
Toto je srovnání, které bych položil před tým, a za ním kontroly, které to skutečně rozhodnou.
Dvě cesty ke stejné instanci
Přímá cesta používá trasu private-services-access z vaší sítě do VPC projektu. Váš klient mluví PostgreSQL se soukromou adresou instance a spojení žije nebo umírá na routingu, pravidlech firewallu a přihlašovacích údajích k databázi.
Cesta přes proxy používá stejnou trasu, ale přidává místní proces. Proxy se autentizuje vůči Google API pomocí výchozích přihlašovacích údajů aplikace, otevře spojení k instanci přes konektor a vystaví port loopbacku, který váš klient považuje za PostgreSQL. Dva skoky se stanou třemi a ten prostřední nese autorizaci IAM. Trasu VPN si stále musíte udržovat sami a proxy ji nikdy nepovažuje za náhradu této kontroly.
Co která cesta skutečně autorizuje
Nejvíc záleží na tom, co za vás která volba může autorizovat:
| 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 |
Kontrola IAM na proxy a přihlášení k databázi jsou oddělené brány a průchod jednou neotevře druhou. Tým, který proxy zapne a předpokládá, že účet aplikace už není potřeba, stráví odpoledne nad chybami hesel, které se sítí nemají nic společného.
Porty a trasy vedle sebe
Proxy potřebuje odchozí TCP 443 pro API a TCP 3307 pro spojení k instanci, obojí je popsané v přehledu Auth Proxy. Vaše trasa VPN pokrývá druhé; první obvykle odchází běžnou cestou.
Přímé připojení potřebuje, aby byl port PostgreSQL instance dostupný přes soukromou trasu, což je jiná firewallová debata. Pokud váš síťový tým povoluje jen odchozí 443 z klientských podsítí, proxy se vejde bez změny pravidla a přímá cesta ne. Tento jediný fakt rozhoduje volbu častěji než jakákoli architektonická preference.
Ani jedna cesta nevyžaduje, aby instance měla veřejnou adresu, a ani jedna neospravedlňuje její přidání.
Kde proxy nepomůže
Proxy neopraví chybějící trasu. Pokud trasa private-services-access chybí nebo ji VPN nenese, konektor selže, zatímco místní posluchač tam stále sedí a poslouchá, a to je ta matoucí část.
Také nechrání úsek mezi vaší aplikací a proxy. Na jednom notebooku je tento úsek loopback a je to v pořádku. Pokud posluchač navážete na adresu wildcard, aby se k němu kolega dostal, postavili jste neautentizovanou bránu k databázi a nazvali to pohodlím. Nechte ho na loopbacku a ať si kolega opatří vlastní přihlašovací údaje.
A nedělá z Private Service Connect a private services access zaměnitelné věci. Instance PSC potřebuje vlastní uspořádání DNS a volání --psc místo podoby --private-ip.
Vybrat, a pak tak jako tak ověřit
Zvolte proxy, když chcete IAM v cestě, krátkodobé přihlašovací údaje a žádnou změnu příchozího firewallu.
Zvolte přímou trasu, když podporovaný klient už má silné přihlašovací údaje k databázi a síťový tým je ochoten port otevřít. V obou případech ověřujte skutečným dotazem, ne úspěšným připojením: připojte se, spusťte jedno čtení nad známou tabulkou a zkontrolujte, co server o vaší relaci vidí.
Po opětovném připojení VPN berte prošlé přihlašovací údaje, chybějící soukromou trasu a odmítnutí přihlášení k databázi jako tři různé poruchy. Jen jedna z nich je síťový problém a jen jedna by kdy měla vést ke změně pravidla firewallu.