Utiliser Workload Identity

Autopilot Standard

---

Ce document explique comment activer et configurer Workload Identity sur vos clusters Google Kubernetes Engine (GKE). Workload Identity permet aux charges de travail de vos clusters GKE d'emprunter l'identité des comptes de service Identity and Access Management (IAM) pour accéder aux services Google Cloud. Pour en savoir plus sur le fonctionnement de Workload Identity et sur les limites, consultez la page Workload Identity.

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.
  Remarque : Pour les installations de gcloud CLI existantes, veillez à définir les propriétés compute/region et compute/zone. En définissant des emplacements par défaut, vous pouvez éviter les erreurs gcloud CLI telles que celle-ci : One of [--zone, --region] must be supplied: Please specify location.

• Assurez-vous d'avoir activé l'API d'identifiants de compte de service IAM.

  Activer l'API des identifiants IAM

• Assurez-vous de disposer des rôles IAM suivants :

  • roles/container.admin
  • roles/iam.serviceAccountAdmin

• Assurez-vous de bien comprendre les limitations relatives à Workload Identity.

Activer Workload Identity

Vous pouvez activer Workload Identity sur des clusters et des pools de nœuds à l'aide de Google Cloud CLI ou de la console Google Cloud. Workload Identity doit être activé au niveau du cluster pour que vous puissiez l'activer sur des pools de nœuds.

Les clusters Autopilot activent Workload Identity par défaut. Pour configurer des pods Autopilot pour utiliser Workload Identity, passez à la section Configurer des applications pour utiliser Workload Identity.

Créer un cluster

Vous pouvez activer Workload Identity sur un nouveau cluster Standard à l'aide de gcloud CLI ou de la console Google Cloud.

gcloud

1. Dans la console Google Cloud, activez Cloud Shell.

   Activer Cloud Shell

   En bas de la fenêtre de la console Google Cloud, une session Cloud Shell démarre et affiche une invite de ligne de commande. Cloud Shell est un environnement shell dans lequel Google Cloud CLI est déjà installé, et dans lequel des valeurs sont déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.

2. Pour activer Workload Identity sur un nouveau cluster, exécutez la commande suivante :

   gcloud container clusters create CLUSTER_NAME \
       --region=COMPUTE_REGION \
       --workload-pool=PROJECT_ID.svc.id.goog
   

   Remplacez les éléments suivants :

   • CLUSTER_NAME : nom de votre nouveau cluster
   • COMPUTE_REGION : région Compute Engine du cluster. Pour les clusters zonaux, utilisez --zone=COMPUTE_ZONE.
   • PROJECT_ID : ID de votre projet Google Cloud.

Console

Pour activer Workload Identity sur un nouveau cluster, procédez comme suit :

1. Accédez à la page Google Kubernetes Engine dans Google Cloud Console.

   Accéder à Google Kubernetes Engine

2. Cliquez sur Créer.

3. Dans la boîte de dialogue Créer un cluster, cliquez sur Configurer pour GKE Standard.

4. Dans le menu de navigation, dans la section Cluster, cliquez sur Sécurité.

5. Cochez la case Activer Workload Identity.

6. Poursuivez la configuration du cluster, puis cliquez sur Créer.

Mettre à jour un cluster existant

Vous pouvez activer Workload Identity sur un cluster Standard existant à l'aide de gcloud CLI ou de la console Google Cloud. Les pools de nœuds existants ne sont pas affectés, mais tous les nouveaux pools de nœuds du cluster utilisent Workload Identity.

gcloud

1. Dans la console Google Cloud, activez Cloud Shell.

   Activer Cloud Shell

   En bas de la fenêtre de la console Google Cloud, une session Cloud Shell démarre et affiche une invite de ligne de commande. Cloud Shell est un environnement shell dans lequel Google Cloud CLI est déjà installé, et dans lequel des valeurs sont déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.

