Zdalny dostęp dewelopera do Google Cloud VPC: wybierz ścieżkę

Deweloper potrzebuje jednej sesji SSH, portu bazy danych lub szerokiego dostępu do tuzina prywatnych usług, a każde z tych żądań wygląda jak to samo pytanie. To nieprawda. Cele, protokoły i zaangażowane tożsamości decydują, która ścieżka dostępu w Google Cloud pasuje, a wybór najszerszej domyślnie tworzy pracę, której nie musiałeś posiadać.

Zapisz cele i protokoły

Wypisz prywatne adresy, porty i protokoły, których praca naprawdę potrzebuje, a następnie oznacz, które tożsamości muszą być uwierzytelniane osobno. Port bazy danych i prywatna strefa DNS to różne wymagania, a usługa UDP całkowicie wyklucza jedną z poniższych opcji. Pisemna lista pokazuje też, czego nie przyznajesz. To właśnie ta część, o którą pytają recenzenci.

Zrób to przed otwarciem nasłuchiwacza. Lista staje się później testem akceptacyjnym i jest jedynym niezawodnym sposobem odróżnienia wąskiego tunelu od szerokiego, który działa przypadkiem.

IAP dla kilku usług TCP

Przekazywanie TCP w Identity-Aware Proxy daje uwierzytelniony tunel do odpowiednich zasobów VM bez wystawiania usługi do internetu. Codzienna forma to gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a, a pojedynczy port można przekazać lokalnie za pomocą gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a.

Trzy rzeczy muszą się zgadzać: wywołujący potrzebuje roli dostępu do tunelu IAP, zapora musi przepuszczać zakres źródłowy IAP, a cel musi być osiągalny na instancji. Uprawnienie do utworzenia tunelu nie jest poświadczeniem bazy danych, logowaniem SSH ani sesją RDP, więc zostaw uwierzytelnianie aplikacji tam, gdzie należy.

Przekazywanie TCP w IAP nie jest VPN-em warstwy trzeciej. Przenosi TCP do wybranego celu, a nie dowolny ruch IP czy UDP, i słabo pasuje, gdy aplikacja potrzebuje prywatnego DNS w wielu usługach.

VPN dostępu zdalnego dla szerszej osiągalności

Gdy potrzebnych jest kilka celów, protokołów lub prywatnych stref DNS, lepszą formą jest jawnie zarządzany VPN dostępu zdalnego na VM lub obsługiwanym urządzeniu. To wdrożenie jest oddzielne od zarządzanego przez Google Cloud VPN: posiadasz rejestrację tożsamości klienta, aktualizacje oprogramowania, trasy klienta i trasy powrotne w VPC.

Zaplanuj całą listę, nie tylko publiczny nasłuchiwacz. Uwzględnij pulę tuneli, trasę VPC z powrotem do niej, kontrolę przekazywania, rozwiązywanie nazw DNS i politykę dostępu dla każdej usługi. VPN, który się łączy, ale nie potrafi rozwiązać nazw wewnętrznych, zawodzi przepływ pracy dewelopera równie całkowicie jak ten, który nigdy się nie łączy.

Cloud VPN to brama witryny, a nie profil laptopa

Google Cloud VPN łączy bramy partnerów przez IPsec, a jego najczęściej zadawane pytania oddzielają tę rolę witryna-do-witryny od dostępu klient-brama. Utworzenie tunelu nie tworzy profilu, który pracownik importuje na laptopie. Rozróżnienie ma znaczenie, gdy ktoś prosi o profil Cloud VPN. Odpowiedzią jest inny produkt.

To, co brama robi dobrze, to dawanie maszynom za siecią biurową trasy do VPC. Nie uwierzytelnia każdego pracownika ani nie przyznaje uprawnień aplikacji, więc te zasady pozostają na warstwie sieci i aplikacji, gdzie można je egzekwować według tożsamości.

Sprawdź i zapisz

Najpierw przetestuj najwęższy cel, potem ten, który wymaga DNS, a następnie cel, który musi pozostać odrzucony. Każdy test uruchom z tego samego klienta, który będzie używał ścieżki na produkcji, ponieważ działający test ze stacji roboczej administratora niewiele dowodzi o laptopie dewelopera z inną siecią.

Zapisz wybrany model, cele, które obejmuje, tożsamości, które uwierzytelnia, oraz zachowanie przy awarii, gdy ścieżka jest niedostępna. Ten zapis jest tym, co powstrzymuje następne żądanie przed cichym rozszerzeniem tunelu zamiast dodania jednego celu do udokumentowanego projektu.