Se connecter en toute sécurité aux instances de VM

Lorsque vous développez des projets sur Compute Engine, il existe plusieurs cas de figure dans lesquels les instances ne doivent pas être accessibles depuis l'Internet public 

  • Les services Web sont en cours de développement et ne sont pas encore prêts à être exposés aux utilisateurs externes, car ils sont incomplets ou n'ont pas encore été configurés avec HTTPS.
  • L'instance fournit des services conçus pour être utilisés uniquement par d'autres instances du projet.
  • Les instances ne doivent être accessibles que par le biais d'interconnexions dédiées à partir des bureaux de l'entreprise ou des centres de données.

Même lorsqu'un service est intentionnellement connecté à Internet, il est important que la communication avec ce service soit limitée aux groupes d'utilisateurs cibles et se déroule sur des canaux sécurisés, tels que SSH ou HTTPS, afin de protéger les informations sensibles.

Dans cet article, vous découvrirez plusieurs méthodes permettant de sécuriser les communications avec les instances Compute Engine associées ou non à des adresses IP externes.

Protection des services sur des machines avec adresse IP externe

Connexion aux instances sans adresse IP externe

Protection des services sur des machines avec adresse IP externe

Lorsque les instances disposent d'une adresse IP publique, seuls les services et le trafic que vous souhaitez exposer doivent être accessibles, et, pour ces parties exposées, les informations sensibles doivent être sécurisées en transit.

Pare-feu

Votre première ligne de défense consiste à limiter les droits d'accès à l'instance à l'aide de pare-feu. En créant des règles de pare-feu, vous pouvez limiter à des adresses IP sources spécifiques tout le trafic vers un réseau ou des machines cibles sur un ensemble de ports donné.

Les pare-feu ne sont pas une solution autonome. La limitation du trafic à des adresses IP sources spécifiques ne protège pas les informations sensibles, telles que les identifiants de connexion, les commandes de création ou de destruction de ressources ou de fichiers, ou les journaux. Lorsque vous exécutez un service Web sur une machine accessible au public, telle qu'une instance Compute Engine dotée d'une adresse IP externe, vous devez chiffrer toutes les communications entre l'hôte et l'instance déployée pour assurer une sécurité adéquate.

De plus, les pare-feu ne sont pas toujours la solution appropriée. Par exemple, ils ne sont pas idéaux pour les environnements de développement qui n'ont pas d'adresse IP statique, tels que les ordinateurs portables en itinérance.

HTTPS et SSL

Pour les systèmes Web de production, vous devez configurer HTTPS/SSL. Pour ce faire, vous pouvez configurer une instance de sorte qu'elle résilie HTTPS ou configurer l'équilibrage de charge HTTPS. Les protocoles HTTPS/SSL sont assez complexes au départ et vous obligent à effectuer les tâches suivantes :

Si vous avez déjà configuré des domaines dotés d'un certificat SSL, vous devriez pouvoir facilement en faire de même avec Compute Engine. Sinon, vous pouvez utiliser une méthode de sécurité différente, telle que le transfert de port ou le proxy SOCKS.

Transfert de port sur SSH

Vous pouvez utiliser l'outil de ligne de commande gcloud pour démarrer un serveur sur un port local donné qui transfère tout le trafic vers un hôte distant via une connexion SSH.

Tout d'abord, notez l'instance et le port fournissant le service avec lequel vous souhaitez établir une connexion sécurisée. Puis, exécutez la commande suivante :

gcloud compute ssh example-instance \
    --project my-project \
    --zone us-central1-a \
    -- -L 2222:localhost:8888

Dans la commande ci-dessus, les paramètres sont définis comme suit :

  • example-instance est le nom de l'instance à laquelle vous souhaitez vous connecter.
  • my-project est l'ID de votre projet Google Cloud Platform (GCP).
  • us-central1-a est la zone dans laquelle votre instance s'exécute.
  • 2222 est le port local sur lequel vous écoutez.
  • 8888 est le port distant auquel vous vous connectez.

Avec ces exemples de paramètres, si vous ouvrez http://localhost:2222/ dans votre navigateur, la connexion HTTP passe par le tunnel SSH que vous venez de créer sur votre hôte distant et se connecte à l'instance spécifiée via SSH, puis se connecte au port 8888 sur le même ordinateur, mais via une connexion SSH chiffrée et sécurisée.

La commande gcloud permet de créer et de maintenir une connexion SSH, et cette approche ne fonctionne que lorsque la session SSH est active. Le transfert de port via http://localhost:2222/ cesse de fonctionner dès que vous quittez la session SSH créée par gcloud.

Si vous souhaitez créer plusieurs règles de transfert de port, vous pouvez le faire sur une même ligne de commande en répétant les indicateurs :

gcloud compute ssh example-instance \
    --project my-project \
    --zone us-central1-a \
    -- -L 2222:localhost:8888 -L 2299:localhost:8000

Vous pouvez également exécuter une nouvelle commande gcloud à chaque fois pour créer un nouveau tunnel. Notez que vous ne pouvez pas ajouter ou supprimer un transfert de port d'une connexion existante sans quitter et rétablir la connexion à partir de zéro.

