Stratégie de pare-feu hiérarchique avec des tags gérés par IAM

1. Introduction

Cloud Next Generation Firewall (NGFW)

Cloud Next Generation Firewall est un service de pare-feu entièrement distribué offrant des fonctionnalités de protection avancées, une microsegmentation et une couverture omniprésente pour protéger vos charges de travail Google Cloud contre les attaques internes et externes.

Cloud NGFW présente les avantages suivants :

Service de pare-feu distribué : Cloud NGFW fournit une application basée sur l'hôte entièrement distribuée avec état pour chaque charge de travail afin d'offrir une architecture de sécurité zéro confiance.
Configuration et déploiement simplifiés : Cloud NGFW implémente des stratégies de pare-feu réseau et hiérarchiques pouvant être associées à un nœud de la hiérarchie des ressources. Ces stratégies fournissent une expérience de pare-feu cohérente dans la hiérarchie des ressources Google Cloud.
Contrôle précis et microsegmentation : la combinaison des stratégies de pare-feu et des tags gérés par IAM (Identity and Access Management) offre un contrôle précis pour le trafic Nord-Sud et le trafic Est-Ouest sur une seule VM dans les réseaux de cloud privé virtuel (VPC).

Stratégies de pare-feu réseau

Une stratégie de pare-feu réseau fait office de conteneur pour les règles de pare-feu. Les règles définies dans une stratégie de pare-feu réseau ne sont appliquées nulle part tant que la stratégie n'est pas associée à un réseau VPC. Chaque réseau VPC peut être associé à une stratégie de pare-feu réseau. Les stratégies de pare-feu réseau sont compatibles avec les Tags gérés par IAM (ou simplement "Tags") dans les règles de pare-feu. Ces Tags peuvent être utilisés pour fournir une identité à la charge de travail.

Le partage d'une stratégie de pare-feu réseau entre plusieurs réseaux et l'intégration avec les Tags gérés par IAM simplifient considérablement la configuration et la gestion des pare-feu.

Avec l'introduction des stratégies de pare-feu réseau, les stratégies de pare-feu de Google Cloud se composent désormais des éléments suivants :

Les stratégies de pare-feu hiérarchiques sont compatibles avec les nœuds d'organisation et de dossier de la hiérarchie des ressources, tandis que les règles de pare-feu VPC et les stratégies de pare-feu réseau sont appliquées au niveau du VPC. Il existe une différence majeure entre les règles de pare-feu VPC et les stratégies de pare-feu réseau : les règles de pare-feu VPC ne peuvent être appliquées qu'à un seul réseau VPC, tandis que les stratégies de pare-feu réseau peuvent être associées à un seul VPC ou à un groupe de VPC, entre autres avantages comme les mises à jour groupées.

Dans cet atelier, nous allons tester les stratégies de pare-feu hiérarchiques et les stratégies de pare-feu réseau mondiales.

Enfin, nous avons également les règles de pare-feu implicites fournies avec chaque réseau VPC :

Une règle de sortie dont l'action est "allow" et dont la destination est 0.0.0.0/0
Une règle d'entrée dont l'action est "deny" et la source est 0.0.0.0/0

Par défaut, la séquence d'application est illustrée dans le schéma suivant :

Tags gérés par IAM

Les nouveaux tags intégrés aux règles des stratégies de pare-feu sont des ressources de paires clé-valeur définies au niveau de l'organisation ou du projet dans la hiérarchie des ressources Google Cloud. Un tel tag contient un contrôle des accès IAM qui, comme son nom l'indique, spécifie qui peut faire quoi sur le tag. Les autorisations IAM, par exemple, permettent de spécifier les comptes principaux qui peuvent attribuer des valeurs aux tags et ceux qui peuvent associer des tags aux ressources. Une fois qu'un tag a été appliqué à une ressource, les règles de stratégie de pare-feu peuvent l'utiliser pour autoriser et refuser le trafic.

Les tags respectent le modèle de ressource d'héritage de Google Cloud, ce qui signifie que les tags et leurs valeurs sont transmis dans la hiérarchie depuis leurs parents. Par conséquent, les tags peuvent être créés à un emplacement, puis utilisés par d'autres dossiers et projets dans toute la hiérarchie de ressources. Pour en savoir plus sur les tags et la restriction des accès, consultez cette page.

