Fjärråtkomst för utvecklare till ett Google Cloud VPC: välj vägen

En utvecklare behöver en SSH-session, en databasport eller bred åtkomst till ett dussin privata tjänster, och var och en av dessa förfrågningar ser ut som samma fråga. Det är det inte. Målen, protokollen och identiteterna som är inblandade avgör vilken åtkomstväg i Google Cloud som passar, och att välja den bredaste som standard skapar arbete du inte behövde äga.

Skriv ner målen och protokollen

Lista de privata adresserna, portarna och protokollen som arbetet faktiskt behöver, markera sedan vilka identiteter som måste autentiseras separat. En databasport och en privat DNS-zon är olika krav, och en UDP-tjänst utesluter helt ett av alternativen nedan. En skriftlig lista visar också vad du inte beviljar. Det är den delen granskarna frågar om.

Gör detta innan du öppnar en lyssnare. Listan blir senare acceptanstestet, och den är det enda tillförlitliga sättet att skilja en smal tunnel från en bred som råkar fungera.

IAP för några få TCP-tjänster

TCP-vidarebefordran i Identity-Aware Proxy ger en autentiserad tunnel till lämpliga VM-resurser utan att exponera tjänsten mot internet. Den dagliga formen är gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a, och en enda port kan vidarebefordras lokalt med gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a.

Tre saker måste stämma: anroparen behöver IAP-tunnelåtkomstrollen, brandväggen måste tillåta IAP-källintervallet, och målet måste vara nåbart på instansen. Behörigheten att skapa tunneln är inte en databasreferens, en SSH-inloggning eller en RDP-session, så håll applikationsautentiseringen där den hör hemma.

TCP-vidarebefordran i IAP är inte ett VPN på lager tre. Det bär TCP till ett valt mål, inte godtycklig IP-trafik eller UDP, och det passar dåligt när en applikation behöver privat DNS över många tjänster.

Ett VPN för fjärråtkomst för bredare nåbarhet

När flera mål, protokoll eller privata DNS-zoner krävs är den bättre formen ett uttryckligen hanterat VPN för fjärråtkomst på en VM eller en stödd enhet. Den driftsättningen är separat från Googles hanterade Cloud VPN: du äger registreringen av klientidentiteten, programuppdateringarna, klientrutterna och returrutterna i VPC:n.

Planera hela listan, inte bara den offentliga lyssnaren. Inkludera tunnelpoolen, VPC-rutten tillbaka till den, vidarebefordringskontroller, DNS-upplösning och åtkomstpolicy per tjänst. Ett VPN som ansluter men inte kan lösa interna namn misslyckas i utvecklarens arbetsflöde lika fullständigt som ett som aldrig ansluter.

Cloud VPN är en platsgateway, inte en laptop-profil

Google Cloud VPN ansluter peer-gateways över IPsec, och dess vanliga frågor skiljer den plats-till-plats-rollen från klient-till-gateway-åtkomst. Att skapa en tunnel ger inte en profil som en anställd importerar på en laptop. Skillnaden spelar roll när någon begär en Cloud VPN-profil. Svaret är en annan produkt.

Det en gateway gör bra är att ge maskinerna bakom ett kontorsnätverk en rutt in i VPC:n. Den autentiserar inte varje anställd och ger inte applikationsbehörigheter, så dessa policyer stannar på nätverks- och applikationslagret där de kan verkställas per identitet.

Verifiera och registrera

Testa det smalaste målet först, sedan det som kräver DNS och sedan ett mål som måste förbli nekat. Kör varje test från samma klient som ska använda vägen i produktion, eftersom ett fungerande test från en administratörsarbetsstation bevisar lite om en utvecklares laptop med ett annat nätverk.

Registrera den valda modellen, de mål den täcker, de identiteter den autentiserar och felbeteendet när vägen inte är tillgänglig. Den registreringen är det som hindrar nästa förfrågan från att tyst utöka tunneln i stället för att lägga till ett mål i en dokumenterad design.