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

Ce document décrit les bonnes pratiques pour vous connecter en toute sécurité aux instances de machine virtuelle (VM) Compute Engine, y compris le stockage des clés d'hôte en activant les attributs d'invité et en empêchant l'accès aux VM depuis l'Internet public.

Avant de commencer

Si ce n'est pas déjà fait, configurez l'authentification. L'authentification est le processus permettant de valider votre identité pour accéder aux services et aux API Google Cloud. Pour exécuter du code ou des exemples depuis un environnement de développement local, vous pouvez vous authentifier auprès de Compute Engine comme suit :

Sélectionnez l'onglet correspondant à la façon dont vous prévoyez d'utiliser les exemples de cette page :
Console

Lorsque vous utilisez la console Google Cloud pour accéder aux services et aux API Google Cloud, vous n'avez pas besoin de configurer l'authentification.
gcloud
1. Installez Google Cloud CLI, puis initialisez-la en exécutant la commande suivante :
```
gcloud init
```
  Remarque : Si vous avez déjà installé gcloud CLI, assurez-vous que vous disposez de la dernière version en exécutant gcloud components update.
2. Définissez une région et une zone par défaut.

Stocker les clés d'hôte en activant les attributs d'invité

Une clé d'hôte est une paire de clés qui identifie un hôte ou une machine spécifiques. Lorsque vous vous connectez à un hôte distant, la clé d'hôte sert à vérifier que vous vous connectez bien à la machine prévue.

Si vous utilisez la commande gcloud compute ssh pour vous connecter à vos VM Linux, vous pouvez ajouter une couche de sécurité en stockant vos clés d'hôte en tant qu'attributs d'invité.

Le stockage de clés d'hôte SSH en tant qu'attributs d'invité améliore la sécurité de vos connexions en vous aidant à vous protéger contre les failles de type "attaque de l'homme du milieu" (man-in-the-middle ou MITM). Lors du démarrage initial d'une VM, si les attributs d'invité sont activés, Compute Engine stocke les clés d'hôte générées en tant qu'attributs d'invité. Compute Engine utilise ensuite ces clés d'hôte stockées pour vérifier toutes les connexions ultérieures à la VM.

Les clés d'hôte peuvent être stockées en tant qu'attributs d'invité sur les images de système d'exploitation publiques suivantes :

Debian
Ubuntu
Red Hat Enterprise Linux (RHEL)
CentOS
SUSE Linux Enterprise Server (SLES)

Pour inscrire les clés d'hôte dans des attributs d'invité, vous devez activer les attributs d'invité avant de démarrer l'instance de VM pour la première fois. Vous pouvez activer les attributs d'invité sur des VM sélectionnées lors de la création de la VM ou sur l'ensemble du projet.

Une fois que vous avez activé les attributs d'invité pour un projet ou une VM, l'agent OS invité publie automatiquement la clé d'hôte en tant qu'attribut d'invité. Si vous utilisez gcloud compute ssh au lieu d'un client SSH classique, la CLI gcloud lit automatiquement les attributs et met à jour le fichier known_hosts lors de votre prochaine connexion.

Pour stocker les clés d'hôte en tant qu'attributs d'invité, procédez comme suit :

Avant de démarrer votre VM pour la première fois, activez les attributs d'invité sur des VM sélectionnées lors de la création de la VM ou sur l'ensemble du projet.
Connectez-vous à votre VM à l'aide de gcloud compute ssh.
1. Assurez-vous de disposer de la dernière version de la CLI Google Cloud :
```
gcloud components update
```
2. Connectez-vous à la VM :
```
gcloud compute ssh --project=PROJECT_ID \
 --zone=ZONE \
 VM_NAME
```
  Remplacez l'élément suivant :
  - PROJECT_ID : ID du projet contenant la VM
  - ZONE : nom de la zone dans laquelle se trouve la VM.
  - VM_NAME : nom de la VM
  Si vous avez défini les propriétés par défaut de la CLI Google Cloud, vous pouvez omettre les options --project et --zone de cette commande. Exemple :
```
gcloud compute ssh VM_NAME
```
3. Consultez le message de démarrage. Par exemple, un système d'exploitation Debian peut afficher le message suivant :
```
Writing 3 keys to YOUR_HOME_DIRECTORY/.ssh/google_compute_known_hosts
Linux host-key-2 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u3 (2019-06-16) x86_64
```

Pour vérifier que les clés d'hôte sont bien stockées en tant qu'attributs d'invité pour cette VM, examinez les valeurs de clé d'hôte pour vous assurer que les clés SSH sont bien écrites dans les attributs d'invités de la VM (option 1) ou examinez le port série pour détecter la présence des clés d'hôte (option 2) :

Option 1 : vérifier les valeurs des clés d'hôte

Vous pouvez utiliser la CLI Google Cloud pour vérifier que les clés SSH sont bien écrites dans les attributs d'invité :

gcloud compute instances get-guest-attributes VM_NAME \
  --query-path="hostkeys/" \
  --zone=ZONE

Remplacez les éléments suivants :

