Afgeleë ontwikkelaartoegang tot 'n Google Cloud VPC: kies die regte pad

'n Ontwikkelaar het een SSH-sessie, 'n databasispoort of breë toegang tot 'n dosyn private dienste nodig, en elkeen van daardie versoeke lyk soos dieselfde vraag. Dit is nie. Die bestemmings, die protokolle en die identiteite wat betrokke is, bepaal watter Google Cloud-toegangspad pas, en om by verstek die breedste een te kies skep werk wat jy nie nodig gehad het om te besit nie.

Skryf die bestemmings en protokolle neer

Lys die private adresse, poorte en protokolle wat die werk werklik nodig het, en merk dan watter identiteite afsonderlik geauthentiseer moet word. 'n Databasispoort en 'n private DNS-sone is verskillende vereistes, en 'n UDP-diens sluit een van die opsies hieronder heeltemal uit. 'n Geskrewe lys wys ook wat jy nie toestaan nie. Dit is die deel waaroor keurders vra.

Doen dit voordat jy 'n luisteraar oopmaak. Die lys word later die aanvaardingstoets, en dit is die enigste betroubare manier om 'n smal tonnel van 'n breë een wat toevallig werk te onderskei.

IAP vir 'n paar TCP-dienste

Identity-Aware Proxy TCP-aansturing gee 'n geauthentiseerde tonnel na geskikte VM-hulpbronne sonder om die diens aan die internet bloot te stel. Die daaglikse vorm is gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a, en 'n enkele poort kan plaaslik aangestuur word met gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a.

Drie dinge moet in lyn wees: die oproeper het die IAP-tonneltoegangsrol nodig, die vuurmuur moet die IAP-bronreeks toelaat, en die bestemming moet op die instansie bereikbaar wees. Magtiging om die tonnel te skep is nie 'n databasisbewys, 'n SSH-aanmelding of 'n RDP-sessie nie, so hou die toepassingverifikasie waar dit hoort.

IAP TCP-aansturing is nie 'n laag-drie VPN nie. Dit dra TCP na 'n gekose bestemming, nie willekeurige IP-verkeer of UDP nie, en dit pas swak wanneer 'n toepassing private DNS oor baie dienste nodig het.

'n Remote-access VPN vir breër bereikbaarheid

Wanneer verskeie bestemmings, protokolle of private DNS-sones vereis word, is 'n eksplisiet bestuurde remote-access VPN op 'n VM of ondersteunde toestel die beter vorm. Daardie ontplooiing is apart van Google se bestuurde Cloud VPN: jy besit die kliëntidentiteitsinskrywing, die sagteware-opdaterings, die kliëntroetes en die VPC-terugroetes.

Beplan die hele lys, nie net die openbare luisteraar nie. Sluit die tonnelpoel, die VPC-roete terug daarheen, aanstuurbeheer, DNS-resolusie en toegangsbeleid per diens in. 'n VPN wat verbind maar nie interne name kan oplos nie, faal die ontwikkelaar se werkvloei net so heeltemal soos een wat nooit verbind nie.

Cloud VPN is 'n terreinpoort, nie 'n skootrekenaarprofiel nie

Google Cloud VPN verbind eweknie-poorte oor IPsec, en sy gereelde vrae skei daardie terrein-tot-terrein-rol van kliënt-tot-poort-toegang. Om 'n tonnel te skep produseer nie 'n profiel wat 'n werknemer op 'n skootrekenaar invoer nie. Die onderskeid maak saak wanneer iemand vir 'n Cloud VPN-profiel vra. Die antwoord is 'n ander produk.

Wat 'n poort goed doen, is om die masjiene agter 'n kantoornetwerk 'n roete in die VPC te gee. Dit verifieer nie elke werknemer nie en verleen nie toepassingstoestemmings nie, so daardie beleide bly op die netwerk- en toepassinglae waar dit per identiteit afgedwing kan word.

Verifieer en teken aan

Toets eers die smalste bestemming, dan die een wat DNS vereis, dan 'n bestemming wat geweier moet bly. Voer elke toets uit vanaf dieselfde kliënt wat die pad in produksie sal gebruik, want 'n werkende toets vanaf 'n administrateur-werkstasie bewys min oor 'n ontwikkelaar se skootrekenaar met 'n ander netwerk.

Teken die gekose model aan, die bestemmings wat dit dek, die identiteite wat dit verifieer en die foutgedrag wanneer die pad onbeskikbaar is. Daardie rekord is wat verhoed dat die volgende versoek die tonnel stilweg verbreed in plaas daarvan om een bestemming by 'n gedokumenteerde ontwerp te voeg.