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

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 :

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

Accéder à Google Kubernetes Engine
Cliquez sur Créer.
Dans la boîte de dialogue Créer un cluster, cliquez sur Configurer pour GKE Standard.
Dans le menu de navigation, dans la section Cluster, cliquez sur Sécurité.
Cochez la case Activer Workload Identity.
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

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 :

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

Accéder à Google Kubernetes Engine
Dans la liste des clusters, cliquez sur le nom du cluster que vous souhaitez modifier.
Dans la section Sécurité de la page "Détails du cluster", cliquez sur Modifier Workload Identity.
Dans la boîte de dialogue Modifier Workload Identity, cochez la case Activer Workload Identity.
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.

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.

gcloud

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 :

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

Accéder à Google Kubernetes Engine
Dans la liste des clusters, cliquez sur le nom du cluster que vous souhaitez modifier.
Cliquez sur l'onglet Nœuds.
Dans la section Pools de nœuds, cliquez sur le nom du pool de nœuds que vous souhaitez modifier.
Sur la page Détails du pool de nœuds, cliquez sur Modifier.
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.
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.

Obtenez les identifiants de votre cluster :
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --region=COMPUTE_REGION
```
Remplacez les éléments suivants :
- CLUSTER_NAME: nom du cluster sur lequel Workload Identity est activé.
- COMPUTE_REGION : région Compute Engine du cluster.
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
```
Créez un compte de service Kubernetes que votre application pourra utiliser. Vous pouvez également utiliser le compte de service Kubernetes par défaut dans l'espace de noms par défaut ou dans un espace de noms existant.
```
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.
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
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.
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 PROJECT_ID \
    --member "serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com" \
    --role "ROLE_NAME"
```
Remplacez les éléments suivants :
- PROJECT_ID : ID de votre projet Google Cloud.
- GSA_NAME : nom de votre compte de service IAM.
- GSA_PROJECT : ID du projet Google Cloud de votre compte de service IAM.
- ROLE_NAME : rôle IAM à attribuer à votre compte de service, tel que roles/spanner.viewer.
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
```
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
```

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

kubectl

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

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"
```
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.

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.
Créez le pod :
```
kubectl apply -f wi-test.yaml
```

Ouvrez une session interactive dans le pod :

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

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.

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

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`.

WINDOWS_SAC,
WINDOWS_SAC_CONTAINERD

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.

Ouvrez une session interactive dans le pod :

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

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 API Google Cloud. 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 différents services de votre cluster.

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

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.

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 :

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.

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

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

Accéder aux API
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

Révoquez l'accès au compte de service IAM :
gcloud
```
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.
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

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.

Désactivez Workload Identity dans le cluster :

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

Console

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

Accéder à Google Kubernetes Engine
Dans la liste des clusters, cliquez sur le nom du cluster que vous souhaitez modifier.
Cliquez sur l'onglet Nœuds.
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.
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.

Utiliser Workload Identity

Avant de commencer

Activer Workload Identity

Créer un cluster

gcloud

Console

Mettre à jour un cluster existant

gcloud

Console

Migrer des charges de travail existantes vers Workload Identity

Créer un pool de nœuds

Mettre à jour un pool de nœuds existant

gcloud

Console

Configurer des applications pour qu'elles utilisent Workload Identity

gcloud

Config Connector

gcloud

Config Connector

kubectl

yaml

Vérifier la configuration de Workload Identity

Linux

Windows

Utiliser Workload Identity à partir de votre code

Utiliser un quota d'un autre projet avec Workload Identity

Effectuer un nettoyage

Révoquer un accès

gcloud

Config Connector

Désactiver Workload Identity

gcloud

Console

Désactiver Workload Identity dans votre organisation

Dépannage

Étapes suivantes