Vzdálený přístup vývojáře k Google Cloud VPC: vyberte správnou cestu

Vývojář potřebuje jedno připojení SSH, port databáze nebo široký přístup k tuctu soukromých služeb a každý z těchto požadavků vypadá jako stejná otázka. Není. Cíle, protokoly a zúčastněné identity rozhodují, která cesta přístupu ke Google Cloudu sedí, a volba nejširší možnosti jako výchozí vytváří práci, kterou jste nemuseli vlastnit.

Zapište cíle a protokoly

Vypište soukromé adresy, porty a protokoly, které práce skutečně potřebuje, a pak označte, které identity se musí ověřovat samostatně. Port databáze a soukromá zóna DNS jsou různé požadavky a služba UDP jednu z níže uvedených možností zcela vylučuje. Písemný seznam také ukazuje, co neudělujete. To je část, na kterou se recenzenti ptají.

Udělejte to před otevřením posluchače. Seznam se později stane akceptačním testem a je jediným spolehlivým způsobem, jak odlišit úzký tunel od širokého, který funguje jen náhodou.

IAP pro několik služeb TCP

Přeposílání TCP v Identity-Aware Proxy dává ověřený tunel k vhodným prostředkům VM, aniž by službu vystavilo internetu. Běžná podoba je gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a a jeden port lze přeposlat lokálně pomocí gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a.

Musí se sejít tři věci: volající potřebuje roli přístupu k tunelu IAP, firewall musí propouštět rozsah zdrojů IAP a cíl musí být na instanci dostupný. Oprávnění vytvořit tunel není přihlašovací údaj databáze, přihlášení SSH ani relace RDP, proto nechte ověřování aplikace tam, kam patří.

Přeposílání TCP v IAP není VPN třetí vrstvy. Přenáší TCP do vybraného cíle, nikoli libovolný provoz IP nebo UDP, a špatně se hodí, když aplikace potřebuje soukromé DNS napříč mnoha službami.

VPN pro vzdálený přístup pro širší dostupnost

Když je potřeba několik cílů, protokolů nebo soukromých zón DNS, lepší podobou je explicitně spravovaná VPN pro vzdálený přístup na VM nebo podporovaném zařízení. Toto nasazení je oddělené od Cloud VPN spravovaného Googlem: vlastníte registraci identity klienta, aktualizace softwaru, klientské trasy a zpětné trasy ve VPC.

Plánujte celý seznam, ne jen veřejný posluchač. Zahrňte fond tunelů, trasu VPC zpět k němu, řízení přeposílání, překlad DNS a politiku přístupu pro každou službu. VPN, která se připojí, ale nedokáže přeložit interní názvy, selhává ve vývojářském postupu stejně úplně jako ta, která se nepřipojí nikdy.

Cloud VPN je brána lokality, ne profil pro notebook

Google Cloud VPN propojuje partnerské brány přes IPsec a jeho časté dotazy oddělují tuto roli lokalita-lokalita od přístupu klient-brána. Vytvoření tunelu nevytvoří profil, který si zaměstnanec naimportuje do notebooku. Rozdíl je důležitý, když někdo požádá o profil Cloud VPN. Odpovědí je jiný produkt.

Brána dobře dělá jednu věc: dává strojům za kancelářskou sítí trasu do VPC. Neověřuje každého zaměstnance ani neuděluje oprávnění aplikacím, takže tyto politiky zůstávají na síťové a aplikační vrstvě, kde je lze vynutit podle identity.

Ověřte a zaznamenejte

Nejprve otestujte nejužší cíl, pak ten, který vyžaduje DNS, a potom cíl, který musí zůstat odmítnutý. Každý test spouštějte ze stejného klienta, který bude cestu používat v produkci, protože úspěšný test z administrátorské stanice málo dokazuje o vývojářském notebooku s jinou sítí.

Zaznamenejte zvolený model, cíle, které pokrývá, identity, které ověřuje, a chování při selhání, když cesta není dostupná. Právě tento záznam brání tomu, aby příští požadavek tiše rozšířil tunel místo přidání jednoho cíle do zdokumentovaného návrhu.