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
.
Assurez-vous d'avoir activé l'API d'identifiants de compte de service 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
-
Dans la console Google Cloud, activez 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.
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 clusterCOMPUTE_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.
Cliquez sur add_box 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
-
Dans la console Google Cloud, activez 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.
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.
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
-
Dans la console Google Cloud, activez 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.
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.
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 de votre 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 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.
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
-
Dans la console Google Cloud, activez 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.
Pour créer un compte de service IAM à l'aide de la CLI gcloud, exécutez la commande suivante.
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 : Cette étape nécessite Config Connector. Suivez les instructions d'installation pour l'installer sur votre cluster.
Pour déployer ce fichier manifeste, téléchargez-le sur votre ordinateur sous le nomservice-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 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 queroles/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
-
Dans la console Google Cloud, activez 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.
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.
Pour déployer ce fichier manifeste, téléchargez-le sur votre ordinateur sous le nompolicy-binding.yaml
. RemplacezGSA_NAME
,PROJECT_ID
,NAMESPACE
etKSA_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
-
Dans la console Google Cloud, activez 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.
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
-
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é.
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.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
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écifiezmcr.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 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 :
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:
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
-
Dans la console Google Cloud, activez 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.
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
.-
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-
Désactiver Workload Identity
Vous ne pouvez désactiver Workload Identity que sur les clusters GKE standards.
gcloud
-
Dans la console Google Cloud, activez 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.
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.
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 :
- 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, décochez la case Activer le serveur de métadonnées GKE.
- Cliquez sur Enregistrer.
Pour désactiver Workload Identity sur le cluster, procédez comme suit :
- Cliquez sur l'onglet Détails.
- Dans la section Sécurité, à côté de Workload Identity, cliquez sur Modifier.
- Dans la boîte de dialogue Modifier Workload Identity, décochez la case Activer Workload Identity.
- 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.