Proxy SOCKS sur SSH

Si vous souhaitez vous connecter à plusieurs hôtes différents dans votre déploiement cloud, le moyen le plus simple consiste à modifier votre navigateur pour qu'il effectue les recherches directement à partir de votre réseau. Cette approche vous permet d'utiliser le surnom des hôtes au lieu de rechercher l'adresse IP de chacun d'eux, d'ouvrir des ports pour chaque service ou de créer un tunnel SSH pour chaque paire hôte/port.

L'approche à utiliser dans ce cas est la suivante :

  1. Configurez un seul tunnel SSH vers l'un des hôtes du réseau, puis créez un proxy SOCKS sur cet hôte.
  2. Modifiez la configuration du navigateur pour que celui-ci effectue toutes les recherches via cet hôte proxy SOCKS.

Étant donné que vous créez un tunnel pour tout le trafic via cet hôte, vous ne devez pas, de façon générale, naviguer sur le Web à l'aide de ce navigateur ou de ce profil spécifique. Pour cela, utilisez la bande passante de votre service cloud. Vous devez pouvoir normalement utiliser un profil de navigateur différent et basculer dessus si nécessaire.

Démarrage du proxy SOCKS

Pour démarrer votre proxy SOCKS, exécutez la commande suivante :

gcloud compute ssh example-instance \
    --project my-project \
    --zone us-central1-a \
    --ssh-flag="-D" \
    --ssh-flag="1080" \
    --ssh-flag="-N"

Dans la commande ci-dessus, les paramètres sont définis comme suit :

  • example-instance est le nom de l'instance à laquelle vous souhaitez vous connecter.
  • my-project est l'ID de votre projet GCP.
  • us-central1-a est la zone dans laquelle votre instance s'exécute.
  • 1080 est le port local sur lequel vous êtes à l'écoute.

Notez que, dans ce cas, vous n'avez pas besoin de spécifier un port distant. Dans la mesure où un proxy SOCKS n'est associé à aucun port distant spécifique, toute connexion établie via le proxy SOCKS sera résolue par rapport à l'hôte auquel vous vous connectez.

Avec un proxy SOCKS, vous pouvez vous connecter à toute instance qui partage un réseau Compute Engine avec votre instance proxy. Pour ce faire, utilisez le surnom de l'instance. De plus, vous pouvez vous connecter à n'importe quel port d'une instance donnée.

Cette approche est beaucoup plus flexible que la méthode simple de transfert de port, mais elle vous oblige à modifier les paramètres de votre navigateur Web pour utiliser le proxy.

Configurez ensuite Chrome ou Firefox pour utiliser le proxy.

Chrome

