Appliquer des stratégies de pare-feu de manière sélective dans GKE

Cette page vous explique comment appliquer de manière sélective les stratégies de pare-feu réseau Cloud Next Generation Firewall (NGFW) dans Google Kubernetes Engine (GKE), à l'aide de tags. Pour apprendre à utiliser des tags dans GKE à d'autres fins, telles que la gestion de la facturation ou les stratégies IAM conditionnelles, consultez la page Gérer les ressources GKE à l'aide de tags.

À propos des tags

Les tags sont des paires clé/valeur qui vous permettent d'annoter et de gérer vos ressources Google Cloud au niveau de l'organisation ou du projet. Vous pouvez utiliser des tags pour organiser vos ressources et appliquer des stratégies de manière conditionnelle, telles que des pare-feu ou des stratégies IAM. Vous pouvez utiliser le contrôle des accès IAM pour déterminer qui peut associer, créer, mettre à jour ou supprimer des tags.

Pour en savoir plus sur les tags, consultez la page Présentation des tags dans la documentation Resource Manager.

Utiliser des tags pour appliquer des stratégies de pare-feu de réseau

Vous pouvez utiliser des tags pour appliquer des stratégies de pare-feu réseau globales ou régionales à vos nœuds GKE de manière conditionnelle. Vous devez désigner l'objectif GCE_FIREWALL pour les tags que vous souhaitez utiliser avec les stratégies de pare-feu réseau. Lorsque vous appliquez des tags d'objectif de pare-feu aux clusters ou aux pools de nœuds GKE, GKE les associe automatiquement aux machines virtuelles (VM) Compute Engine correspondantes.

Les tags pour les stratégies de pare-feu réseau remplacent la nécessité d'utiliser des tags réseau, qui sont des métadonnées que tout le monde peut associer aux VM Compute Engine sous-jacentes pour l'application de la stratégie de pare-feu du cloud privé virtuel et qui ne sont pas compatibles avec le contrôle des accès IAM. Si vous utilisez actuellement des tags réseau avec des stratégies de pare-feu VPC, nous vous recommandons de migrer vers les stratégies de pare-feu réseau et d'utiliser des tags de pare-feu sécurisés. Pour une comparaison détaillée, consultez la section Comparer les tags réseau avec des tags dans ce document.

Tags pour le workflow des stratégies de pare-feu réseau

Pour utiliser des tags avec des stratégies de pare-feu réseau dans GKE, procédez comme suit :

  1. Créez un tag :

    1. Définissez une clé de tag au niveau de l'organisation ou du projet, par exemple env.
    2. Définissez les valeurs de tag possibles pour la clé, telles que dev, staging et prod.

    3. Désignez le tag pour l'utilisation de la stratégie de pare-feu réseau.

  2. Accordez aux utilisateurs l'accès pour interagir avec le tag de pare-feu.

  3. Appliquez des paires clé/valeur de tags à des clusters ou à des pools de nœuds GKE spécifiques. GKE associe automatiquement les tags aux VM Compute Engine sous-jacentes pour l'application de la stratégie de pare-feu.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Activez l'API Google Kubernetes Engine.
    • Activer l'API Google Kubernetes Engine
  • Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.

Conditions requises et limites

  • Les tags pour les stratégies de pare-feu réseau sont compatibles avec GKE version 1.28 et ultérieure. Si vous utilisez une version de GKE antérieure à la version 1.28, utilisez plutôt des tags réseau avec des stratégies de pare-feu VPC.
  • Le cluster GKE doit avoir été créé à l'aide de GKE version 1.28 ou ultérieure. La mise à niveau d'un cluster depuis une version antérieure à la version 1.28 vers la version 1.28 ou ultérieure n'active pas les tags.
  • Le cluster GKE et le tag doivent être associés au même réseau VPC.
  • Dans les clusters standards, chaque pool de nœuds peut comporter jusqu'à cinq tags de pare-feu associés.
  • Les clusters Autopilot acceptent jusqu'à cinq tags de pare-feu.
  • GKE rejette les clés de tag qui utilisent le préfixe gke-managed.
  • Vous devez créer les paires clé/valeur des tags avant de pouvoir les associer à des clusters ou à des pools de nœuds.

Rôles et autorisations IAM