2. Pour activer Workload Identity sur un cluster existant, exécutez la commande suivante :

   gcloud container clusters update CLUSTER_NAME \
       --region=COMPUTE_REGION \
       --workload-pool=PROJECT_ID.svc.id.goog
   

   Remplacez les éléments suivants :

   • CLUSTER_NAME : nom de votre cluster existant.
   • COMPUTE_REGION : région Compute Engine du cluster. Pour les clusters zonaux, utilisez --zone=COMPUTE_ZONE.
   • PROJECT_ID : ID de votre projet Google Cloud.

Console

Pour activer Workload Identity sur un cluster existant, procédez comme suit :

1. Accédez à la page Google Kubernetes Engine dans la console Google Cloud.

   Accéder à Google Kubernetes Engine

2. Dans la liste des clusters, cliquez sur le nom du cluster que vous souhaitez modifier.

3. Dans la section Sécurité de la page "Détails du cluster", cliquez sur  Modifier Workload Identity.

4. Dans la boîte de dialogue Modifier Workload Identity, cochez la case Activer Workload Identity.

5. Cliquez sur Enregistrer les modifications.

Migrer des charges de travail existantes vers Workload Identity

Après avoir activé Workload Identity sur un cluster existant, vous pouvez migrer vos charges de travail en cours d'exécution pour qu'elles utilisent Workload Identity. Choisissez la stratégie de migration idéale pour votre environnement. Vous pouvez créer des pools de nœuds lorsque Workload Identity est activé, ou mettre à jour des pools de nœuds existants pour activer Workload Identity.

Remarque : Vous ne pouvez activer Workload Identity sur un pool de nœuds que si Workload Identity est activé sur le cluster.

Il est recommandé de créer des pools de nœuds si vous devez également modifier vos applications pour qu'elles soient compatibles avec Workload Identity.

Créer un pool de nœuds

Tous les nouveaux pools de nœuds que vous créez utilisent Workload Identity par défaut si Workload Identity est activé sur ce cluster. Pour créer un pool de nœuds sur lequel Workload Identity est activé, exécutez la commande suivante :

gcloud container node-pools create NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --workload-metadata=GKE_METADATA

Remplacez les éléments suivants :

• NODEPOOL_NAME : nom du nouveau pool de nœuds.
• CLUSTER_NAME : nom du cluster existant sur lequel Workload Identity est activé.

L'option --workload-metadata=GKE_METADATA configure le pool de nœuds de sorte qu'il utilise le serveur de métadonnées GKE. Nous vous recommandons d'inclure cette option pour que la création du pool de nœuds échoue si Workload Identity n'est pas activé sur le cluster.

Mettre à jour un pool de nœuds existant

Vous pouvez activer manuellement Workload Identity sur des pools de nœuds existants après l'avoir activé sur le cluster.

Attention : La modification immédiate du pool de nœuds active Workload Identity pour toutes les charges de travail exécutées dans le pool de nœuds. Cela empêche les charges de travail d'utiliser le compte de service Compute Engine par défaut et peut entraîner des interruptions.

gcloud

1. Dans la console Google Cloud, activez Cloud Shell.

   Activer Cloud Shell

   En bas de la fenêtre de la console Google Cloud, une session Cloud Shell démarre et affiche une invite de ligne de commande. Cloud Shell est un environnement shell dans lequel Google Cloud CLI est déjà installé, et dans lequel des valeurs sont déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.

2. Pour modifier un pool de nœuds existant de sorte qu'il utilise Workload Identity, exécutez la commande suivante :

   gcloud container node-pools update NODEPOOL_NAME \
       --cluster=CLUSTER_NAME \
       --region=COMPUTE_REGION \
       --workload-metadata=GKE_METADATA
   

   Si Workload Identity est activé pour un cluster, vous pouvez le désactiver de manière sélective pour un pool de nœuds spécifique en indiquant --workload-metadata=GCE_METADATA. Pour en savoir plus, reportez-vous à la section Protéger les métadonnées d'un cluster.

Console

Pour modifier un pool de nœuds existant de sorte qu'il utilise Workload Identity, procédez comme suit :

1. Accédez à la page Google Kubernetes Engine dans la console Google Cloud.

   Accéder à Google Kubernetes Engine