Par défaut, Chrome utilise les paramètres de proxy pour l'ensemble du système. Vous devez donc spécifier un proxy différent à l'aide des indicateurs de ligne de commande. Lorsque vous lancez Chrome par défaut, cela entraîne la création d'une instance d'un profil déjà actif. Par conséquent, pour pouvoir exécuter plusieurs copies de Chrome simultanément (une qui utilise le proxy et d'autres non), vous devez créer un nouveau profil.

Lancez Chrome en utilisant un nouveau profil. S'il n'existe pas encore, il sera créé automatiquement.

Linux :

"/usr/bin/google-chrome \
    --user-data-dir="$HOME/chrome-proxy-profile" \
    --proxy-server="socks5://localhost:1080"

macOS :

"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
    --user-data-dir="$HOME/chrome-proxy-profile" \
    --proxy-server="socks5://localhost:1080"

Windows :

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" ^
    --user-data-dir="%USERPROFILE%\chrome-proxy-profile" ^
    --proxy-server="socks5://localhost:1080"

Veillez à définir la même valeur pour le port "localhost" que celle que vous avez utilisée dans la commande gcloud (1080 dans notre exemple).

Firefox

Avant de modifier ces paramètres, il est conseillé de créer un nouveau profil Firefox. En effet, l'utilisation de cet hôte en tant que proxy affecte toutes les instances de Firefox, ce qui n'est généralement pas souhaitable.

Après avoir exécuté Firefox avec un autre profil, vous pouvez configurer le proxy SOCKS :

  1. Ouvrez les préférences.
  2. Cliquez sur Options avancées > Réseaux > Paramètres pour ouvrir la boîte de dialogue Paramètres de connexion.
  3. Choisissez l'option Configuration manuelle du proxy.
    1. Dans la section Hôte SOCKS, saisissez localhost en tant qu'hôte et le port que vous avez sélectionné lorsque vous avez exécuté la commande gcloud.
    2. Sélectionnez SOCKS v5.
    3. Cochez la case DNS distant.
    4. Laissez tous les autres champs vides.
  4. Cliquez sur OK et fermez la boîte de dialogue Préférences.

Connexion aux instances sans adresse IP externe

Lorsqu'une instance ne possède pas d'adresse IP externe, elle n'est accessible que par les autres instances du réseau, via la fonctionnalité de transfert TCP de Cloud Identity-Aware Proxy ou via une passerelle VPN gérée. Vous pouvez configurer des instances de votre réseau pour qu'elles agissent en tant que relais de confiance pour les connexions entrantes (hôtes bastion) ou la sortie réseau (passerelles NAT). Pour une connectivité plus transparente sans configurer de telles connexions, vous pouvez utiliser une ressource de passerelle VPN gérée.

Hôtes bastion

Les hôtes bastion fournissent un point d'entrée externe dans un réseau contenant des instances privées, comme le montre le schéma suivant.

Architecture des hôtes bastion agissant comme point d'entrée externe dans un réseau d'instances privées.

Ce type d'hôte peut constituer un point de renforcement ou d'audit unique, et être démarré et arrêté pour activer ou désactiver la communication SSH entrante depuis Internet. Via un hôte bastion, vous pouvez vous connecter à une instance qui ne dispose pas d'adresse IP externe. Cette approche vous permet de vous connecter à un environnement de développement ou de gérer l'instance de base de données de votre application externe, par exemple, sans configurer de règles de pare-feu supplémentaires.

Le renforcement complet d'un hôte bastion n'entre pas dans le cadre de cet article, mais vous pouvez effectuer les premières étapes suivantes :

  • Limiter la plage CIDR d'adresses IP sources pouvant communiquer avec le bastion
  • Configurer des règles de pare-feu qui autorisent le trafic SSH vers des instances privées provenant uniquement de l'hôte bastion

Par défaut, SSH sur les instances est configuré pour utiliser des clés privées pour l'authentification. Lorsque vous utilisez un hôte bastion, vous vous connectez d'abord à cet hôte, puis à votre instance privée cible. En raison de cette connexion en deux étapes, pour laquelle les hôtes bastion sont parfois appelés "serveurs jump", vous devez utiliser le transfert ssh afin d'atteindre la machine cible, au lieu de stocker la clé privée de la machine cible sur l'hôte bastion. Cette action est requise même si vous utilisez la même paire de clés pour les instances bastion et cible, car le bastion n'a un accès direct qu'à la moitié publique de la paire de clés.

Pour découvrir comment utiliser une instance d'hôte bastion pour se connecter à d'autres instances de votre réseau GCP et apprendre à vous servir du transfert ssh, consultez la section Se connecter à des instances sans adresse IP externe.

Cloud IAP pour le transfert TCP

L'utilisation de SSH avec la fonctionnalité de transfert TCP de Cloud IAP encapsule une connexion SSH en HTTPS. La fonctionnalité de transfert TCP de Cloud IAP l'envoie ensuite à l'instance distante.

Pour apprendre à vous connecter à une instance distante avec Cloud IAP, reportez-vous à la section Utiliser Cloud IAP pour le transfert TCP.

VPN

Cloud VPN vous permet de connecter votre réseau existant à votre réseau GCP via une connexion IPsec à une passerelle VPN. De cette manière, le trafic de votre site est acheminé directement vers les interfaces d'adresses IP privées des instances Compute Engine. Le trafic est chiffré lorsqu'il transite par des liens publics vers Google.

Pour en savoir plus sur la configuration et l'utilisation de VPN avec Compute Engine, reportez-vous à la documentation de Cloud VPN.

Pour découvrir comment vous connecter aux instances de votre réseau GCP via un VPN existant plutôt que via leurs adresses IP externes, consultez la page Se connecter à des instances sans adresse IP externe.

Trafic sortant à l'aide d'une passerelle NAT

Si aucune adresse IP externe n'est attribuée à une instance, cette instance ne peut pas établir de connexions directes avec des services externes, y compris d'autres services GCP. Pour permettre à ces instances d'accéder aux services sur l'Internet public, vous pouvez configurer une passerelle NAT, qui peut acheminer le trafic pour le compte de n'importe quelle instance du réseau. Sachez qu'une seule instance ne doit pas être considérée comme ayant une haute disponibilité et ne peut pas prendre en charge un débit de trafic élevé pour plusieurs instances.

Accès interactif à la console série

Même lorsqu'une instance ne possède aucune adresse IP externe, vous devez parfois interagir avec elle à des fins de dépannage ou de maintenance. La configuration d'un hôte bastion est une possibilité, mais elle peut nécessiter un plus gros effort de configuration qu'il n'en vaut la peine pour vos besoins. Si vous souhaitez dépanner une instance sans adresse IP externe, vous pouvez activer l'accès interactif sur la console série, ce qui vous permet d'interagir avec la console série d'une instance à l'aide de SSH et d'exécuter des commandes sur la console série.

Pour en savoir plus, consultez la section Interagir avec la console série.

Équilibreurs de charge proxy HTTPS et SSL

Les instances backend pour les équilibreurs de charge proxy HTTPS et SSL n'ont pas besoin d'adresses IP externes pour être accessibles via l'équilibreur de charge. Pour accéder directement à ces ressources, vous devez utiliser les méthodes répertoriées dans la section Connexion aux instances sans adresse IP externe.

Pour en savoir plus, lisez la documentation sur l'équilibrage de charge pour ces équilibreurs spécifiques.

Testez d'autres fonctionnalités de Google Cloud Platform. Découvrez nos tutoriels.

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Documentation Compute Engine