VM_NAME : nom de la VM
ZONE : nom de la zone dans laquelle se trouve la VM

Le résultat ressemble à ce qui suit :

NAMESPACE  KEY                  VALUE
hostkeys   ecdsa-sha2-nistp256  AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBBJAGpTm
                                V3mFxBTHK1NIu9a7kVQWaHsZVaFUsqF8cLxQRQ+N96/Djiiuz1tucHQ8vBTJI=
hostkeys   ssh-ed25519          AAAAC3NzaC1lZDI1NTE5AAAAIM/WYBn3jIEW5t3BZumx0X/Htm61J6S9FcU8L
hostkeys   ssh-rsa              AAAAB3NzaC1yc2EAAAADAQABAAABAQDU3jReR/MoSttlWYfauW6qEqS2dhe5
                                Zdd3guYk2H7ZyxblNuP56nOl/IMuniVmsFa9v8W6MExViu6G5Cy4iIesot09
                                1hsgkG0U7sbWrXM10PQ8pnpI3B5arplCiEMhRtXy64rlW3Nx156bLdcxv5l+
                                7Unu4IviKlY43uqqwSyTv+V8q4ThpQ9dNbk1Gg838+KzazljzHahtbIaE1rm
                                I0L1lUqKiKLSLKuBgrI2Y/WSuqvqGEz+bMH7Ri4ht+7sAwykph6FbOgKqoBI
                                hVWBo38/Na/gEuvtmgULUwK+xy9zWg9k8k/Qtihc6El9GD9y

Option 2 : vérifier le port série

Affichez les sorties du port série.
Sélectionnez le port série 1.
Recherchez le message suivant :
```
INFO Wrote ssh-rsa host key to guest attributes
```
Si votre image utilise un système d'exploitation compatible, mais que les paramètres des attributs d'invité n'ont pas été activés avant le premier démarrage de la VM, vous pouvez être confronté au message suivant :
```
Unable to write ssh-rsa host key to guest attributes
```
Cela signifie que les clés d'hôte ne sont pas stockées en tant qu'attributs d'invité pour cette VM. Si vous souhaitez enregistrer des clés d'hôte pour des VM supplémentaires que vous prévoyez de créer, activez les attributs d'invité avant le premier démarrage de la VM.

Empêcher l'accès aux VM depuis l'Internet public

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

Les services Web en cours de développement qui 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.
La VM peut fournir des services conçus pour être utilisés uniquement par d'autres VM du projet.
Les VM qui 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 VM associées à des adresses IP externes et les VM sans adresses IP externes. Que vous sécurisiez ou non les communications avec ces méthodes, Google Cloud autorise toujours la communication entre une instance de VM et le serveur de métadonnées correspondant. Pour en savoir plus, consultez la section Trafic toujours autorisé.

Protection des services sur des machines avec adresse IP externe

Lorsque les VM 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. Ce document décrit plusieurs méthodes de protection des services sur les VM associées à des adresses IP externes, y compris les pare-feu, les protocoles HTTPS et SSL, le transfert de port sur SSH et le proxy SOCKS via SSH.

Pare-feu

Votre première ligne de défense consiste à limiter les droits d'accès à la VM à 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 VM Compute Engine dotée d'une adresse IP externe, vous devez chiffrer toutes les communications entre l'hôte et la VM 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 cela, vous pouvez configurer une VM pour arrêter 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 :

Enregistrer un nom de domaine
Acquérir un certificat SSL auprès d'une autorité de certification
Enregistrer le certificat auprès de votre équilibreur de charge HTTPS et de ses VM connectées, ou configurer un serveur Web ou un proxy avec résiliation SSL sur une ou plusieurs VM Compute Engine.

Transfert de port sur SSH

Vous pouvez utiliser la CLI Google Cloud 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 la VM 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 VM_NAME \
    --project PROJECT_ID \
    --zone ZONE \
    -- -NL LOCAL_PORT:localhost:REMOTE_PORT

Remplacez les éléments suivants :

VM_NAME est le nom de la VM à laquelle vous souhaitez vous connecter.
PROJECT_ID est votre ID de projet Google Cloud.
ZONE : zone dans laquelle votre VM s'exécute, par exemple, us-central1-a.
LOCAL_PORT : port local sur lequel vous écoutez, par exemple 2222.
REMOTE_PORT : port distant auquel vous vous connectez, par exemple, 8888

Par exemple, si vous spécifiez le port local "2222" et le port distant "8888", et que vous ouvrez http://localhost:2222/ dans votre navigateur, la connexion HTTP utilise le tunnel SSH que vous avez créé sur votre hôte distant pour se connecter à la VM spécifiée à l'aide de SSH. La connexion HTTP utilise ensuite le tunnel SSH pour se connecter au port 8888 sur la même machine, mais via une connexion SSH sécurisée et chiffrée.

La commande gcloud crée et maintient une connexion SSH tant que la session SSH est active. Dès que vous quittez la session SSH, le transfert de port à l'aide de http://VM_NAME:LOCAL_PORT cesse de fonctionner.