2. Dans la liste des clusters, cliquez sur le nom du cluster que vous souhaitez modifier.

3. Cliquez sur l'onglet Nœuds.

4. Dans la section Pools de nœuds, cliquez sur le nom du pool de nœuds que vous souhaitez modifier.

5. Sur la page Détails du pool de nœuds, cliquez sur Modifier.

6. Dans la section Sécurité de la page Modifier le pool de nœuds, cochez la case Activer le serveur de métadonnées GKE.

7. Cliquez sur Enregistrer.

Configurer des applications pour qu'elles utilisent Workload Identity

Après avoir activé Workload Identity, vous devez configurer vos applications pour qu'elles s'authentifient auprès de Google Cloud à l'aide de Workload Identity avant de les migrer vers les nouveaux pools de nœuds.

Vous devez attribuer un compte de service Kubernetes à l'application et le configurer pour qu'il agisse en tant que compte de service IAM.

La procédure suivante permet de configurer vos applications pour qu'elles utilisent Workload Identity s'il est activé sur le cluster.

1. Obtenez les identifiants de votre cluster :

   gcloud container clusters get-credentials CLUSTER_NAME \
       --region=COMPUTE_REGION
   

   Remplacez les éléments suivants :

   • CLUSTER_NAME : nom de votre cluster sur lequel Workload Identity est activé.
   • COMPUTE_REGION : région Compute Engine du cluster.

2. Créez un espace de noms à utiliser pour le compte de service Kubernetes. Vous pouvez également utiliser l'espace de noms par défaut ou tout espace de noms existant.

   kubectl create namespace NAMESPACE
   

3. Créez un compte de service Kubernetes que votre application pourra utiliser. Vous pouvez également utiliser n'importe quel compte de service Kubernetes existant dans n'importe quel espace de noms, y compris le compte de service default.

   kubectl create serviceaccount KSA_NAME \
       --namespace NAMESPACE
   

   Remplacez les éléments suivants :

   • KSA_NAME : nom de votre nouveau compte de service Kubernetes.
   • NAMESPACE : nom de l'espace de noms Kubernetes du compte de service.

4. Créez un compte de service IAM pour votre application ou utilisez un compte de service IAM existant. Vous pouvez utiliser n'importe quel compte de service IAM dans n'importe quel projet de votre organisation. Pour Config Connector, appliquez l'objet IAMServiceAccount pour le compte de service sélectionné.

   gcloud

   1. Dans la console Google Cloud, activez Cloud Shell.

      Activer Cloud Shell

      En bas de la fenêtre de la console Google Cloud, une session Cloud Shell démarre et affiche une invite de ligne de commande. Cloud Shell est un environnement shell dans lequel Google Cloud CLI est déjà installé, et dans lequel des valeurs sont déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.

   2. Pour créer un compte de service IAM à l'aide de la CLI gcloud, exécutez la commande suivante.

      Remarque : Si vous utilisez un compte de service IAM existant avec la CLI gcloud, ignorez cette étape.

      gcloud iam service-accounts create GSA_NAME \
          --project=GSA_PROJECT
      

      Remplacez les éléments suivants :

      • GSA_NAME : nom du nouveau compte de service IAM.
      • GSA_PROJECT : ID du projet Google Cloud de votre compte de service IAM.

   Config Connector

   Pour utiliser un compte de service IAM nouveau ou existant avec Config Connector, appliquez le fichier de configuration suivant.

   Remarque : Vous devez appliquer l'objet IAMServiceAccount au cluster à l'aide de kubectl même si vous utilisez un compte de service IAM existant. Remplacez GSA_NAME dans le fichier de configuration par le nom du compte de service à utiliser.

   Remarque : Cette étape nécessite Config Connector. Suivez les instructions d'installation pour l'installer sur votre cluster.

   Afficher sur GitHub

   apiVersion: iam.cnrm.cloud.google.com/v1beta1
   kind: IAMServiceAccount
   metadata:
     name: [GSA_NAME]
   spec:
     displayName: [DISPLAY_NAME]

   Pour déployer ce fichier manifeste, téléchargez-le sur votre ordinateur sous le nom service-account.yaml.

   Utilisez kubectl pour appliquer le fichier manifeste :

   kubectl apply -f service-account.yaml
   

   Pour en savoir plus sur l'autorisation d'accéder aux API Google Cloud via les comptes de service IAM, consultez la page Comprendre les comptes de service.