Vous ne devez pas confondre les tags avec les tags réseau. Ces derniers sont des chaînes pouvant être ajoutées aux instances Compute Engine. Ils sont associés à l'instance et disparaissent lorsque celle-ci est mise hors service. Les règles de pare-feu VPC peuvent inclure des tags réseau, mais comme ils ne sont pas considérés comme des ressources cloud, ils ne sont pas soumis au contrôle des accès IAM. Pour en savoir plus sur la différence, consultez cette page.

2. Points abordés

Découvrez comment créer des tags régis par IAM à utiliser avec Cloud NGFW et de portée mondiale.
Découvrez comment associer des tags à des VM.
Découvrez comment créer une stratégie de pare-feu hiérarchique et l'associer à un dossier.
Créer une règle de pare-feu dans la stratégie de pare-feu hiérarchique et spécifier la source et la cible à l'aide de tags gérés par IAM

3. Architecture globale de l'atelier

Organisation et dossiers :

Vous allez créer deux dossiers, folder1 et folder2, directement sous votre organisation.

Projets :

Dans folder1, vous allez créer un projet hôte. Ce projet contiendra le réseau VPC partagé.
Dans folder2, vous allez créer un projet de service. Ce projet contiendra les VM qui utilisent le VPC partagé.

Mise en réseau :

Un réseau VPC nommé mynet sera créé dans le projet hôte et configuré en tant que VPC partagé. Cela permet aux ressources du projet de service d'utiliser le réseau.
Deux VM seront créées dans le projet de service et connectées au VPC partagé mynet.

Tags gérés par IAM :

Vous allez créer un tag régi par IAM nommé http_tags avec deux valeurs, http_server et http_client, au niveau de l'organisation. Ces tags/valeurs seront utilisés pour identifier les VM et leur appliquer des règles de pare-feu.

Stratégies de pare-feu :

Une stratégie de pare-feu hiérarchique sera créée et associée à folder1. Une règle de cette stratégie utilisera les tags régis par IAM pour autoriser le trafic de http-client vers http-server sur le port 80.
Une stratégie de pare-feu réseau sera créée dans le projet hôte et associée au VPC mynet. Cette stratégie inclura une règle permettant l'accès SSH IAP aux VM à des fins de test.

4. Étapes de préparation

Commencez par configurer les rôles IAM, l'infrastructure réseau et les instances nécessaires dans votre organisation Google Cloud.

Rôles IAM requis pour effectuer l'atelier

Nous allons commencer par attribuer les rôles IAM requis au compte GCP au niveau de l'organisation.

Administrateur de l'organisation (roles/resourcemanager.organizationAdmin) : ce rôle vous permet de gérer les stratégies IAM et d'afficher les règles d'administration des organisations, des dossiers et des projets.
Administrateur de tags(roles/resourcemanager.tagAdmin) : ce rôle vous permet de créer, de mettre à jour et de supprimer des tags sécurisés.
Rôle Utilisateur de tags (roles/resourcemanager.tagUser) : ce rôle vous permet d'accéder à la liste des tags sécurisés et de gérer leurs associations aux ressources.
Rôle Administrateur des règles de pare-feu de l'organisation Compute (roles/compute.orgFirewallPolicyAdmin) : ce rôle vous permet de contrôler entièrement les règles de pare-feu de l'organisation Compute Engine.
Rôle Administrateur des ressources de l'organisation Compute (roles/compute.orgSecurityResourceAdmin) : ce rôle vous permet de contrôler entièrement les associations des règles de pare-feu Compute Engine à l'organisation ou au dossier.
Administrateur de réseaux Compute (roles/compute.networkAdmin) : ce rôle vous permet de contrôler entièrement les ressources réseau Compute Engine.
Administrateur d'instances Compute( bêta) (roles/compute.instanceAdmin) : ce rôle vous permet de contrôler totalement les ressources d'instances Compute Engine.
Administrateur Logging (roles/logging.admin) : ce rôle vous donne accès à toutes les autorisations de Logging et aux autorisations associées.
Administrateur de compte de service (roles/iam.serviceAccountAdmin) : ce rôle vous permet de créer et de gérer des comptes de service.
Administrateur d'utilisation du service (roles/serviceusage.serviceUsageAdmin) : ce rôle vous permet d'activer, de désactiver et d'inspecter les états de service, d'inspecter les opérations, et de consommer les quotas et la facturation pour un projet destiné à un consommateur.
Administrateur VPC Compute partagé (roles/compute.xpnAdmin) : ce rôle vous permet d'administrer un réseau VPC partagé (XPN).