Pour obtenir les autorisations nécessaires pour utiliser des tags pour les stratégies de pare-feu dans GKE, demandez à votre administrateur de vous accorder les rôles IAM suivants :

  • Pour accorder les autorisations requises pour les tags aux utilisateurs et aux agents de service GKE :
  • Pour créer et administrer des tags : Administrateur de tags (roles/resourcemanager.tagAdmin) sur l'organisation ou le projet
  • Pour associer des tags à des ressources : Utilisateur de tags (roles/resourcemanager.tagUser) sur le projet

Pour en savoir plus sur l'attribution de rôles, consultez la section Gérer les accès.

Vous pouvez également obtenir les autorisations requises via des rôles personnalisés ou d'autres rôles prédéfinis.

Créer des tags

Les tags doivent exister pour que vous puissiez les associer à des clusters ou à des nœuds. Pour créer un tag, consultez la page Utiliser des tags pour les pare-feu dans la documentation Cloud NGFW.

Par exemple, pour créer un tag de pare-feu à l'échelle du projet, exécutez les commandes suivantes :

  1. Créez la clé de tag :

    gcloud resource-manager tags keys create TAG_KEY \
    --parent=projects/PROJECT_ID \
    --purpose=GCE_FIREWALL \
    --purpose-data=network=PROJECT_ID/NETWORK_NAME

    Remplacez les éléments suivants :

    • TAG_KEY : nom de la clé de tag, par exemple env
    • PROJECT_ID : ID de votre projet Google Cloud
    • NETWORK_NAME : nom du réseau VPC que vous utiliserez avec le tag

  2. Obtenez l'ID de la clé de tag :

    gcloud resource-manager tags keys describe PROJECT_ID/TAG_KEY \
    --format="value(name)"

    Le résultat est tagKeys/KEY_ID, où KEY_ID est un ID numérique de la clé. Notez cet ID pour plus tard.

  3. Ajoutez une valeur de tag à la clé de tag :

    gcloud resource-manager tags values create TAG_VALUE \
    --parent=tagKeys/KEY_ID

    Remplacez TAG_VALUE par le nom d'une valeur autorisée pour cette clé de tag, telle que dev.

Syntaxe des tags dans les commandes de gcloud CLI

Lorsque vous faites référence à des tags à l'aide de gcloud CLI, vous devez formater les paires clé/valeur au moyen de l'une des syntaxes suivantes :

Syntaxe des tags 
tagKeys/KEY_ID=tagValues/VALUE_ID

Remplacez les éléments suivants :

  • KEY_ID : ID de clé numérique
  • VALUE_ID : ID de la valeur numérique

Par exemple, tagKeys/123456789=tagValues/987654321.

 
ORGANIZATION_ID/TAG_KEY=TAG_VALUE

Remplacez les éléments suivants :

  • ORGANIZATION_ID : ID numérique de votre organisation Google Cloud
  • TAG_KEY : nom de la clé de tag que vous avez créée
  • TAG_VALUE : nom de la valeur de tag que vous avez créée

Par exemple, 12345678901/env=dev.

 
PROJECT_ID/TAG_KEY=TAG_VALUE

Remplacez les éléments suivants :

  • PROJECT_ID : ID de votre projet Google Cloud
  • TAG_KEY : nom de la clé de tag que vous avez créée
  • TAG_VALUE : nom de la valeur de tag que vous avez créée

Par exemple, example-project/env=dev.

 
PROJECT_NUMBER/TAG_KEY=TAG_VALUE

Remplacez les éléments suivants :

  • PROJECT_ID : identifiant numérique de votre projet Google Cloud
  • TAG_KEY : nom de la clé de tag que vous avez créée
  • TAG_VALUE : nom de la valeur de tag que vous avez créée

Par exemple, 11223344556/env=dev.

Tags cibles avec stratégies de pare-feu

Après avoir créé des tags, vous pouvez faire référence à des paires clé/valeur spécifiques dans les règles de stratégie de pare-feu. Pour obtenir des instructions, consultez la section Utiliser des tags pour les pare-feu.

Accorder des autorisations IAM aux agents de service

