Acceso remoto de desenvolvedores a unha VPC de Google Cloud: escolla o camiño

Un desenvolvedor necesita unha sesión SSH, un porto de base de datos ou acceso amplo a unha ducia de servizos privados, e cada unha desas solicitudes parece a mesma pregunta. Non o é. Os destinos, os protocolos e as identidades implicadas deciden que camiño de acceso de Google Cloud encaixa, e escoller o máis amplo por defecto crea traballo que non tiña que asumir.

Anote os destinos e os protocolos

Enumere os enderezos privados, os portos e os protocolos que o traballo necesita de verdade, e despois marque que identidades deben autenticarse por separado. Un porto de base de datos e unha zona DNS privada son requisitos distintos, e un servizo UDP descarta por completo unha das opcións seguintes. Unha lista escrita tamén mostra o que non está a conceder. Esa é a parte que preguntan os revisores.

Fagao antes de abrir un oínte. A lista convértese máis tarde na proba de aceptación, e é a única forma fiable de distinguir un túnel estreito dun amplo que funciona por casualidade.

IAP para uns poucos servizos TCP

O reenvío TCP de Identity-Aware Proxy dá un túnel autenticado cara a recursos de VM elixibles sen expoñer o servizo a internet. A forma cotiá é gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a, e un só porto pode reenviarse localmente con gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a.

Tres cousas deben coincidir: quen chama necesita o rol de acceso ao túnel de IAP, a devasa debe admitir o rango de orixe de IAP e o destino debe ser alcanzable na instancia. A autorización para crear o túnel non é unha credencial de base de datos, un inicio de sesión SSH nin unha sesión RDP, así que deixe a autenticación da aplicación onde corresponde.

O reenvío TCP de IAP non é unha VPN de capa tres. Leva TCP a un destino seleccionado, non tráfico IP arbitrario nin UDP, e encaixa mal cando unha aplicación necesita DNS privado en moitos servizos.

Unha VPN de acceso remoto para unha alcanzabilidade máis ampla

Cando se requiren varios destinos, protocolos ou zonas DNS privadas, a mellor forma é unha VPN de acceso remoto xestionada de forma explícita nunha VM ou nun dispositivo compatible. Ese despregamento é independente de Cloud VPN xestionado por Google: vostede posúe a alta de identidade do cliente, as actualizacións de software, as rutas do cliente e as rutas de retorno da VPC.

Planifique a lista completa, non só o oínte público. Inclúa o conxunto de túneles, a ruta da VPC de volta, os controis de reenvío, a resolución DNS e a política de acceso por servizo. Unha VPN que conecta pero non pode resolver nomes internos fai fracasar o fluxo de traballo do desenvolvedor con tanta plenitude como unha que nunca conecta.

Cloud VPN é unha porta de sitio, non un perfil de portátil

Google Cloud VPN conecta portas pares mediante IPsec, e as súas preguntas frecuentes separan ese papel de sitio a sitio do acceso de cliente a porta. Crear un túnel non produce un perfil que un empregado importe nun portátil. A distinción importa cando alguén pide un perfil de Cloud VPN. A resposta é outro produto.

O que unha porta fai ben é dar ás máquinas detrás dunha rede de oficina unha ruta cara á VPC. Non autentica a cada empregado nin concede permisos de aplicación, así que esas políticas quedan nas capas de rede e aplicación, onde poden aplicarse por identidade.

Verifique e rexistre

Probe primeiro o destino máis estreito, despois o que require DNS e logo un destino que debe seguir denegado. Execute cada proba desde o mesmo cliente que usará o camiño en produción, porque unha proba que funciona desde unha estación de traballo de administrador demostra pouco sobre un portátil de desenvolvedor con outra rede.

Rexistre o modelo elixido, os destinos que cobre, as identidades que autentica e o comportamento de fallo cando o camiño non está dispoñible. Ese rexistro é o que impide que a seguinte solicitude amplíe o túnel en silencio en lugar de engadir un destino a un deseño documentado.