Cloud SQL Auth Proxy срещу директен VPN маршрут до базата данни
Auth Proxy и директният VPN маршрут решават различни половини от един и същ проблем. Първо сравнете оторизацията на конектора, портовете и влизането в базата данни.
Има два разумни начина да стигнете до частен Cloud SQL екземпляр от лаптоп във VPN. Единият е директна връзка към частния адрес на екземпляра през маршрута, който вече имате. Другият е Cloud SQL Auth Proxy, който слуша на loopback и сам отваря връзката към Cloud SQL. Това са по-скоро не конкуриращи се продукти, а два различни отговора на въпроса кой държи идентификационните данни и кой държи маршрута. Лошият избор обикновено се проявява като грешка в оторизацията, която се чете като мрежова грешка.
Ето сравнението, което бих поставил пред екипа, последвано от проверките, които всъщност решават въпроса.
Два пътя до един и същ екземпляр
Директният път използва маршрута private-services-access от вашата мрежа към VPC на проекта. Вашият клиент говори PostgreSQL с частния адрес на екземпляра и връзката живее или умира на базата на маршрутизацията, правилата на firewall и идентификационните данни за базата.
Пътят през прокси използва същия маршрут, но добавя локален процес. Проксито се удостоверява пред Google API с default credentials на приложението, отваря връзка към екземпляра през конектора и предоставя loopback порт, който вашият клиент третира като PostgreSQL. Два скока стават три, а средният носи IAM оторизация. VPN маршрутът остава ваш за поддръжка и проксито никога не го приема за заместител на тази проверка.
Какво всъщност оторизира всеки път
Най-важното разграничение е какво може да оторизира всяка опция вместо вас:
| 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 |
IAM проверката на проксито и влизането в базата данни са отделни порти и преминаването през едната не отваря другата. Екип, който включи проксито и приеме, че акаунтът на приложението вече е ненужен, ще прекара следобеда в отстраняване на паролни грешки, които нямат нищо общо с мрежата.
Портове и маршрути един до друг
Проксито изисква изходящ TCP 443 за API и TCP 3307 за връзката с екземпляра, като и двете са описани в Преглед на Auth Proxy. Вашият VPN маршрут покрива второто; първото обикновено излиза по обичайния път.
Директната връзка изисква PostgreSQL портът на екземпляра да е достъпен през частния маршрут, което е съвсем друг разговор за firewall. Ако мрежовият ви екип разрешава само изходящ 443 от клиентски подмрежи, проксито пасва без промяна на правило, а директният път не. Този единствен факт решава избора по-често от всяко архитектурно предпочитание.
Нито един от пътищата не изисква екземплярът да има публичен адрес и нито един не оправдава добавянето му.
Къде проксито не помага
Проксито не поправя липсващ маршрут. Ако маршрутът private-services-access липсва или VPN не го носи, конекторът се проваля, докато локалният слушател все още седи и слуша, и точно това обърква.
То също не защитава участъка между приложението и проксито. На един лаптоп този участък е loopback и е наред. Ако вържете слушателя към wildcard адрес, за да може колега да го достигне, сте изградили неудостоверен шлюз към базата данни и сте го нарекли удобство. Дръжте го на loopback и оставете колегата да си вземе собствени идентификационни данни.
И не прави Private Service Connect и private services access взаимозаменяеми. PSC екземплярът се нуждае от собствена DNS подредба и от извикването --psc, а не от формата --private-ip.
Избор, после проверка и по двата пътя
Изберете проксито, когато искате IAM в пътя, краткотрайни идентификационни данни и без промяна на входящия firewall.
Изберете директния маршрут, когато поддържан клиент вече има силни идентификационни данни за базата и мрежовият екип е готов да отвори порта. В двата случая проверете с истинска заявка, а не с успешна връзка: свържете се, изпълнете едно четене срещу известна таблица и проверете какво вижда сървърът за вашата сесия.
След повторно свързване на VPN третирайте изтеклите идентификационни данни, липсващия частен маршрут и отказа за вход в базата като три различни отказа. Само един от тях е мрежов проблем и само един трябва някога да води до промяна на firewall правило.