Pour que GKE associe automatiquement des tags aux nouveaux nœuds lors des événements de scaling à la hausse, vous devez attribuer les rôles IAM correspondants aux comptes de service gérés par Google Cloud, également appelés agents de service.

  1. Attribuez le rôle Utilisateur des tags (roles/resourcemanager.tagUser) à l'agent de service Kubernetes Engine :

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
    --role=roles/resourcemanager.tagUser \
    --condition=None

    Remplacez PROJECT_NUMBER par le numéro du projet Google Cloud du cluster. Pour trouver le numéro de projet, exécutez la commande suivante :

    gcloud projects describe PROJECT_ID --format="value(projectNumber)"

  2. Attribuez le rôle Administrator d'éléments TagHold (roles/resourcemanager.tagHoldAdmin) à l'agent de service Kubernetes Engine pour la paire clé-valeur de tag :

    gcloud resource-manager tags values add-iam-policy-binding PROJECT_ID/TAG_KEY/TAG_VALUE \
    --member=serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
    --role=roles/resourcemanager.tagHoldAdmin

    Ce rôle permet à l'agent de service d'empêcher la suppression des tags si la paire clé/valeur est toujours utilisée dans GKE.

  3. Attribuez le rôle Utilisateur de tags (roles/resourcemanager.tagUser) à l'agent de service des API Google :

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:PROJECT_NUMBER@cloudservices.gserviceaccount.com \
    --role=roles/resourcemanager.tagUser \
    --condition=None

Accorder des rôles IAM supplémentaires pour les tags en dehors du projet

Pour utiliser des tags appartenant à une organisation ou à un projet différent du projet de cluster, procédez comme suit :

  1. Attribuez le rôle Utilisateur de tags (roles/resourcemanager.tagUser) à l'agent de service Kubernetes Engine pour accéder aux tags dans la ressource parente :

    gcloud resource-manager tags keys add-iam-policy-binding PARENT_RESOURCE/TAG_KEY \
    --member=serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
    --role=roles/resourcemanager.tagUser \
    --condition=None

    Remplacez les éléments suivants :

    • PARENT_RESOURCE : ID de projet ou d'organisation de la ressource propriétaire de ce tag.
    • PROJECT_NUMBER : numéro du projet de cluster

  2. Attribuez le rôle Utilisateur de tags (roles/resourcemanager.tagUser) pour l'accès de l'agent de service des API Google pour les tags de la ressource parente :

    gcloud resource-manager tags keys add-iam-policy-binding PARENT_RESOURCE/TAG_KEY \
    --member=serviceAccount:PROJECT_NUMBER@cloudservices.gserviceaccount.com \
    --role=roles/resourcemanager.tagUser \
    --condition=None

  3. Attribuez le rôle Administrateur d'éléments Tag Hold (roles/resourcemanager.tagHoldAdmin) à l'agent de service Kubernetes Engine pour la paire clé/valeur de tag :

    gcloud resource-manager tags values add-iam-policy-binding PARENT_RESOURCE/TAG_KEY/TAG_VALUE \
    --member=serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
    --role=roles/resourcemanager.tagHoldAdmin

Associer des tags de pare-feu à des clusters Autopilot

Vous associez des tags de pare-feu aux clusters Autopilot au niveau du cluster. GKE applique automatiquement ces tags au niveau du cluster à chaque nœud.

Associer des tags lorsque vous créez un cluster Autopilot

Exécutez la commande suivante :

gcloud beta container clusters create-auto CLUSTER_NAME \
    --location=LOCATION \
    --autoprovisioning-resource-manager-tags=TAG1,TAG2,...

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du nouveau cluster
  • LOCATION : région Compute Engine du cluster.
  • TAG1,TAG2,... : ensemble de paires clé/valeur séparées par une virgule à associer. Chaque paire clé/valeur doit utiliser une syntaxe compatible, comme décrit dans la section Syntaxe des tags dans les commandes. Exemple : example-project/env=dev,1234567901/team=sre.

Associer des tags à des clusters Autopilot existants

Exécutez la commande suivante :

gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --autoprovisioning-resource-manager-tags=TAG1,TAG2,...

Lorsque vous mettez à jour les tags d'un cluster, GKE écrase les tags existants sur tous les nœuds.

Associer des tags de pare-feu à des clusters et des pools de nœuds standards

La méthode que vous utilisez pour associer des tags varie selon que vous souhaitez que les autres pools de nœuds du cluster héritent des tags, comme suit :

Tags de pare-feu de cluster standards
--autoprovisioning-resource-manager-tags

Paramètre au niveau du cluster

GKE applique les tags à tous les nouveaux pools de nœuds provisionnés automatiquement dans le cluster. Si vous utilisez cette option sur un cluster existant, les pools de nœuds existants conservent tous les tags appliqués avant la mise à jour.
--resource-manager-tags

Paramètre au niveau du pool de nœuds

GKE applique les tags au pool de nœuds spécifié. Si vous utilisez cette option lors de la création du cluster, GKE applique les tags au pool de nœuds par défaut créé par GKE. Si vous utilisez cette option sur un pool de nœuds provisionné automatiquement, GKE écrase tous les tags existants du pool de nœuds.

