Externe ontwikkelaarstoegang tot een Google Cloud VPC: kies het pad

Een ontwikkelaar heeft één SSH-sessie, één databasepoort of brede toegang tot een dozijn privédiensten nodig, en elk van die verzoeken lijkt dezelfde vraag. Dat is het niet. De bestemmingen, de protocollen en de betrokken identiteiten bepalen welk toegangspad in Google Cloud past, en standaard de breedste kiezen creëert werk dat u niet hoefde te bezitten.

Schrijf de bestemmingen en protocollen op

List de privéadressen, poorten en protocollen op die het werk echt nodig heeft, en markeer dan welke identiteiten afzonderlijk moeten worden geauthenticeerd. Een databasepoort en een privé-DNS-zone zijn verschillende vereisten, en een UDP-dienst sluit een van de onderstaande opties volledig uit. Een schriftelijke lijst laat ook zien wat u niet verleent. Dat is het deel waar reviewers naar vragen.

Doe dit voordat u een listener opent. De lijst wordt later de acceptatietest, en het is de enige betrouwbare manier om een smalle tunnel te onderscheiden van een brede die toevallig werkt.

IAP voor een paar TCP-diensten

TCP-doorsturen in Identity-Aware Proxy geeft een geauthenticeerde tunnel naar geschikte VM-resources zonder de dienst op het internet bloot te stellen. De dagelijkse vorm is gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a, en één poort kan lokaal worden doorgestuurd met gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a.

Drie dingen moeten kloppen: de aanroeper heeft de IAP-tunneltoegangsrol nodig, de firewall moet het IAP-bronbereik toelaten, en de bestemming moet op de instantie bereikbaar zijn. Toestemming om de tunnel te maken is geen databasereferentie, SSH-login of RDP-sessie, dus houd de applicatie-authenticatie waar die hoort.

TCP-doorsturen in IAP is geen VPN op laag drie. Het draagt TCP naar een gekozen bestemming, niet willekeurig IP-verkeer of UDP, en het past slecht wanneer een applicatie privé-DNS over veel diensten nodig heeft.

Een VPN voor externe toegang voor bredere bereikbaarheid

Wanneer meerdere bestemmingen, protocollen of privé-DNS-zones nodig zijn, is een expliciet beheerde VPN voor externe toegang op een VM of ondersteund apparaat de betere vorm. Die uitrol staat los van het door Google beheerde Cloud VPN: u bezit de registratie van de clientidentiteit, de software-updates, de clientroutes en de retourroutes in het VPC.

Plan de hele lijst, niet alleen de openbare listener. Neem de tunnelpool, de VPC-route terug, doorstuurbeheer, DNS-resolutie en het toegangsbeleid per dienst op. Een VPN die verbindt maar interne namen niet kan oplossen, laat de workflow van de ontwikkelaar even volledig mislukken als een die nooit verbindt.

Cloud VPN is een sitegateway, geen laptop-profiel

Google Cloud VPN verbindt peergateways via IPsec, en de veelgestelde vragen scheiden die site-naar-site-rol van client-naar-gateway-toegang. Een tunnel maken levert geen profiel op dat een medewerker op een laptop importeert. Het onderscheid is belangrijk wanneer iemand om een Cloud VPN-profiel vraagt. Het antwoord is een ander product.

Wat een gateway goed doet, is de machines achter een kantoornetwerk een route het VPC in geven. Het authenticeert niet elke medewerker en verleent geen applicatierechten, dus dat beleid blijft op de netwerk- en applicatielaag waar het per identiteit kan worden afgedwongen.

Verifieer en leg vast

Test eerst de smalste bestemming, dan degene die DNS vereist, en dan een bestemming die geweigerd moet blijven. Voer elke test uit vanaf dezelfde client die het pad in productie gebruikt, want een werkende test vanaf een beheerderswerkplek bewijst weinig over een laptop van een ontwikkelaar met een ander netwerk.

Leg het gekozen model vast, de bestemmingen die het dekt, de identiteiten die het authenticeert en het faalgedrag wanneer het pad niet beschikbaar is. Dat verslag is wat voorkomt dat het volgende verzoek de tunnel stil verbreedt in plaats van één bestemming aan een gedocumenteerd ontwerp toe te voegen.