Créer des dossiers et des projets

Dans Cloud Shell, procédez comme suit pour créer folder1 et folder2 :

gcloud auth login

export org_id=$(gcloud organizations list --format='value(ID)')
export BILLING_ACCOUNT_ID=$(gcloud billing accounts list --format='value(ACCOUNT_ID)')
export folder1=[FOLDER1 NAME]
export folder2=[FOLDER2 NAME]
export hostproject=[HOST PROJECT NAME]
export serviceproject=[SERVICE PROJECT NAME]
export regionname=[REGION NAME]
export zonename=[COMPUTE ZONE NAME]

gcloud resource-manager folders create --display-name=$folder1 --organization=$org_id
export folder1_id=$(gcloud resource-manager folders list --organization=$org_id --filter="displayName=$folder1" --format="value(ID)")
gcloud resource-manager folders create --display-name=$folder2 --organization=$org_id
export folder2_id=$(gcloud resource-manager folders list --organization=$org_id --filter="displayName=$folder2" --format="value(ID)")

Dans Cloud Shell, procédez comme suit pour créer le projet hôte sous folder1 :

gcloud projects create  --name=$hostproject --folder=$folder1_id

Le message suivant s'affiche. Appuyez sur Y pour créer le projet avec le nouvel ID de projet.

No project ID provided.

Use [NEW-PROJECT-ID] as project ID (Y/n)?

Notez l'ID du projet. Dans Cloud Shell, procédez comme suit pour l'exporter vers hostproject_id :

export hostproject_id=[HOSTPROJECT ID]

Dans Cloud Shell, procédez comme suit pour associer le projet hôte au compte de facturation :

gcloud billing projects link $hostproject_id \
--billing-account=$BILLING_ACCOUNT_ID

Dans Cloud Shell, procédez comme suit pour créer le projet de service sous folder2 :

gcloud projects create  --name=$serviceproject --folder=$folder2_id

Le message suivant s'affiche. Appuyez sur Y pour créer le projet avec le nouvel ID de projet.

No project ID provided.

Use [NEW-PROJECT-ID] as project ID (Y/n)?

Notez l'ID du projet. Dans Cloud Shell, procédez comme suit pour l'exporter vers serviceproject_id :

export serviceproject_id=[SERVICEPROJECT ID]

Dans Cloud Shell, procédez comme suit pour associer le projet de service au compte de facturation :

gcloud billing projects link $serviceproject_id \
--billing-account=$BILLING_ACCOUNT_ID

Créer des tags gérés par IAM

Un tag est une paire clé-valeur pouvant être associée à une organisation, un dossier ou un projet. Pour en savoir plus, consultez Créer et gérer des tags et les autorisations requises.

Nous créons un tag au niveau de l'organisation, http-tags. Le tag est destiné à être utilisé avec Cloud NGFW. Nous ne limitons pas le champ d'application à un seul réseau. Le tag est défini au niveau mondial. Nous appliquerons ensuite le tag aux VM créées dans le projet de service sous folder2.

Dans Cloud Shell, procédez comme suit :

gcloud resource-manager tags keys create http_tags \
    --parent=organizations/$org_id \
    --purpose GCE_FIREWALL \
    --purpose-data organization=auto

Nous utiliserons l'ID de clé de tag pour annoter la VM lors de sa création. Dans Cloud Shell, procédez comme suit pour obtenir l'ID de clé de tag :

export http_tags_id=$(gcloud resource-manager tags keys describe $org_id/http_tags --format="value(name)")
echo $http_tags_id

Dans Cloud Shell, créez deux valeurs de tag, http_server et http_client :

 gcloud resource-manager tags values create http_server \
      --parent $org_id/http_tags
 gcloud resource-manager tags values create http_client \
      --parent $org_id/http_tags

Nous utiliserons l'ID et la valeur de tag pour annoter la VM lors de sa création. Dans Cloud Shell, procédez comme suit pour obtenir l'ID de valeur de tag de http_server et http_client :

export http_tags_http_server_id=$(gcloud resource-manager tags values describe $org_id/http_tags/http_server --format="value(name)")
echo $http_tags_http_server_id