Associer des tags de pare-feu à des clusters standards

Vous pouvez associer des tags à des clusters standards nouveaux ou existants. Lorsque vous associez des tags à l'ensemble d'un cluster, GKE considère qu'ils sont définis au niveau du cluster.

Associer des tags à un nouveau cluster standard avec provisionnement automatique des nœuds

GKE utilise par défaut des tags au niveau du cluster pour les nouveaux nœuds provisionnés automatiquement. Le pool de nœuds par défaut créé par GKE dans le cluster n'est pas provisionné automatiquement et n'obtient pas ces tags.

gcloud beta container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --autoprovisioning-resource-manager-tags=TAG1,TAG2,... \
    --enable-autoprovisioning \
    --max-cpu=MAX_CPU \
    --max-memory=MAX_MEMORY

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du nouveau cluster
  • LOCATION : région ou zone Compute Engine du cluster
  • TAG1,TAG2,... : ensemble de paires clé/valeur séparées par une virgule à associer. Chaque paire clé/valeur doit utiliser une syntaxe compatible, comme décrit dans la section Syntaxe des tags dans les commandes. Exemple : example-project/env=dev,1234567901/team=sre.
  • MAX_CPU : nombre maximal de cœurs pour le cluster
  • MAX_MEMORY : capacité de mémoire maximale du cluster en gigaoctets

Associer des tags lorsque vous activez le provisionnement automatique des nœuds sur un cluster existant

GKE n'applique ces tags qu'aux nouveaux pools de nœuds provisionnés automatiquement. Les pools de nœuds existants conservent tous les tags qu'ils avaient avant la mise à jour.

  1. Associez des tags au cluster :

    gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --autoprovisioning-resource-manager-tags=TAG1,TAG2,...

  2. Activez le provisionnement automatique des nœuds sur le cluster :

    gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --enable-autoprovisioning \
    --max-cpu=MAX_CPU \
    --max-memory=MAX_MEMORY

Associer des tags de pare-feu à des pools de nœuds

Vous pouvez associer des tags à des pools de nœuds nouveaux ou existants, qu'ils utilisent ou non le provisionnement automatique des nœuds. GKE considère ces tags comme un paramètre au niveau du pool de nœuds.

Associer des tags au pool de nœuds par défaut

GKE associe les tags que vous spécifiez à l'aide de l'option --resource-manager-tags lorsque vous créez un cluster au pool de nœuds par défaut créé par GKE dans le cluster.

gcloud beta container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --resource-manager-tags=TAG1,TAG2,...

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du nouveau cluster
  • LOCATION : région ou zone Compute Engine du cluster
  • TAG1,TAG2,... : ensemble de paires clé/valeur séparées par une virgule à associer. Chaque paire clé/valeur doit utiliser une syntaxe compatible, comme décrit dans la section Syntaxe des tags dans les commandes. Exemple : example-project/env=dev,1234567901/team=sre.

Associer des tags à un nouveau pool de nœuds

Lorsque vous utilisez l'option --resource-manager-tags lors de la création du pool de nœuds, GKE associe les tags que vous spécifiez à ce pool.

gcloud beta container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --resource-manager-tags=TAG1,TAG2,...

Remplacez les éléments suivants :

  • NODE_POOL_NAME : nom du nouveau pool de nœuds
  • CLUSTER_NAME : nom du cluster
  • LOCATION : région ou zone Compute Engine du cluster
  • TAG1,TAG2,... : ensemble de paires clé/valeur séparées par une virgule à associer Chaque paire clé/valeur doit utiliser une syntaxe compatible, comme décrit dans la section Syntaxe des tags dans les commandes. Exemple : example-project/env=dev,1234567901/team=sre.

Associer des tags à un pool de nœuds existant

Lorsque vous mettez à jour les tags d'un pool de nœuds existant à l'aide de l'option --resource-manager-tags, GKE écrase tous les tags existants sur ce pool de nœuds. Vous pouvez utiliser cette commande pour mettre à jour les tags sur des pools de nœuds provisionnés automatiquement.

gcloud beta container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --resource-manager-tags=TAG1,TAG2,...

Remplacez NODE_POOL_NAME par le nom du pool de nœuds à mettre à jour.

Activer/Désactiver les paramètres de provisionnement automatique dans les clusters et les pools de nœuds existants

Lorsque vous mettez à jour des tags au niveau du cluster, GKE applique ces nouveaux tags à tous les nouveaux pools de nœuds du cluster et conserve les tags associés aux pools de nœuds existants.