5. Assurez-vous que votre compte de service IAM dispose des rôles dont vous avez besoin. Vous pouvez attribuer des rôles supplémentaires à l'aide de la commande suivante :

   gcloud projects add-iam-policy-binding GSA_PROJECT \
       --member "serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com" \
       --role "ROLE_NAME"
   

   Remplacez les éléments suivants :

   • GSA_PROJECT : ID du projet Google Cloud de votre compte de service IAM.
   • GSA_NAME : nom de votre compte de service IAM.
   • ROLE_NAME : rôle IAM à attribuer à votre compte de service, tel que roles/spanner.viewer.

6. Autorisez le compte de service Kubernetes à emprunter l'identité du compte de service IAM en ajoutant une liaison de stratégie IAM entre les deux comptes de service. Cette liaison permet au compte de service Kubernetes d'agir en tant que compte de service IAM.

   gcloud

   1. Dans la console Google Cloud, activez Cloud Shell.

      Activer Cloud Shell

      En bas de la fenêtre de la console Google Cloud, une session Cloud Shell démarre et affiche une invite de ligne de commande. Cloud Shell est un environnement shell dans lequel Google Cloud CLI est déjà installé, et dans lequel des valeurs sont déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.

   2. Dans votre environnement de développement, exécutez la commande suivante :

      gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \
          --role roles/iam.workloadIdentityUser \
          --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]"
      

   Config Connector

   Remarque : Cette étape nécessite Config Connector. Suivez les instructions d'installation pour l'installer sur votre cluster.

   Afficher sur GitHub

   apiVersion: iam.cnrm.cloud.google.com/v1beta1
   kind: IAMPolicy
   metadata:
     name: iampolicy-workload-identity-sample
   spec:
     resourceRef:
       apiVersion: iam.cnrm.cloud.google.com/v1beta1
       kind: IAMServiceAccount
       name: [GSA_NAME]
     bindings:
       - role: roles/iam.workloadIdentityUser
         members:
           - serviceAccount:[PROJECT_ID].svc.id.goog[[K8S_NAMESPACE]/[KSA_NAME]]

   Pour déployer ce fichier manifeste, téléchargez-le sur votre ordinateur sous le nom policy-binding.yaml. Remplacez GSA_NAME, PROJECT_ID, NAMESPACE et KSA_NAME par les valeurs de votre environnement. Exécutez ensuite la commande ci-dessous :

   kubectl apply -f policy-binding.yaml
   

7. Annotez le compte de service Kubernetes avec l'adresse e-mail du compte de service IAM.

   kubectl

   1. Dans la console Google Cloud, activez Cloud Shell.

      Activer Cloud Shell

      En bas de la fenêtre de la console Google Cloud, une session Cloud Shell démarre et affiche une invite de ligne de commande. Cloud Shell est un environnement shell dans lequel Google Cloud CLI est déjà installé, et dans lequel des valeurs sont déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.

   2. Dans votre environnement de développement, exécutez la commande suivante :

      kubectl annotate serviceaccount KSA_NAME \
          --namespace NAMESPACE \
          iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com
      

   yaml

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     annotations:
       iam.gke.io/gcp-service-account: GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
     name: KSA_NAME
     namespace: NAMESPACE
   

   Remarque : Cette annotation n'accorde pas à elle seule l'accès afin d'emprunter l'identité du compte de service IAM. Si la liaison IAM n'existe pas, le pod ne pourra pas utiliser le compte de service IAM.

