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. Les tags offrent un contrôle plus précis pour organiser votre hiérarchie de ressources par rapport à la hiérarchie de ressources Google Cloud par défaut. Les tags permettent également d'appliquer des règles de manière conditionnelle.

Cette page s'adresse aux spécialistes de la sécurité qui souhaitent contrôler précisément les règles de pare-feu dans GKE. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud , consultez Rôles utilisateur et tâches courantes de GKE.

Avant de lire cette page, assurez-vous de maîtriser les concepts suivants :

À propos des tags

Les tags sont des paires clé/valeur qui vous permettent d'annoter et de gérer vos ressourcesGoogle 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 des tags réseau avec des règles 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, ou utilisez-les dans des ComputeClasses personnalisées pour les appliquer à des nœuds pour des charges de travail 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 la gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la commande gcloud components update. Il est possible que les versions antérieures de la gcloud CLI ne permettent pas d'exécuter les commandes de ce document.

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.
  • Les clusters et les pools de nœuds GKE ne sont pas compatibles avec les tags créés avec l'indicateur --purpose-data=organization=auto. Pour les charges de travail GKE, nous vous recommandons de créer des tags limités à votre réseau VPC à l'aide de l'indicateur --purpose-data=network. Pour en savoir plus, consultez Créer des 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.
  • Les classes de calcul personnalisées acceptent jusqu'à cinq tags.
  • 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 en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

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.

Utiliser la syntaxe correcte des tags dans les commandes 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 de projet Google Clouddu 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 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 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 dans un cluster existant, GKE n'applique pas les tags aux pools de nœuds existants du cluster. Les pools de nœuds existants conservent tous les tags qui leur ont été appliqués avant la mise à jour. Pour mettre à jour les tags des pools de nœuds existants, utilisez l'option --resource-manager-tags.
--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 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 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 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 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 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 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.

Appliquer des tags aux charges de travail avec des ComputeClasses personnalisées

Vous pouvez appliquer des tags de pare-feu à des pools de nœuds spécifiques dans les clusters Autopilot et dans les clusters standards qui utilisent le provisionnement automatique des nœuds (NAP) à l'aide de ComputeClasses personnalisées (CCC). Une classe de calcul personnalisée est une ressource qui vous permet de définir une configuration pour un groupe de nœuds, y compris les tags Resource Manager à appliquer aux nœuds.

Lorsque vous déployez une charge de travail qui demande un nœud avec un libellé de classe de calcul personnalisée spécifique, NAP vérifie d'abord s'il existe déjà un pool de nœuds qui répond à toutes les exigences de la classe de calcul personnalisée, y compris les tags Resource Manager spécifiés.

Si aucun pool de nœuds correspondant n'existe, NAP crée un pool de nœuds pour la charge de travail avec la configuration spécifiée et associe les tags aux VM Compute Engine sous-jacentes. Cette création automatique de pools de nœuds garantit que les charges de travail s'exécutent sur des nœuds avec les tags de pare-feu appropriés pour l'application des règles.

Créer une ComputeClass personnalisée à l'aide de tags

  1. Pour créer un ComputeClass avec des tags, enregistrez le fichier manifeste suivant sous le nom my-compute-class.yaml. Dans le champ resourceManagerTags, spécifiez les clés et les valeurs des tags à associer aux pools de nœuds créés à l'aide de cette classe.

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: COMPUTE_CLASS_NAME
spec:
    nodePoolConfig:
      resourceManagerTags:
        - key: "PROJECT_ID/TAG_KEY_1"
          value: "TAG_VALUE_1"
        - key: "ORGANIZATION_ID/TAG_KEY_2"
          value: "TAG_VALUE_2"
        - key: "tagKeys/KEY_ID"
          value: "tagValues/VALUE_ID"

    Remplacez les éléments suivants :

    • COMPUTE_CLASS_NAME : nom de votre classe de calcul personnalisée, par exemple my-custom-class.
    • PROJECT_ID : ID de votre projet Google Cloud .
    • TAG_KEY_1 : nom de la première clé de tag.
    • TAG_VALUE_1 : nom de la première valeur de tag.
    • ORGANIZATION_ID : ID numérique de votre organisation Google Cloud .
    • TAG_KEY_2 : nom de la deuxième clé de tag.
    • TAG_VALUE_2 : nom de la deuxième valeur de tag.
    • KEY_ID : ID numérique d'une clé de tag.
    • VALUE_ID : ID numérique d'une valeur de tag.

  2. Appliquez le fichier manifeste :

    kubectl apply -f my-compute-class.yaml

Si vous spécifiez un tag non valide ou si les agents de service GKE ne disposent pas des autorisations IAM requises pour le tag, GKE ne provisionne pas de pool de nœuds pour votre charge de travail, et celle-ci reste à l'état Pending. Pour en savoir plus sur l'erreur, consultez le champ Status de votre ressource ComputeClass.

Pour vérifier l'état, exécutez la commande suivante :