export http_tags_http_client_id=$(gcloud resource-manager tags values describe $org_id/http_tags/http_client --format="value(name)")
echo $http_tags_http_client_id

Activer les API dans le projet hôte et le projet de service

Dans Cloud Shell, procédez comme suit :

gcloud services enable compute.googleapis.com --project=$serviceproject_id
gcloud services enable compute.googleapis.com --project=$hostproject_id

Créer un VPC dans le projet hôte

Dans le projet hôte, créez un réseau VPC avec un mode de sous-réseau personnalisé. Pour ce faire, exécutez les commandes suivantes dans Cloud Shell :

gcloud compute networks create mynet \
    --subnet-mode=custom \
    --project=$hostproject_id

Créer des sous-réseaux dans le projet hôte

Dans Cloud Shell, procédez comme suit pour créer un sous-réseau IPv4 :

gcloud compute networks subnets create mysubnet \
    --network=mynet \
    --range=10.0.0.0/28 \
    --region=$regionname \
    --project=$hostproject_id

Activer le VPC partagé dans le projet hôte

Dans Cloud Shell, procédez comme suit pour activer le VPC partagé dans le projet hôte :

gcloud compute shared-vpc enable $hostproject_id

Associer un projet de service pour le VPC partagé dans le projet hôte

Dans Cloud Shell, procédez comme suit pour associer un projet de service au VPC partagé dans le projet hôte :

gcloud compute shared-vpc associated-projects add $serviceproject_id --host-project=$hostproject_id

Créer un routeur Cloud Router et Cloud NAT dans le projet hôte

Cloud NAT est utilisé pour permettre aux VM d'accéder à Internet afin de télécharger et d'installer des applications.

gcloud compute routers create $regionname-cr \
   --network=mynet \
   --region=$regionname \
   --project=$hostproject_id
gcloud compute routers nats create $regionname-nat \
    --router=$regionname-cr \
    --region=$regionname \
    --nat-all-subnet-ip-ranges \
    --auto-allocate-nat-external-ips \
    --project=$hostproject_id

Créer des instances dans le projet de service

Dans le projet de service, créez deux instances dans les sous-réseaux que vous venez de créer dans le VPC partagé du projet hôte. Une instance est nommée http-server et nous annotons le tag de http_tags avec la valeur de http_server. L'autre instance est nommée http-client et nous annotons le tag http_tags avec la valeur http_client. Exécutez la ou les commandes suivantes dans Cloud Shell :

gcloud compute instances create http-client \
    --project=$serviceproject_id \
   --subnet=projects/$hostproject_id/regions/$regionname/subnetworks/mysubnet \
    --zone=$zonename \
    --no-address \
    --resource-manager-tags=$http_tags_id=$http_tags_http_client_id

gcloud compute instances create http-server \
    --project=$serviceproject_id \
    --subnet=projects/$hostproject_id/regions/$regionname/subnetworks/mysubnet \
    --zone=$zonename \
    --no-address \
    --resource-manager-tags=$http_tags_id=$http_tags_http_server_id \
    --metadata startup-script='#! /bin/bash
    sudo apt-get update
    sudo apt-get install apache2 -y
    a2enmod ssl
    sudo a2ensite default-ssl
    echo "I am a Http Server." | \
    tee /var/www/html/index.html
    systemctl restart apache2'

Notez l'adresse IP interne de http-server. Nous l'utiliserons lors de l'étape de test des règles de pare-feu.

export http_server_ip=$(gcloud compute instances describe http-server --zone $zonename --format='value(networkInterfaces[0].networkIP)' --project $serviceproject_id)
echo $http_server_ip

5. Créer une stratégie de pare-feu de réseau au niveau mondial dans le projet hôte

Nous allons créer une stratégie de pare-feu réseau au niveau mondial dans le projet hôte et l'associer au VPC partagé dans le projet hôte.

gcloud config set project $hostproject_id
gcloud compute network-firewall-policies create  mynet-fw-policy \
--global \
--project=$hostproject_id
gcloud compute network-firewall-policies associations create \
    --firewall-policy=mynet-fw-policy \
    --network=mynet \
    --name=mynet-fw-policy \
    --global-firewall-policy \
    --project=$hostproject_id

Pour permettre à IAP de se connecter à vos instances de VM, créez une règle de pare-feu dans la stratégie de pare-feu réseau :