8. Mettez à jour la spécification de pod pour planifier les charges de travail sur les nœuds qui utilisent Workload Identity et utiliser le compte de service Kubernetes annoté.

   Remarque : Ignorez spec.serviceAccountName si vous annotez le compte de service Kubernetes par défaut. Pour les clusters Autopilot, ignorez le champ nodeSelector. Autopilot rejette ce nodeSelector, car tous les nœuds utilisent Workload Identity.

   spec:
     serviceAccountName: KSA_NAME
     nodeSelector:
       iam.gke.io/gke-metadata-server-enabled: "true"
   

9. Appliquez la configuration mise à jour au cluster :

   kubectl apply -f DEPLOYMENT_FILE
   

   Remplacez DEPLOYMENT_FILE par le chemin d'accès à la spécification de pod mise à jour.

Vérifier la configuration de Workload Identity

Vérifiez que les comptes de service sont configurés correctement en créant un pod avec le compte de service Kubernetes qui exécute l'image du conteneur spécifique à l'OS, puis en vous y connectant à l'aide d'une session interactive.

Linux

Créez un pod qui utilise le compte de service Kubernetes annoté et appelez le point de terminaison service-accounts avec curl.

1. Enregistrez la configuration suivante sous wi-test.yaml :

   apiVersion: v1
   kind: Pod
   metadata:
     name: workload-identity-test
     namespace: NAMESPACE
   spec:
     containers:
     - image: google/cloud-sdk:slim
       name: workload-identity-test
       command: ["sleep","infinity"]
     serviceAccountName: KSA_NAME
     nodeSelector:
       iam.gke.io/gke-metadata-server-enabled: "true"
   

   L'image google/cloud-sdk inclut Google Cloud CLI, qui constitue un moyen pratique de consommer les API Google Cloud. Le téléchargement de l'image peut prendre un certain temps.

   Remarque : Pour les clusters Autopilot, ignorez le champ nodeSelector. Autopilot rejette ce nodeSelector, car tous les nœuds utilisent Workload Identity.

2. Créez le pod :

   kubectl apply -f wi-test.yaml
   

3. Ouvrez une session interactive dans le pod :

   kubectl exec -it workload-identity-test \
     --namespace NAMESPACE \
     -- /bin/bash
   

4. Exécutez la commande suivante dans le pod :

   curl -H "Metadata-Flavor: Google" http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/email
   

   Si les comptes de service sont correctement configurés, l'adresse e-mail du compte de service IAM est répertoriée en tant qu'identité active (et unique). Cela montre que, par défaut, le pod agit en tant qu'autorité du compte de service IAM lors de l'appel des API Google Cloud.

Windows

Créez un pod avec le compte de service Kubernetes qui exécute l'image du conteneur servercore.

1. Enregistrez le fichier manifeste suivant :

   apiVersion: v1
   kind: Pod
   metadata:
     name: workload-identity-test
     namespace: NAMESPACE
   spec:
     containers:
     - image: IMAGE_NAME
       name: workload-identity-test
       command: ["powershell.exe", "sleep", "3600"]
     serviceAccountName: KSA_NAME
     nodeSelector:
       kubernetes.io/os: windows
       cloud.google.com/gke-os-distribution: windows_ltsc
       iam.gke.io/gke-metadata-server-enabled: "true"
   

   Remplacez IMAGE_NAME par l'une des valeurs d'image ServerCore suivantes pour le conteneur :

   Image de nœud Windows Server	Image du conteneur servercore
   WINDOWS_LTSC, WINDOWS_LTSC_CONTAINERD	mcr.microsoft.com/windows/servercore:ltsc2019
   WINDOWS_SAC, WINDOWS_SAC_CONTAINERD	Avertissement : Les images SAC (Semi-Annual Channel) Windows Server ne seront plus compatibles après le 9 août 2022, car Microsoft supprime la compatibilité avec SAC. Pour obtenir des instructions sur l'impact potentiel et la migration, consultez la page Fin de la maintenance du canal semi-annuel Windows Server. Vérifiez le mappage des versions entre la version du nœud GKE et la version SAC de Windows. Pour Windows Server version 1909, spécifiez mcr.microsoft.com/windows/servercore:1909. Sinon, spécifiez mcr.microsoft.com/windows/servercore:20H2.

2. Ouvrez une session interactive dans le pod :

   kubectl exec -it workload-identity-test \
     --namespace NAMESPACE -- powershell
   