kubectl get cc COMPUTE_CLASS_NAME -o jsonpath='{.status}' | jq .

Remplacez COMPUTE_CLASS_NAME par le nom de votre classe de calcul personnalisée.

Cibler la classe de calcul personnalisée dans votre charge de travail

  1. Pour cibler la ComputeClass que vous avez créée, enregistrez le fichier manifeste suivant sous le nom pod-with-ccc.yaml. Ce fichier manifeste utilise le champ nodeSelector pour cibler la classe de calcul.

    apiVersion: v1
kind: Pod
metadata:
  name: nginx-server
spec:
  nodeSelector:
    cloud.google.com/compute-class: "COMPUTE_CLASS_NAME"
  containers:
    - name: nginx
      image: nginx:latest

    Remplacez COMPUTE_CLASS_NAME par le nom de votre classe de calcul personnalisée, par exemple my-custom-class.

  2. Appliquez le fichier manifeste :

    kubectl apply -f pod-with-ccc.yaml

Lorsque vous planifiez une charge de travail ciblant une classe de calcul personnalisée, GKE applique automatiquement un rejet aux nœuds créés pour cette classe et ajoute une tolérance correspondante aux pods de votre charge de travail. Ainsi, seuls les pods demandant explicitement la classe sont planifiés sur ces nœuds.

Autoriser les charges de travail avec une règle d'admission de validation

Pour vous assurer que seules les charges de travail autorisées peuvent être planifiées sur des pools de nœuds avec des tags, nous vous recommandons d'utiliser une règle d'admission de validation. Cette règle, une fonctionnalité Kubernetes intégrée, intercepte les requêtes de création ou de mise à jour des pods avant leur persistance. Cette interception empêche les charges de travail non autorisées de s'exécuter sur les nœuds tagués.

La règle suivante refuse les demandes de création de pods si le pod contient une tolérance pour l'une des contaminations de classe de calcul listées et et ne se trouve pas dans un espace de noms autorisé.

  1. Enregistrez le manifeste suivant sous le nom restrict-toleration.yaml :

    # Copyright 2025 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: restrict-toleration
spec:
  failurePolicy: Fail
  paramKind:
    apiVersion: v1
    kind: ConfigMap
  matchConstraints:
    # GKE will mutate any pod specifying a CC label in a nodeSelector
    # or in a nodeAffinity with a toleration for the CC node label.
    # Mutation hooks will always mutate the K8s object before validating
    # the admission request.  
    # Pods created by Jobs, CronJobs, Deployments, etc. will also be validated.
    # See https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#admission-control-phases for details
    resourceRules:
    - apiGroups:   [""]
      apiVersions: ["v1"]
      operations:  ["CREATE", "UPDATE"]
      resources:   ["pods"]
  matchConditions:
    - name: 'match-tolerations'
      # Validate only if compute class toleration exists
      # and the CC label tolerated is listed in the configmap.
      expression: > 
        object.spec.tolerations.exists(t, has(t.key) &&
        t.key == 'cloud.google.com/compute-class' &&
        params.data.computeClasses.split('\\n').exists(cc, cc == t.value))
  validations:
    # ConfigMap with permitted namespace list referenced via `params`.
    - expression: "params.data.namespaces.split('\\n').exists(ns, ns == object.metadata.namespace)"
      messageExpression: "'Compute class toleration not permitted on workloads in namespace ' + object.metadata.namespace"

---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: restrict-toleration-binding
spec:
  policyName: restrict-toleration
  validationActions: ["Deny"]
  paramRef:
    name: allowed-ccc-namespaces
    namespace: default
    parameterNotFoundAction: Deny
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: allowed-ccc-namespaces
  namespace: default
data:
  # Replace example namespaces in line-separated list below.
  namespaces: |
    foo
    bar
    baz
  # ComputeClass names to monitor with this validation policy.
  # The 'autopilot' and 'autopilot-spot' CCs are present on
  # all NAP Standard and Autopilot clusters.
  computeClasses: |
    MY_COMPUTE_CLASS
    autopilot
    autopilot-spot

  2. Appliquez le fichier manifeste :

    kubectl apply -f restrict-toleration.yaml

Ajustez les règles de validation des admissions pour répondre aux besoins de sécurité spécifiques de votre organisation.

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

  • Répertoriez les tags sur les clusters Autopilot :

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

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster.
    • LOCATION : région ou zone Compute Engine du cluster.

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

    Cette commande permet également de vérifier les tags sur les pools de nœuds provisionnés automatiquement par une classe de calcul personnalisée.

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

    Remplacez les éléments suivants :

    • NODE_POOL_NAME : nom du pool de nœuds.
    • CLUSTER_NAME : nom du cluster.
    • LOCATION : région ou zone Compute Engine du cluster.

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 container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --autoprovisioning-resource-manager-tags=

Dissocier des tags d'un pool de nœuds

  1. Dissociez les tags autoprovisioning des nœuds au niveau du cluster :

    gcloud 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 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