Guide : Centraliser le Contrôle d'Accès IP pour les VMs sur GCP

Ce guide a pour objectif de centraliser la gestion des accès par adresses IP aux machines virtuelles (VMs) au sein d'une organisation Google Cloud, et ce, sans nécessairement recourir à un déploiement de VPN par lequel tout le monde devrait passer.

En utilisant une Politique de Pare-feu Hiérarchique (Hierarchical Firewall Policy) , nous pouvons définir une liste d'adresses IP autorisées en un seul endroit et l'appliquer de manière sélective sur des dossiers ou des projets spécifiques, garantissant une gestion de la sécurité cohérente et simplifiée. Cette méthode est idéale pour contrôler le trafic entrant au niveau du réseau VPC, notamment pour des protocoles SSH ou Web Server.

Pré-requis : Rôles et Permissions IAM

Pour mettre en œuvre et gérer les politiques de pare-feu au niveau de l'organisation, vous devez disposer des rôles IAM appropriés.

Assurez-vous que votre compte dispose des permissions suivantes au niveau de l'Organisation (et pas simplement d’un projet) :

1. Administrateur des politiques de pare-feu de l'organisation roles/compute.orgFirewallPolicyAdmin : Permet de créer, modifier, supprimer et associer des politiques de pare-feu hiérarchiques. 2. Lecteur de l'organisation roles/resourcemanager.organizationViewer : Nécessaire pour lister et identifier votre ID d'organisation. 3. Administrateur réseau roles/compute.networkAdmin : Peut être nécessaire au niveau des projets pour tester la configuration et créer les ressources (VMs, réseaux VPC).

Mise en Œuvre

Étape 1: Identifier votre ID d'Organisation

L'ID de l'organisation est un identifiant numérique unique requis pour toutes les opérations `gcloud` au niveau de cette dernière.

▶️ Via l'interface utilisateur (Console GCP)

1. Ouvrez la console Google Cloud. 2. Dans la barre de sélection de projet en haut de la page, cliquez sur le menu déroulant. 3. La liste des projets et des dossiers s'affiche. L'organisation se trouve au sommet de la hiérarchie. L'ID est affiché à côté du nom de l'organisation, ou vous pouvez le trouver dans la section IAM & Admin > Gérer les ressources.

▶️ Via la ligne de commande (gcloud)Exécutez la commande suivante pour lister toutes les organisations auxquelles vous avez accès :

sql
gcloud organizations list

La sortie affichera le DISPLAY_NAME et l’ID de votre organisation. Notez cet ID pour les étapes suivantes.

Étape 2: Créer la politique pare-feu

Cette politique agira comme un conteneur pour nos règles d’accès.

▶️ Via l’interface utilisateur (Console GCP)

Assurez-vous d’avoir sélectionné votre Organisation dans le sélecteur de ressources en haut de la console.

Naviguez vers le menu VPC network > Firewall.

Cliquez sur l’onglet FIREWALL POLICIES.

Cliquez sur CREATE FIREWALL POLICY.