3. Exécutez la commande PowerShell suivante dans le pod :

   Invoke-WebRequest  -Headers @{"Metadata-Flavor"="Google"} -Uri  http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/email  -UseBasicParsing
   

   Si les comptes de service sont correctement configurés, l'adresse e-mail du compte de service IAM est répertoriée en tant qu'identité active (et unique). Ainsi, le pod utilise l'autorité du compte de service IAM par défaut lors de l'appel des API Google Cloud.

Utiliser Workload Identity à partir de votre code

La procédure d'authentification auprès des services Google Cloud à partir de votre code est identique à l'authentification à l'aide du serveur de métadonnées Compute Engine. Lorsque vous utilisez Workload Identity, vos requêtes adressées au serveur de métadonnées de l'instance sont acheminées vers le serveur de métadonnées GKE. Le code existant qui s'authentifie à l'aide du serveur de métadonnées de l'instance (comme le code utilisant les bibliothèques clientes Google Cloud) devrait fonctionner sans qu'aucune modification ne soit requise.

Utiliser un quota d'un autre projet avec Workload Identity

Sur les clusters exécutant GKE version 1.24 ou ultérieure, vous pouvez éventuellement configurer votre compte de service Kubernetes pour qu'il utilise le quota d'un autre projet Google Cloud lors des appels aux méthodes GenerateAccessToken et GenerateIdToken dans l'API IAM Service Account Credentials. Cela vous permet d'éviter d'utiliser l'intégralité du quota de votre projet principal, en utilisant plutôt le quota d'autres projets pour ces services de votre cluster.

Pour configurer un projet de quota avec Workload Identity, procédez comme suit :

1. Accordez l'autorisation serviceusage.services.use sur le projet de quota au compte de service Kubernetes.

   gcloud projects add-iam-policy-binding \
   --role=roles/serviceusage.serviceUsageConsumer \
   --member=serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME] \
   QUOTA_PROJECT_ID
   

   Remplacez QUOTA_PROJECT_ID par l'ID du projet de quota.

2. Annotez le compte de service Kubernetes avec le projet de quota :

   kubectl annotate serviceaccount KSA_NAME \
   --namespace NAMESPACE \
   iam.gke.io/credential-quota-project=QUOTA_PROJECT_ID
   

Pour vérifier que la configuration fonctionne correctement, procédez comme suit :

1. Créez un pod et démarrez une session de shell en suivant les instructions de la section Vérifier la configuration de Workload Identity.

2. Effectuez une requête de jeton de compte de service :

   curl -H "Metadata-Flavor: Google" http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token
   

3. Accédez à la page API Service Accounts Credentials IAM dans la console Google Cloud pour votre projet de quota:

   Accéder aux API

4. Vérifier les variations de trafic

Effectuer un nettoyage

Pour arrêter d'utiliser Workload Identity, révoquez l'accès au compte de service IAM et désactivez Workload Identity sur le cluster.

Révoquer un accès

1. Révoquez l'accès au compte de service IAM :

   gcloud

   1. Dans la console Google Cloud, activez Cloud Shell.

      Activer Cloud Shell

      En bas de la fenêtre de la console Google Cloud, une session Cloud Shell démarre et affiche une invite de ligne de commande. Cloud Shell est un environnement shell dans lequel Google Cloud CLI est déjà installé, et dans lequel des valeurs sont déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.

   2. Dans votre environnement de développement, exécutez la commande suivante :

      gcloud iam service-accounts remove-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \
          --role roles/iam.workloadIdentityUser \
          --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]"
      

      Remplacez les éléments suivants :

      • PROJECT_ID : ID de projet du cluster GKE.
      • NAMESPACE : nom de l'espace de noms Kubernetes dans lequel se trouve votre compte de service Kubernetes.
      • KSA_NAME : nom du compte de service Kubernetes dont l'accès sera révoqué.
      • GSA_NAME : nom du compte de service IAM.
      • GSA_PROJECT : ID de projet du compte de service IAM.

   Config Connector

   Si vous avez utilisé Config Connector pour créer le compte de service, supprimez le compte de service avec kubectl.

   kubectl delete -f service-account.yaml
   

   L'expiration des jetons mis en cache peut prendre jusqu'à 30 minutes. Vous pouvez vérifier si les jetons mis en cache ont expiré à l'aide de cette commande :

   gcloud auth list
   

   Les jetons mis en cache arrivent à expiration lorsque le résultat de cette commande n'inclut plus GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com.