S'applique à toutes les instances de VM auxquelles vous souhaitez être accessible à l'aide d'IAP.
Autorise le trafic entrant à partir de la plage d'adresses IP 35.235.240.0/20. Cette plage contient toutes les adresses IP qu'IAP utilise pour le transfert TCP.

gcloud compute network-firewall-policies rules create 1000 \
    --action=ALLOW \
    --firewall-policy=mynet-fw-policy \
    --description="mynet-allow-iap" \
    --direction=INGRESS \
    --src-ip-ranges=35.235.240.0/20 \
    --layer4-configs=tcp:22  \
    --global-firewall-policy \
    --project=$hostproject_id

Dans la console, vous pouvez accéder au projet hôte et trouver la stratégie de pare-feu réseau au niveau mondial que vous venez de créer sous "Stratégie de pare-feu". Vous pouvez vérifier la règle de pare-feu que vous venez de créer dans la stratégie de pare-feu réseau. Pour y accéder, cliquez sur ce lien. Veuillez vous assurer de sélectionner le projet hôte dans le sélecteur de projet de la console.

6. Tester l'accès de la VM http-client à la VM http-server

Connectez-vous en SSH à la VM nommée http-client et vérifiez si elle peut accéder à http-server sur le port HTTP 80.

Dans Cloud Shell, procédez comme suit :

gcloud compute ssh \
    --zone=$zonename "http-client" \
    --tunnel-through-iap \
    --project=$serviceproject_id

Utilisez curl pour accéder au serveur Web.

curl -m 10 [http_server_ip]

Le résultat de la commande curl s'affiche. Aucune règle de pare-feu d'entrée n'autorise le port 80 pour http-server.

La connexion a expiré au bout de 10 000 millisecondes.

Revenez à Cloud Shell en quittant la session SSH.

exit

7. Créer une stratégie de pare-feu hiérarchique et des règles de pare-feu

Nous allons créer une stratégie de pare-feu hiérarchique au niveau de folder1 et l'associer à folder1. Les règles de pare-feu de la stratégie s'appliqueront au projet hôte sous folder1.

Créer une stratégie de pare-feu hiérarchique

gcloud compute firewall-policies create \
  --folder=$folder1_id \
  --short-name=my-folder1-fw-policy

Créer une règle de pare-feu dans la stratégie de pare-feu hiérarchique

La règle autorise les VM dont la valeur de tag est http_tags/http_client à accéder aux VM dont la valeur de tag est http_tags/http_server sur le port TCP 80.

gcloud compute firewall-policies rules create 100 \
  --organization=$org_id \
  --firewall-policy my-folder1-fw-policy \
  --direction=INGRESS \
  --layer4-configs=tcp:80 \
  --action=allow \
  --src-secure-tags=$org_id/http_tags/http_client \
  --target-secure-tags=$org_id/http_tags/http_server \
  --description=folder1-allow-http

Associer une stratégie de pare-feu hiérarchique à folder1

gcloud compute firewall-policies associations create \
   --firewall-policy=my-folder1-fw-policy \
   --folder=$folder1_id \
   --name=my-folder1-fw-policy\
   --organization=$org_id

Dans la console, vous pouvez accéder à folder1 et trouver la stratégie de pare-feu hiérarchique nouvellement créée sous "Stratégie de pare-feu". La stratégie de pare-feu s'affiche dans "Stratégies de pare-feu situées dans ce dossier". Vous pouvez vérifier la règle de pare-feu que vous venez de créer dans la stratégie de pare-feu hiérarchique. Pour y accéder, cliquez sur ce lien. Veuillez vous assurer de sélectionner folder1 dans le sélecteur de projet de la console.

8. Tester l'accès de la VM http-client à la VM http-server

Vérifiez les stratégies de pare-feu effectives appliquées au VPC partagé dans le projet hôte.

Dans Cloud Shell, procédez comme suit :

gcloud compute networks get-effective-firewalls mynet --project=$hostproject_id

La stratégie de pare-feu hiérarchique héritée s'affiche comme suit :

TYPE: org-firewall
FIREWALL_POLICY_NAME: <NUMBER_FOR_YOUR_FW_POLICY>
FIREWALL_POLICY_PRIORITY: 
PRIORITY: 100
ACTION: ALLOW
DIRECTION: INGRESS
DISABLED: False
IP_RANGES:

You will see the network firewall policy to the VPC like this:
TYPE: network-firewall-policy
FIREWALL_POLICY_NAME: mynet-fw-policy
FIREWALL_POLICY_PRIORITY: 1000
PRIORITY: 1000
ACTION: ALLOW
DIRECTION: INGRESS
DISABLED: False
IP_RANGES: 35.235.240.0/20

Connectez-vous en SSH à la VM nommée http-client et vérifiez si elle peut accéder à http-server sur le port HTTP 80.

Dans Cloud Shell, procédez comme suit :

gcloud compute ssh \
    --zone=$zonename "http-client" \
    --tunnel-through-iap \
    --project=$serviceproject_id

Utilisez curl pour accéder au serveur Web.

curl [http_server_ip]

La commande curl renvoie une réponse de http-server.

I am a Http Server.

Une règle de pare-feu d'entrée de la stratégie de pare-feu hiérarchique autorise l'accès de http-client à http-server sur le port 80.

Revenez à Cloud Shell en quittant la session SSH.

exit

9. Effectuer un nettoyage

Nettoyer les VM dans le projet de service

Dans Cloud Shell, procédez comme suit :

gcloud compute instances delete http-server --zone $zonename --project=$serviceproject_id
gcloud compute instances delete http-client --zone $zonename --project=$serviceproject_id

Nettoyer la stratégie de pare-feu hiérarchique

Dans Cloud Shell, procédez comme suit :

gcloud compute firewall-policies associations delete my-folder1-fw-policy \
   --firewall-policy=my-folder1-fw-policy \
   --organization=$org_id
gcloud compute firewall-policies rules delete 100 \
  --organization=$org_id \
  --firewall-policy=my-folder1-fw-policy
gcloud compute firewall-policies delete my-folder1-fw-policy \
  --organization=$org_id

Nettoyer les tags au niveau de l'organisation

Dans Cloud Shell, procédez comme suit :

gcloud resource-manager tags values delete $http_tags_http_server_id
gcloud resource-manager tags values delete $http_tags_http_client_id
gcloud resource-manager tags keys delete $http_tags_id

Nettoyer le projet hôte

Dans Cloud Shell, procédez comme suit :

gcloud compute shared-vpc associated-projects remove $serviceproject_id --host-project=$hostproject_id 
gcloud compute shared-vpc disable $hostproject_id
gcloud projects delete $hostproject_id

Nettoyer le projet de service

Dans Cloud Shell, procédez comme suit :

gcloud projects delete $serviceproject_id

Nettoyer les dossiers

Dans Cloud Shell, procédez comme suit :

gcloud resource-manager folders delete $folder1_id
gcloud resource-manager folders delete $folder2_id

10. Félicitations

Vous avez réussi à tester la stratégie de pare-feu hiérarchique avec des tags gérés par IAM.

Stratégie de pare-feu hiérarchique avec des tags gérés par IAM Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

1. Introduction

Cloud Next Generation Firewall (NGFW)

Stratégies de pare-feu réseau

Tags gérés par IAM

2. Points abordés

3. Architecture globale de l'atelier

4. Étapes de préparation

Rôles IAM requis pour effectuer l'atelier

Créer des dossiers et des projets

Créer des tags gérés par IAM

Activer les API dans le projet hôte et le projet de service

Créer un VPC dans le projet hôte

Créer des sous-réseaux dans le projet hôte

Créer un routeur Cloud Router et Cloud NAT dans le projet hôte

Créer des instances dans le projet de service

5. Créer une stratégie de pare-feu de réseau au niveau mondial dans le projet hôte

6. Tester l'accès de la VM http-client à la VM http-server

7. Créer une stratégie de pare-feu hiérarchique et des règles de pare-feu

Créer une stratégie de pare-feu hiérarchique

Créer une règle de pare-feu dans la stratégie de pare-feu hiérarchique

Associer une stratégie de pare-feu hiérarchique à folder1

8. Tester l'accès de la VM http-client à la VM http-server

9. Effectuer un nettoyage

Nettoyer les VM dans le projet de service

Nettoyer la stratégie de pare-feu hiérarchique

Nettoyer les tags au niveau de l'organisation

Nettoyer le projet hôte

Nettoyer le projet de service

Nettoyer les dossiers

10. Félicitations

Stratégie de pare-feu hiérarchique avec des tags gérés par IAM