Cloud SQL Auth Proxy a bezpośrednia trasa VPN do bazy danych
Auth Proxy i bezpośrednia trasa VPN rozwiązują różne połowy tego samego problemu. Najpierw porównaj autoryzację connectora, porty i logowanie do bazy danych.
Są dwa rozsądne sposoby dotarcia do prywatnej instancji Cloud SQL z laptopa w sieci VPN. Jeden to bezpośrednie połączenie z prywatnym adresem instancji przez trasę, którą już masz. Drugi to Cloud SQL Auth Proxy, który nasłuchuje na loopback i sam otwiera połączenie do Cloud SQL. To mniej konkurencyjne produkty, a bardziej dwie różne odpowiedzi na pytanie, kto trzyma dane uwierzytelniające, a kto trzyma trasę. Zły wybór zwykle objawia się błędem autoryzacji, który czyta się jak błąd sieci.
Oto porównanie, które postawiłbym przed zespołem, a za nim kontrole, które naprawdę decydują.
Dwie drogi do tej samej instancji
Ścieżka bezpośrednia korzysta z trasy private-services-access z Twojej sieci do VPC projektu. Twój klient mówi po PostgreSQL z prywatnym adresem instancji, a połączenie żyje lub umiera na routingu, regułach firewalla i danych uwierzytelniających bazy.
Ścieżka przez proxy korzysta z tej samej trasy, ale dodaje lokalny proces. Proxy uwierzytelnia się w Google API za pomocą default credentials aplikacji, otwiera połączenie z instancją przez connector i udostępnia port loopback, który Twój klient traktuje jak PostgreSQL. Dwa przeskoki stają się trzema, a środkowy niesie autoryzację IAM. Trasa VPN nadal jest Twoja do utrzymania, a proxy nigdy nie traktuje jej jako zamiennika tej kontroli.
Co każda ścieżka faktycznie autoryzuje
Najważniejsza różnica polega na tym, co każda opcja może autoryzować za Ciebie:
| 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 proxy i logowanie do bazy to dwie osobne bramy, a przejście jednej nie otwiera drugiej. Zespół, który włączy proxy i założy, że konto aplikacji jest już zbędne, spędzi popołudnie na błędach haseł, które nie mają nic wspólnego z siecią.
Porty i trasy obok siebie
Proxy potrzebuje wychodzącego TCP 443 do API i TCP 3307 do połączenia z instancją, oba opisane w omówieniu Auth Proxy Google. Twoja trasa VPN pokrywa drugi; pierwszy zwykle wychodzi zwykłą drogą.
Bezpośrednie połączenie wymaga, aby port PostgreSQL instancji był osiągalny przez prywatną trasę, co jest zupełnie inną rozmową o firewallu. Jeśli Twój zespół sieciowy dopuszcza tylko wychodzący 443 z podsieci klientów, proxy pasuje bez zmiany reguły, a ścieżka bezpośrednia nie. Ten jeden fakt decyduje o wyborze częściej niż jakiekolwiek preferencje architektoniczne.
Żadna ze ścieżek nie wymaga, aby instancja miała publiczny adres, i żadna nie uzasadnia jego dodania.
Gdzie proxy nie pomaga
Proxy nie naprawia brakującej trasy. Jeśli trasy private-services-access nie ma albo VPN jej nie przenosi, connector zawodzi, podczas gdy lokalny nasłuch wciąż tam siedzi i nasłuchuje, i to jest ta myląca część.
Nie chroni też odcinka między Twoją aplikacją a proxy. Na jednym laptopie ten odcinek to loopback i jest w porządku. Jeśli przypniesz nasłuch do adresu wildcard, żeby współpracownik mógł się do niego dostać, zbudowałeś nieuwierzytelnioną bramę do bazy i nazwałeś to wygodą. Trzymaj go na loopback i pozwól współpracownikowi zdobyć własne dane uwierzytelniające.
Nie czyni też Private Service Connect i private services access wymiennymi. Instancja PSC potrzebuje własnego układu DNS i wywołania --psc zamiast formy --private-ip.
Wybrać, a potem w każdym razie zweryfikować
Wybierz proxy, gdy chcesz IAM na ścieżce, krótkotrwałe dane uwierzytelniające i żadnej zmiany przychodzącego firewalla.
Wybierz trasę bezpośrednią, gdy obsługiwany klient ma już silne dane uwierzytelniające do bazy, a zespół sieciowy jest gotów otworzyć port. W obu przypadkach weryfikuj prawdziwym zapytaniem, a nie udanym połączeniem: połącz się, wykonaj jeden odczyt na znanej tabeli i sprawdź, co serwer widzi w Twojej sesji.
Po ponownym połączeniu VPN traktuj wygasłe dane uwierzytelniające, brakującą prywatną trasę i odrzucenie logowania do bazy jako trzy różne awarie. Tylko jedna z nich jest problemem sieciowym i tylko jedna powinna kiedykolwiek prowadzić do zmiany reguły firewalla.