Vzdialený prístup vývojára ku Google Cloud VPC: vyberte cestu

Vývojár potrebuje jedno reláciu SSH, port databázy alebo široký prístup k tuctu súkromných služieb a každá z týchto požiadaviek vyzerá ako tá istá otázka. Nie je. Ciele, protokoly a zúčastnené identity rozhodujú, ktorá cesta prístupu v Google Cloud sedí, a výber najširšej ako predvolenej vytvára prácu, ktorú ste nemuseli vlastniť.

Zapíšte ciele a protokoly

Vypíšte súkromné adresy, porty a protokoly, ktoré práca skutočne potrebuje, a potom označte, ktoré identity sa musia overovať samostatne. Port databázy a súkromná zóna DNS sú rôzne požiadavky a služba UDP jednu z nižšie uvedených možností úplne vylučuje. Písomný zoznam tiež ukazuje, čo neudeľujete. To je časť, na ktorú sa pýtajú recenzenti.

Urobte to pred otvorením poslúchača. Zoznam sa neskôr stane akceptačným testom a je jediným spoľahlivým spôsobom, ako odlíšiť úzky tunel od širokého, ktorý funguje len náhodou.

IAP pre niekoľko služieb TCP

Preposielanie TCP v Identity-Aware Proxy poskytuje overený tunel k vhodným zdrojom VM bez vystavenia služby internetu. Bežná podoba je gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a a jeden port možno preposlať lokálne pomocou gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a.

Musia sa zhodovať tri veci: volajúci potrebuje rolu prístupu k tunelu IAP, firewall musí prepúšťať rozsah zdroja IAP a cieľ musí byť na inštancii dostupný. Oprávnenie vytvoriť tunel nie je prihlasovací údaj databázy, prihlásenie SSH ani relácia RDP, preto nechajte overovanie aplikácie tam, kam patrí.

Preposielanie TCP v IAP nie je VPN tretej vrstvy. Prenáša TCP do vybraného cieľa, nie ľubovoľnú prevádzku IP alebo UDP, a slabo sa hodí, keď aplikácia potrebuje súkromné DNS naprieč mnohými službami.

VPN vzdialeného prístupu pre širšiu dostupnosť

Keď je potrebných niekoľko cieľov, protokolov alebo súkromných zón DNS, lepšou podobou je výslovne spravovaná VPN vzdialeného prístupu na VM alebo podporovanom zariadení. Toto nasadenie je oddelené od Cloud VPN spravovaného Googlom: vlastníte registráciu identity klienta, aktualizácie softvéru, klientske trasy a spätné trasy vo VPC.

Plánujte celý zoznam, nielen verejný poslúchač. Zahrňte fond tunelov, trasu VPC späť k nemu, riadenie preposielania, preklad DNS a politiku prístupu pre každú službu. VPN, ktorá sa pripojí, ale nedokáže preložiť interné názvy, zlyháva vo vývojárskom postupe rovnako úplne ako tá, ktorá sa nepripojí nikdy.

Cloud VPN je brána lokality, nie profil pre notebook

Google Cloud VPN prepája partnerské brány cez IPsec a jeho často kladené otázky oddeľujú túto rolu lokalita-lokalita od prístupu klient-brána. Vytvorenie tunela nevytvorí profil, ktorý si zamestnanec naimportuje do notebooku. Rozdiel je dôležitý, keď niekto požiada o profil Cloud VPN. Odpoveďou je iný produkt.

Brána dobre robí jednu vec: dáva strojom za kancelárskou sieťou trasu do VPC. Neoveruje každého zamestnanca ani neudeľuje oprávnenia aplikácií, preto tieto politiky zostávajú na sieťovej a aplikačnej vrstve, kde ich možno vynútiť podľa identity.

Overte a zaznamenajte

Najprv otestujte najužší cieľ, potom ten, ktorý vyžaduje DNS, a nakoniec cieľ, ktorý musí zostať odmietnutý. Každý test spúšťajte z toho istého klienta, ktorý bude cestu používať v produkcii, pretože úspešný test z administrátorskej stanice málo dokazuje o vývojárskom notebooku s inou sieťou.

Zaznamenajte zvolený model, ciele, ktoré pokrýva, identity, ktoré overuje, a správanie pri zlyhaní, keď cesta nie je dostupná. Práve tento záznam bráni tomu, aby nasledujúca požiadavka ticho rozšírila tunel namiesto pridania jedného cieľa do zdokumentovaného návrhu.