Donnez un nom à votre politique (ex: org-ip-allowlist-ssh) et une description claire (ex: Liste des IPs autorisées pour l'accès aux outils internes sur les VMs).

Cliquez sur Create.

▶️ Via la ligne de commande (gcloud)

Utilisez la commande suivante, en remplaçant les placeholders :

bash
gcloud compute firewall-policies create \
--short-name=org-ip-allowlist \
--organization=VOTRE_ID_ORGANISATION \
--description="Liste des IPs autorisées pour l'accès aux outils internes sur les VMs"

Étape 3: Ajouter les Règles de Pare-feu à la Politique

Nous allons maintenant définir les règles. La logique est d’autoriser un ensemble spécifique d’IPs avec une haute priorité, puis de bloquer tout le reste avec une priorité plus basse.

Règle 3.1: Autoriser l’accès (SSH/Web UI/ etc.) pour les adresses IP approuvées

Cette règle permettra explicitement aux IPs de vos collaborateurs d’accéder aux ports voulus (22 pour SSH mais aussi ceux qui donnent accès aux Web UI).

Priorité : Une valeur faible, comme 1000, pour qu’elle soit évaluée avant les règles de refus.

Action : Allow.

Source : La liste de vos adresses IP au format CIDR (ex: 90.79.206.107/32, 87.240.90.251/32).

Vous pouvez aussi définir la liste des addresses dans un “Address group” pour pouvoir l’utiliser à plusieurs endroits (voir en fin d’article).

▶️ Via l’interface utilisateur (Console GCP)

Cliquez sur le nom de la politique que vous venez de créer.

Cliquez sur ADD RULE.

Remplissez le formulaire :

Priority : 1000

Direction of traffic : Ingress

Action : Allow

Dans la section Source, sélectionnez IPv4 ranges et entrez votre liste d’adresses IP, séparées par des virgules. (Si vous avez créé un Address Group renseignez son nom dans la section Address group).

Dans la section Protocols and ports, spécifier selon vos besoins ou laissez l’autorisation en ‘All’.

Laissez la section Target par défaut pour que la règle s’applique à tous les réseaux VPC. (Vous pouvez aussi définir un tag que vous associerez aux ressources que vous voulez sécuriser)

Cliquez sur Create.

▶️ Via la ligne de commande (gcloud)

bash
# pour du ssh par exemple
gcloud compute firewall-policies rules create 1000 \
--firewall-policy=org-ip-allowlist \
--action=allow \
--description="Autoriser SSH pour les IPs des collaborateurs" \
--direction=INGRESS \
--src-ip-ranges="90.79.206.107/32,87.240.90.251/32" \
--layer4-configs=tcp:22 \
--organization=VOTRE_ID_ORGANISATION

Règle 3.2: (Recommandé) Bloquer tout autre accès SSH

Pour renforcer la sécurité, il est judicieux d’ajouter une règle qui bloque explicitement tout autre trafic sur les ports voulus. Cela empêche une règle de pare-feu VPC mal configurée dans un projet d’autoriser un accès non désiré.

Priorité : Une valeur élevée (priorité faible), comme 2000.

Action : Deny.

▶️ Via l’interface utilisateur (Console GCP)

Dans votre politique, cliquez à nouveau sur ADD RULE.

Remplissez le formulaire :

Priority : 2000

Direction of traffic : Ingress

Action : Deny

Source : 0.0.0.0/0 (pour tout le trafic IPv4).

Protocols and ports : En adéquation avec vos outils

▶️ Via la ligne de commande (gcloud)

bash
gcloud compute firewall-policies rules create 2000 \
--firewall-policy=org-ip-allowlist \
--action=deny \
--description="Bloquer tout autre trafic SSH entrant" \
--direction=INGRESS \
--src-ip-ranges="0.0.0.0/0" \
--layer4-configs=tcp:22 \
--organization=VOTRE_ID_ORGANISATION

Étape 4: Associer la Politique de Pare-feu à un Dossier

Une fois la politique et ses règles définies, vous devez l’appliquer à une ressource dans votre hiérarchie. Tous les projets et sous-dossiers hériteront de la politique.

▶️ Via l’interface utilisateur (Console GCP)

Retournez à la liste de vos politiques de pare-feu.

Cliquez sur votre politique nouvellement créée (org-ip-allowlist).

Cliquez sur ASSOCIATIONS dans le volet de détails qui s’ouvre, ou ouvrez la politique et allez dans l’onglet Associations.

Cliquez sur ADD ASSOCIATION.

Sélectionnez le nœud de votre hiérarchie (l’organisation entière ou un dossier spécifique) auquel vous souhaitez appliquer la politique.

Cliquez sur Create.

▶️ Via la ligne de commande (gcloud)

Pour associer la politique à un dossier, utilisez la commande suivante. Obtenez d’abord l’ID du dossier via gcloud resource-manager folders list.

bash
gcloud compute firewall-policies associations create \
--firewall-policy=org-ip-allowlist-ssh \
--folder=ID_DE_VOTRE_DOSSIER_OU_DE_ORGANIZATION \
--organization=ORGANIZATION

Étape 5: Tester et Valider la Configuration

La meilleure façon de valider est de tester la connectivité.

Créez une VM de test : Lancez une nouvelle instance Compute Engine dans un projet situé sous le dossier où la politique a été appliquée. Assurez-vous qu’elle dispose d’une adresse IP externe.

Test de l’échec (votre IP n’est pas dans la liste) :

Vérifiez que votre adresse IP publique actuelle n’est PAS dans la règle d’autorisation de votre politique de pare-feu.

Essayez de vous connecter en SSH à la VM (ou son interface en fonction de l’outil).

Résultat attendu : La connexion devrait échouer (timeout).

Mettez à jour la politique :

Modifiez la règle d’autorisation (priorité 1000) et ajoutez votre adresse IP actuelle à la liste des source-ranges.

Test du succès (votre IP est dans la liste) :

Attendez une minute pour que la politique se propage.

Essayez à nouveau de vous connecter en SSH.

Résultat attendu : La connexion devrait réussir.

Si ce scénario de test fonctionne, votre politique de pare-feu hiérarchique est correctement configurée.

Points Clés et Bonnes Pratiques

Héritage et Évaluation des Règles Les politiques de pare-feu hiérarchiques sont évaluées avant les règles de pare-feu VPC. Une règle deny au niveau de l’organisation ou du dossier l’emportera toujours sur une règle allow définie au niveau du VPC d’un projet. C’est ce qui rend cette approche si puissante.

Différence avec Cloud Armor Il est crucial de comprendre que les Politiques de Pare-feu Hiérarchiques s’appliquent au trafic réseau du VPC (VMs, GKE, etc.). Pour protéger des services exposés via un Load Balancer HTTPS Externe (comme des applications web sur des VMs, Cloud Run, ou App Engine), il faut utiliser Google Cloud Armor, qui opère à la périphérie du réseau de Google. Les deux outils sont complémentaires.

Gestion des Adresses IP Pour des listes d’adresses IP volumineuses ou changeant fréquemment, envisagez d’utiliser des Groupes d’adresses (Address Groups). Vous pouvez créer un groupe d’adresses au niveau de l’organisation et y référencer dans votre règle de pare-feu. Ainsi, pour ajouter ou retirer une IP, vous mettez à jour le groupe d’adresses sans jamais toucher à la règle elle-même, ce qui est plus simple et moins risqué.