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 від Google. Ваш маршрут 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.