Lorsque vous mettez à jour des pools de nœuds existants pour activer ou désactiver le provisionnement automatique des nœuds, tenez compte des implications suivantes pour les tags :

  • Lorsque vous activez ou désactivez le provisionnement automatique des nœuds, le pool de nœuds conserve tous les tags existants. GKE ne remplace pas ces tags par des tags au niveau du cluster, même lors de la recréation des nœuds.
  • Si vous mettez à jour manuellement les tags de pools de nœuds spécifiques, GKE écrase les tags existants en fonction des tags spécifiés pour ce pool de nœuds.

Vérifier les tags de pare-feu sur le cluster

  • Répertoriez les tags sur les clusters Autopilot :

    gcloud beta container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format="value(nodePoolAutoConfig.resourceManagerTags)"

  • Répertoriez les tags sur des pools de nœuds spécifiques :

    gcloud beta container node-pools describe NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --location=LOCATION \
  --format="value(config.resourceManagerTags)"

Dissocier des tags de pare-feu des clusters et des pools de nœuds

Pour supprimer les tags de pare-feu des clusters et des pools de nœuds, mettez à jour la ressource avec une valeur vide pour les tags.

Dissocier des tags des clusters Autopilot

Exécutez la commande suivante :

gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --autoprovisioning-resource-manager-tags=

Dissocier des tags d'un pool de nœuds

  1. Dissociez les tags de provisionnement automatique des nœuds au niveau du cluster :

    gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --autoprovisioning-resource-manager-tags=

    GKE n'associe pas de tags aux nouveaux pools de nœuds provisionnés automatiquement.

  2. Dissociez les tags du pool de nœuds :

    gcloud beta container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --resource-manager-tags=

    GKE supprime les tags existants de ce pool de nœuds.

Supprimer des clés et des valeurs de tags

Pour supprimer une clé ou une valeur de tag, assurez-vous que le tag est dissocié de toutes les ressources. Consultez ensuite la section Supprimer des tags dans la documentation de Resource Manager.

Comparer les tags réseau avec des tags

L'utilisation de tags pour l'application des stratégies de pare-feu présente des avantages significatifs en termes de sécurité et de facilité d'utilisation par rapport aux tags réseau. De même, les stratégies de pare-feu réseau améliorent les capacités des stratégies de pare-feu VPC en facilitant l'application des stratégies de pare-feu sur l'ensemble des organisations, des dossiers, des projets ou des réseaux.

L'utilisation de tags avec des stratégies de pare-feu réseau est un moyen plus sécurisé et évolutif de gérer l'accès à vos environnements GKE dans toute votre organisation. Vous pouvez utiliser des tags réseau dans le même cluster que les tags, mais vous ne pouvez pas utiliser de tags réseau pour appliquer des stratégies de pare-feu réseau.

Pour une comparaison détaillée entre les tags et les tags réseau, consultez la section Comparaison des tags et des tags réseau dans la documentation Cloud NGFW.

Différences fonctionnelles dans les pools de nœuds provisionnés automatiquement

Dans les clusters Autopilot et dans les pools de nœuds standards qui n'utilisent pas le provisionnement automatique des nœuds, les tags réseau et les tags présentent un comportement similaire. Le tableau suivant montre les différences fonctionnelles entre les tags réseau et les tags dans les pools de nœuds provisionnés automatiquement dans des clusters standards :

Action Comportement des tags réseau Comportement des tags
GKE provisionne automatiquement un pool de nœuds. GKE applique les tags réseau au niveau du cluster. GKE applique les tags au niveau du cluster.
Vous mettez à jour les tags ou les tags réseau sur un pool de nœuds provisionné automatiquement.
  • Si des tags réseau au niveau du cluster existent, l'opération de mise à jour échoue.
  • Si les tags réseau au niveau du cluster n'existent pas, GKE écrase les tags réseau existants pour le pool de nœuds.
 GKE écrase les tags existants pour le pool de nœuds, que les tags au niveau du cluster existent ou non.
Vous mettez à jour les tags ou les tags réseau pour l'ensemble du cluster. GKE écrase les tags réseau des pools de nœuds provisionnés automatiquement nouveaux et existants dans le cluster. GKE applique les nouveaux tags au niveau du cluster aux nouveaux pools de nœuds provisionnés automatiquement. Les pools de nœuds provisionnés automatiquement existants conservent les tags qu'ils avaient avant la mise à jour.

Étapes suivantes