2. Supprimez l'annotation du compte de service Kubernetes. Cette étape est facultative, car l'accès a été révoqué par IAM.

   kubectl annotate serviceaccount KSA_NAME \
       --namespace NAMESPACE iam.gke.io/gcp-service-account-
   

   Remarque : Si vous ne supprimez pas l'annotation, le compte de service IAM que vous utilisez avec Workload Identity peut continuer à s'afficher lorsque vous exécutez gcloud auth list. Toutefois, GKE n'utilise pas le compte de service IAM pour s'authentifier auprès des services Google Cloud.

Désactiver Workload Identity

Vous ne pouvez désactiver Workload Identity que sur les clusters GKE standards.

gcloud

1. Dans la console Google Cloud, activez Cloud Shell.

   Activer Cloud Shell

   En bas de la fenêtre de la console Google Cloud, une session Cloud Shell démarre et affiche une invite de ligne de commande. Cloud Shell est un environnement shell dans lequel Google Cloud CLI est déjà installé, et dans lequel des valeurs sont déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.

2. Désactivez Workload Identity sur chaque pool de nœuds :

   gcloud container node-pools update NODEPOOL_NAME \
       --cluster=CLUSTER_NAME \
       --workload-metadata=GCE_METADATA
   

   Répétez cette commande pour chaque pool de nœuds du cluster.

3. Désactivez Workload Identity dans le cluster :

   gcloud container clusters update CLUSTER_NAME \
       --disable-workload-identity
   

Console

1. Accédez à la page Google Kubernetes Engine dans Google Cloud Console.

   Accéder à Google Kubernetes Engine

2. Dans la liste des clusters, cliquez sur le nom du cluster que vous souhaitez modifier.

3. Cliquez sur l'onglet Nœuds.

4. Pour désactiver Workload Identity sur chaque pool de nœuds, procédez comme suit pour chaque pool de nœuds de la section Pools de nœuds :

   1. Cliquez sur le nom du pool de nœuds que vous souhaitez modifier.
   2. Sur la page Détails du pool de nœuds, cliquez sur Modifier.
   3. Dans la section Sécurité de la page Modifier le pool de nœuds, décochez la case Activer le serveur de métadonnées GKE.
   4. Cliquez sur Enregistrer.

5. Pour désactiver Workload Identity sur le cluster, procédez comme suit :

   1. Cliquez sur l'onglet Détails.
   2. Dans la section Sécurité, à côté de Workload Identity, cliquez sur  Modifier.
   3. Dans la boîte de dialogue Modifier Workload Identity, décochez la case Activer Workload Identity.
   4. Cliquez sur Enregistrer les modifications.

Désactiver Workload Identity dans votre organisation

Du point de vue de la sécurité, Workload Identity permet à GKE de valider des identités de compte de service Kubernetes pouvant être authentifiées et autorisées sur les ressources Google Cloud. Si vous êtes un administrateur ayant effectué des actions pour isoler les charges de travail des ressources Google Cloud, par exemple en désactivant la création de comptes de service ou en désactivant la création de clés de compte de service, vous pouvez également souhaiter désactiver Workload Identity dans votre organisation.

Voir ces instructions pour désactiver Workload Identity pour votre organisation.

Dépannage

Pour obtenir des informations de dépannage, consultez la page Résoudre les problèmes liés à Workload Identity.

Étapes suivantes

• Apprenez-en plus sur Workload Identity.
• Consultez la présentation de la sécurité dans GKE.
• Obtenez plus d'informations sur la protection des métadonnées de cluster.
• Familiarisez-vous avec les comptes de service IAM.