Pour créer plusieurs règles de transfert de port, vous pouvez spécifier plusieurs règles sur une même ligne de commande en répétant les options :

gcloud compute ssh VM_NAME \
    --project PROJECT_ID \
    --zone ZONE \
    -- -NL LOCAL_PORT:localhost:REMOTE_PORT \
    -- -NL LOCAL_PORT:localhost:REMOTE_PORT

Vous pouvez également exécuter à chaque fois une nouvelle commande gcloud 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 nom court des hôtes au lieu de rechercher l'adresse IP de chaque hôte, 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 :

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

Notez que, comme vous acheminez tout le trafic vers cet hôte, il est préférable de ne pas utiliser ce navigateur ou ce profil spécifique pour naviguer sur le Web, car vous devez dédier cette bande passante à votre service cloud. Généralement, il est conseillé d'utiliser un profil de navigateur différent et de basculer dessus au besoin.

Démarrage du proxy SOCKS

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

gcloud compute ssh VM_NAME \
    --project PROJECT_ID \
    --zone ZONE
    --ssh-flag="-D" \
    --ssh-flag="LOCAL_PORT" \
    --ssh-flag="-N"

Remplacez l'élément suivant :

VM_NAME : nom de la VM à laquelle vous souhaitez vous connecter.
PROJECT_ID : ID de votre projet Google Cloud.
ZONE : zone dans laquelle votre VM s'exécute, par exemple, us-central1-a.
LOCAL_PORT : port local sur lequel vous écoutez, par exemple 1080.

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.

À l'aide d'un proxy SOCKS, vous pouvez vous connecter à n'importe quelle VM qui partage un réseau Compute Engine avec votre VM proxy en utilisant le nom court de la VM. De plus, vous pouvez vous connecter à n'importe quel port d'une VM 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 VM 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 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"

Définissez le port localhost sur la même valeur que celle utilisée précédemment 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 VM 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 :

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

Se connecter à des VM sans adresse IP externe

Lorsque les VM n'ont pas d'adresses IP externes (y compris des VM backend pour les équilibreurs de charge proxy HTTPS et SSL), elles ne sont accessibles que comme suit :

Autres VM sur le réseau
Fonctionnalité de transfert TCP d'Identity-Aware Proxy
Serveur de métadonnées
SDK Google Cloud
Passerelle VPN gérée

Vous pouvez provisionner des VM sur votre réseau pour qu’elles agissent en tant que relais de confiance pour les connexions entrantes, appelées hôtes bastions. En outre, vous pouvez configurer une passerelle Cloud NAT pour le trafic réseau sortant, ou la console série interactive pour gérer les VM sans adresses IP externe ou résoudre les problèmes liés à celles-ci.

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.

Cet hôte peut fournir un point de fortification ou d'audit unique, et peut être démarré et arrêté pour activer ou désactiver le SSH entrant. En utilisant un hôte bastion, vous pouvez vous connecter à une VM sans 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 VM privées provenant uniquement de l'hôte bastion

Par défaut, SSH sur les VM est configuré pour utiliser des clés privées pour l'authentification. Lorsque vous utilisez un hôte bastion, vous devez d'abord vous connecter à l'hôte bastion, puis à votre VM 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. Vous devez procéder ainsi même si vous utilisez la même paire de clés pour les VM cibles et le bastion, car le bastion a un accès direct uniquement à la moitié publique de la paire de clés.

Pour savoir comment utiliser une instance d'hôte bastion pour vous connecter à d'autres VM de votre réseau Google Cloud, consultez la page Se connecter à des VM Linux à l'aide d'un hôte bastion.

Pour savoir comment utiliser le transfert ssh et découvrir d'autres méthodes pour vous connecter à des VM sans adresse IP externe, consultez la section Se connecter à des VM sans adresse IP externe

IAP pour le transfert TCP

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

Pour savoir comment vous connecter à une VM distante avec IAP, consultez la section Se connecter à des VM Linux à l'aide d'Identity-Aware Proxy.

VPN

Cloud VPN vous permet de connecter votre réseau existant à votre réseau Google Cloud à l'aide d'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 VM 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 savoir comment vous connecter à des VM de votre réseau Google Cloud via un VPN existant plutôt que via des adresses IP externes, consultez la page Se connecter à des VM Linux à l'aide de Cloud VPN ou de Cloud Interconnect.

Acheminer le trafic sortant à l'aide de Cloud NAT

Lorsqu'une VM ne possède pas d'adresse IP externe attribuée, elle ne peut pas établir de connexions directes avec des services externes, y compris d'autres services Google Cloud. Pour permettre à ces VM d'accéder aux services sur l'Internet public, vous pouvez mettre en place et configurer une passerelle Cloud NAT, qui peut acheminer le trafic pour le compte de n'importe quelle VM du réseau. Une seule VM ne peut pas être considérée comme hautement disponible ou capable de prendre en charge un débit élevé pour plusieurs VM.

Accès interactif à la console série

Même lorsqu'une VM 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 VM 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 VM à 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 VM faisant office de 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 VM sans adresse IP externe.

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