Accès distant des développeurs à un VPC Google Cloud : choisissez le bon chemin

Un développeur a besoin d'une session SSH, d'un port de base de données ou d'un large accès à une douzaine de services privés, et chacune de ces demandes ressemble à la même question. Ce n'est pas le cas. Les destinations, les protocoles et les identités impliqués décident quel chemin d'accès Google Cloud convient, et choisir le plus large par défaut crée un travail que vous n'aviez pas à assumer.

Notez les destinations et les protocoles

Listez les adresses privées, les ports et les protocoles dont le travail a réellement besoin, puis marquez quelles identités doivent être authentifiées séparément. Un port de base de données et une zone DNS privée sont des exigences différentes, et un service UDP exclut entièrement l'une des options ci-dessous. Une liste écrite montre aussi ce que vous n'accordez pas. C'est la partie que les relecteurs demandent.

Faites-le avant d'ouvrir un écouteur. La liste devient plus tard le test d'acceptation, et c'est la seule façon fiable de distinguer un tunnel étroit d'un tunnel large qui fonctionne par hasard.

IAP pour quelques services TCP

Le transfert TCP d'Identity-Aware Proxy donne un tunnel authentifié vers des ressources VM éligibles sans exposer le service à internet. La forme courante est gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a, et un seul port peut être transféré localement avec gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a.

Trois choses doivent s'aligner : l'appelant a besoin du rôle d'accès au tunnel IAP, le pare-feu doit admettre la plage source IAP, et la destination doit être joignable sur l'instance. L'autorisation de créer le tunnel n'est pas un identifiant de base de données, une connexion SSH ni une session RDP, alors gardez l'authentification de l'application là où elle appartient.

Le transfert TCP d'IAP n'est pas un VPN de couche trois. Il transporte du TCP vers une destination choisie, pas du trafic IP arbitraire ni de l'UDP, et il convient mal lorsqu'une application a besoin d'un DNS privé sur de nombreux services.

Un VPN d'accès distant pour une joignabilité plus large

Lorsque plusieurs destinations, protocoles ou zones DNS privées sont nécessaires, la meilleure forme est un VPN d'accès distant géré explicitement sur une VM ou un appareil pris en charge. Ce déploiement est distinct de Cloud VPN géré par Google : vous possédez l'enrôlement de l'identité client, les mises à jour logicielles, les routes client et les routes de retour du VPC.

Planifiez toute la liste, pas seulement l'écouteur public. Incluez le pool de tunnels, la route VPC de retour vers celui-ci, les contrôles de transfert, la résolution DNS et la politique d'accès par service. Un VPN qui se connecte mais ne peut pas résoudre les noms internes fait échouer le flux de travail du développeur tout aussi complètement qu'un VPN qui ne se connecte jamais.

Cloud VPN est une passerelle de site, pas un profil d'ordinateur portable

Google Cloud VPN connecte des passerelles homologues via IPsec, et sa FAQ sépare ce rôle de site à site de l'accès client à passerelle. Créer un tunnel ne produit pas un profil qu'un employé importe sur un ordinateur portable. La distinction compte quand quelqu'un demande un profil Cloud VPN. La réponse est un autre produit.

Ce qu'une passerelle fait bien, c'est donner aux machines derrière un réseau de bureau une route vers le VPC. Elle n'authentifie pas chaque employé et n'accorde pas de permissions d'application, donc ces politiques restent aux couches réseau et application, où elles peuvent être appliquées par identité.

Vérifiez et consignez

Testez d'abord la destination la plus étroite, puis celle qui exige du DNS, puis une destination qui doit rester refusée. Exécutez chaque test depuis le même client que celui qui utilisera le chemin en production, car un test qui fonctionne depuis un poste d'administrateur prouve peu de choses sur un ordinateur portable de développeur avec un autre réseau.

Consignez le modèle choisi, les destinations qu'il couvre, les identités qu'il authentifie et le comportement en cas de défaillance lorsque le chemin n'est pas disponible. Cette consignation est ce qui empêche la demande suivante d'élargir silencieusement le tunnel au lieu d'ajouter une destination à une conception documentée.