Utiliser Workload Identity

Cette page présente la solution recommandée pour que vos applications Google Kubernetes Engine (GKE) consomment les services fournis par les API Google.

Présentation

Workload Identity est la solution recommandée pour accéder aux services Google Cloud à partir des applications s'exécutant dans GKE en raison de ses propriétés de sécurité renforcée et de sa facilité de gestion. Pour en savoir plus sur les autres moyens d'accéder aux API Google Cloud depuis GKE, consultez la section Alternatives ci-dessous.

Terminologie

Ce document distingue les comptes de service Kubernetes et les comptes de service Google. Les comptes de service Kubernetes sont des ressources Kubernetes, tandis que les comptes de service Google sont spécifiques à Google Cloud. Les autres articles de la documentation Google Cloud désignent les comptes de service Google comme étant des "comptes de service".

Concepts

Les applications s'exécutant sur GKE doivent s'authentifier pour utiliser les API Google Cloud telles que les API de calcul, les API de stockage et de base de données ou les API de machine learning.

Avec Workload Identity, vous pouvez configurer un compte de service Kubernetes qui agira en tant que compte de service Google. Les pods exécutés en tant que compte de service Kubernetes s'authentifient automatiquement en tant que compte de service Google lors de l'accès aux API Google Cloud. Cela vous permet d'attribuer des identités et des autorisations distinctes et précises pour chaque application du cluster.

Pour effectuer un mappage sécurisé entre les comptes de service Kubernetes et les comptes de service Google, Workload Identity introduit le concept de pool d'identités de charge de travail d'un cluster, ce qui permet à Identity and Access Management (IAM) de faire confiance et de comprendre les identifiants du compte de service Kubernetes.

Lorsque vous activez Workload Identity sur votre cluster GKE, le pool d'identités de la charge de travail du cluster est défini sur PROJECT_ID.svc.id.goog. Cela permet à IAM d'authentifier les comptes de service Kubernetes avec le nom de membre suivant :

serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME]

Dans ce nom de membre :

PROJECT_ID.svc.id.goog correspond au pool d'identités de charge de travail défini sur le cluster.
KSA_NAME est le nom du compte de service Kubernetes qui envoie la requête.
K8S_NAMESPACE est l'espace de noms Kubernetes dans lequel le compte de service Kubernetes est défini.

Il n'existe qu'un seul pool d'identités de charge de travail fixe par projet Google Cloud, PROJECT_ID.svc.id.goog, et il est automatiquement créé pour vous.

Uniformité de l'identité entre les clusters

Tous les comptes de service Kubernetes partageant un nom, un nom d'espace de noms et un pool d'identités de charge de travail sont associés au même nom de membre et partagent donc l'accès aux ressources Google Cloud. Cette identité commune permet de donner aux applications d'un pool d'identités de charge de travail l'accès à une ressource externe plutôt que cluster par cluster.

Pour mieux illustrer ce point, prenons l'exemple suivant. Les clusters A, B et C sont enregistrés dans le même pool d'identités de charge de travail. Lorsque des applications de l'espace de noms backend accèdent aux ressources Google Cloud, leur identité est mappée à un compte de service Google commun appelé back, quel que soit le cluster hébergeant l'application. Le compte de service Google back peut être autorisé sur plusieurs API Google Cloud, de Cloud Storage à Cloud SQL.

En raison de l'uniformité des identités, il est important que tous les clusters d'un pool d'identités de charge de travail soient approuvés et bien validés. Pour reprendre l'exemple précédent, si le cluster C appartient à une équipe distincte non approuvée, ses membres peuvent également créer un espace de noms backend et accéder aux API Google Cloud comme en cas d'appartenance à backend dans le cluster A ou B.

Schéma illustrant l'uniformité des identités dans un pool d'identités de charge de travail — Uniformité des identités qui accèdent aux API Google Cloud avec Workload Identity

Pour éviter que les clusters ne partagent des autorisations, ceux-ci doivent se trouver dans des projets distincts ou utiliser des noms d'espace de noms Kubernetes distincts. À titre d'exemple, les utilisateurs disposant de clusters "dev" permissifs et de clusters "prod" verrouillés doivent envisager de séparer ces clusters dans des projets différents afin d'obtenir des pools d'identités de charge de travail distincts.

Limites

Actuellement, il n'existe qu'un seul pool d'identités de charge de travail fixe par projet Google Cloud, PROJECT_ID.svc.id.goog, et il est automatiquement créé pour vous.
Actuellement, Workload Identity n'est pas compatible lorsqu'une charge de travail s'exécute dans des clusters Anthos sur VMware.
Workload Identity se substitue à la nécessité d'utiliser la dissimulation de métadonnées et les deux approches sont incompatibles. Les métadonnées sensibles protégées par la dissimulation de métadonnées sont également protégées par Workload Identity.
Lorsque le serveur de métadonnées GKE est activé sur un pool de nœuds, les pods ne peuvent plus accéder au serveur de métadonnées Compute Engine. Au lieu de cela, les requêtes envoyées par ces pods aux API de métadonnées seront acheminées vers le serveur de métadonnées GKE. La seule exception à cette règle concerne les pods s'exécutant sur le réseau hôte (voir l'élément suivant).
Workload Identity ne peut pas être utilisé par des pods en cours d'exécution sur le réseau hôte. Les requêtes envoyées par ces pods aux API de métadonnées seront acheminées vers le serveur de métadonnées Compute Engine.
Le serveur de métadonnées GKE a besoin de quelques secondes pour pouvoir commencer à accepter les requêtes sur un pod nouvellement créé. Par conséquent, les tentatives d'authentification à l'aide de Workload Identity dans les premières secondes de la vie d'un pod peuvent échouer. Une nouvelle tentative d'appel permet de résoudre le problème. Pour en savoir plus, consultez la section de dépannage.
Les agents de journalisation et de surveillance intégrés à GKE continueront à utiliser le compte de service du nœud.
Workload Identity n'est pas compatible avec les nœuds Windows.
Workload Identity doit être configuré manuellement pour que Cloud Run pour Anthos sur Google Cloud continue à générer des métriques de requêtes.
Workload Identity installe ip-masq-agent si le cluster est créé sans l'option --disable-default-snat.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

Assurez-vous d'avoir activé l'API Google Kubernetes Engine.

Activer l'API Google Kubernetes Engine

Assurez-vous d'avoir installé le SDK Cloud.

Configurez les paramètres gcloud par défaut à l'aide de l'une des méthodes suivantes :

Utilisez gcloud init pour suivre les instructions permettant de définir les paramètres par défaut.
Utilisez gcloud config pour définir individuellement l'ID, la zone et la région de votre projet.

Utiliser gcloud init

Si le message d'erreur One of [--zone, --region] must be supplied: Please specify location s'affiche, effectuez les tâches ci-dessous.

Exécutez gcloud init et suivez les instructions :
```
gcloud init
```
Si vous utilisez SSH sur un serveur distant, utilisez l'option --console-only pour empêcher la commande d'ouvrir un navigateur :
```
gcloud init --console-only
```
Suivez les instructions pour autoriser gcloud à utiliser votre compte Google Cloud.
Créez ou sélectionnez une configuration.
Choisissez un projet Google Cloud.
Choisissez une zone Compute Engine par défaut.

Remarque : Vous pouvez remplacer ces paramètres par défaut dans les commandes gcloud à l'aide des options --project, --zone et --region.

Utiliser gcloud config

Définissez votre ID de projet par défaut :
```
gcloud config set project PROJECT_ID
```
Si vous utilisez des clusters zonaux, définissez votre zone de calcul par défaut :
```
gcloud config set compute/zone COMPUTE_ZONE
```
Si vous utilisez des clusters régionaux, définissez votre région de calcul par défaut :
```
gcloud config set compute/region COMPUTE_REGION
```
Mettez à jour gcloud vers la dernière version :
```
gcloud components update
```

Remarque : Vous pouvez remplacer ces paramètres par défaut dans les commandes gcloud à l'aide des options --project, --zone et --region.

Activer Workload Identity sur un cluster

Vous pouvez activer Workload Identity sur un cluster nouveau ou existant à l'aide de l'outil gcloud.

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

Activer l'API des identifiants IAM
Pour créer un cluster avec Workload Identity activé, exécutez la commande suivante :
```
gcloud container clusters create CLUSTER_NAME \
  --workload-pool=PROJECT_ID.svc.id.goog
```
Remplacez l'élément suivant :
- CLUSTER_NAME : nom du cluster
- PROJECT_ID : ID de votre projet Google Cloud
Cette action nécessite une autorisation container.clusters.create sur le projet.
Pour activer Workload Identity sur un cluster existant, modifiez le cluster à l'aide de la commande suivante :
```
gcloud container clusters update CLUSTER_NAME \
  --workload-pool=PROJECT_ID.svc.id.goog
```
Les pools de nœuds existants ne sont pas affectés. Les nouveaux pools de nœuds utilisent --workload-metadata=GKE_METADATA par défaut.

Cette action nécessite des autorisations container.clusters.update sur le cluster.

Migrer des applications vers Workload Identity

Choisissez la stratégie de migration idéale pour votre environnement. Vous pouvez migrer les pools de nœuds sur place ou créer des pools de nœuds lorsque Workload Identity est activé. Il est recommandé de créer des pools de nœuds si vous devez également modifier votre application pour qu'elle soit compatible avec cette fonctionnalité.

Option 1 : Créer un pool de nœuds avec Workload Identity (recommandé)

Ajoutez un pool de nœuds au cluster lorsque Workload Identity est activé, puis migrez manuellement les charges de travail sur ce pool. Cette opération ne fonctionne que si Workload Identity est activé sur le cluster.

gcloud container node-pools create NODEPOOL_NAME \
  --cluster=CLUSTER_NAME \
  --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.

Option 2 : Modifier le pool de nœuds

Modifiez le pool de nœuds existant pour activer GKE_METADATA. Cette mise à jour ne réussit que si Workload Identity est activé sur le cluster. Elle permet d'activer immédiatement Workload Identity pour les charges de travail déployées dans le pool de nœuds. Cette modification empêche les charges de travail d'utiliser le compte de service Compute Engine et doit être soigneusement déployée.

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

Cette action nécessite des autorisations container.nodes.update sur le projet.

S'authentifier sur Google Cloud

Cette section explique comment une application peut s'authentifier auprès de Google Cloud à l'aide de Workload Identity. Pour ce faire, attribuez un compte de service Kubernetes à l'application et configurez-la pour qu'elle agisse en tant que compte de service Google :

Configurez kubectl pour communiquer avec le cluster :
```
gcloud container clusters get-credentials CLUSTER_NAME
```
Remplacez CLUSTER_NAME par le nom du cluster que vous avez créé à l'étape précédente.

Cette action nécessite une autorisation container.clusters.get sur le projet.
Comme la plupart des autres ressources, les comptes de service Kubernetes se situent dans un espace de noms. Créez l'espace de noms à utiliser pour le compte de service Kubernetes.
```
kubectl create namespace K8S_NAMESPACE
```
Cette action nécessite l'autorisation RBAC : créer un espace de noms dans le cluster.
Créez le compte de service Kubernetes à utiliser pour votre application :
```
kubectl create serviceaccount --namespace K8S_NAMESPACE KSA_NAME
```
Remplacez l'élément suivant :
- K8S_NAMESPACE : nom de l'espace de noms Kubernetes que vous avez créé à l'étape précédente.
- KSA_NAME : nom que vous souhaitez utiliser pour le compte de service Kubernetes.
Cette action nécessite l'autorisation RBAC : créer des comptes de service dans l'espace de noms.

Vous pouvez également utiliser l'espace de noms par défaut ou le compte de service Kubernetes par défaut dans n'importe quel espace de noms.
Créez un compte de service Google pour votre application. Si vous disposez déjà d'un compte de service, vous pouvez l'utiliser au lieu d'en créer un autre. Le compte de service ne doit pas obligatoirement se trouver dans le même projet que votre cluster. Vous pouvez utiliser n'importe quel compte de service Google dans votre organisation.
gcloud
Remplacez GSA_NAME par le nom que vous avez attribué au compte de service.
```
gcloud iam service-accounts create GSA_NAME
```
Config Connector
Si Config Connector est déjà installé sur un cluster, vous pouvez créer un cluster GKE lorsque Workload Identity est activé à l'aide d'une configuration 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: IAMServiceAccount
metadata:
  name: [GSA_NAME]
spec:
  displayName: [GSA_NAME]
```
Pour déployer ce fichier manifeste, téléchargez-le sur votre ordinateur sous le nom service-account.yaml. Remplacez GSA_NAME par le nom que vous avez attribué au compte de service. Utilisez ensuite kubectl pour appliquer le fichier manifeste.
```
kubectl apply -f service-account.yaml
```
Cette action nécessite une autorisation iam.serviceAccounts.create sur le projet.

Pour en savoir plus sur l'autorisation d'accéder aux API Google Cloud via les comptes de service Google, consultez la page Comprendre les comptes de service.
Autorisez le compte de service Kubernetes à emprunter l'identité du compte de service Google en créant une liaison de stratégie IAM entre eux. Cette liaison permet au compte de service Kubernetes d'agir en tant que compte de service Google.
gcloud
```
gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME]" \
  GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
```
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, K8S_NAMESPACE et KSA_NAME par les valeurs de votre environnement. Exécutez ensuite la commande ci-dessous :
```
kubectl apply -f policy-binding.yaml
```
Cette action nécessite une autorisation iam.serviceAccounts.setIamPolicy sur le projet.
Ajoutez l'annotation iam.gke.io/gcp-service-account=GSA_NAME@PROJECT_ID au compte de service Kubernetes à l'aide de l'adresse e-mail du compte de service Google.
kubectl
```
kubectl annotate serviceaccount \
  --namespace K8S_NAMESPACE \
  KSA_NAME \
  iam.gke.io/gcp-service-account=GSA_NAME@PROJECT_ID.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: K8S_NAMESPACE
```
Cette action nécessite des autorisations de modification RBAC sur le compte de service Kubernetes.

Remarque : Cette annotation n'accorde pas à elle seule l'accès afin d'emprunter l'identité du compte de service Google. Si la liaison IAM n'existe pas, le pod ne pourra pas utiliser le compte de service Google.
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 cloud-sdk, puis en vous y connectant à l'aide d'une session interactive.
kubectl
```
kubectl run -it \
  --image google/cloud-sdk:slim \
  --serviceaccount KSA_NAME \
  --namespace K8S_NAMESPACE \
  workload-identity-test
```
yaml
```
apiVersion: v1
kind: Pod
metadata:
  name: workload-identity-test
  namespace: K8S_NAMESPACE
spec:
  containers:
  - image: google/cloud-sdk:slim
    name: workload-identity-test
    command: ["sleep","infinity"]
  serviceAccountName: KSA_NAME
```
L'image google/cloud-sdk inclut l'outil de ligne de commande gcloud, qui constitue un moyen pratique de consommer les API Google Cloud. Le téléchargement de l'image peut prendre un certain temps.

Cette action nécessite l'autorisation RBAC de créer des pods dans l'espace de noms.

Vous êtes maintenant connecté à une interface système interactive dans le pod créé. Exécutez la commande suivante dans le pod :
```
gcloud auth list
```
Si les comptes de service sont correctement configurés, l'adresse e-mail du compte de service Google est répertoriée en tant qu'identité active (et unique). Ainsi, le pod utilise l'autorité du compte de service Google 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.

Comprendre le serveur de métadonnées GKE

Le serveur de métadonnées GKE est un nouveau serveur de métadonnées conçu pour être utilisé avec Kubernetes. Il fonctionne en tant que daemonset, avec un pod sur chaque nœud du cluster. Le serveur de métadonnées intercepte les requêtes HTTP envoyées à http://metadata.google.internal (169.254.169.254:80), y compris les requêtes telles que GET /computeMetadata/v1/instance/service-accounts/default/token afin de récupérer un jeton pour le compte de service Google pour lequel le pod agit. Le trafic vers le serveur de métadonnées ne quitte jamais l'instance de VM qui héberge le pod.

Le serveur de métadonnées GKE met en œuvre uniquement un sous-ensemble de points de terminaison du serveur de métadonnées Compute Engine qui sont pertinents et sécurisés pour les charges de travail Kubernetes :

/computeMetadata/v1/instance/attributes/cluster-location
/computeMetadata/v1/instance/attributes/cluster-name
/computeMetadata/v1/instance/attributes/cluster-uid
/computeMetadata/v1/instance/hostname
/computeMetadata/v1/instance/id
/computeMetadata/v1/project/numeric-project-id
/computeMetadata/v1/project/project-id
/computeMetadata/v1/instance/service-accounts
/computeMetadata/v1/instance/service-accounts/default
/computeMetadata/v1/instance/service-accounts/default/aliases
/computeMetadata/v1/instance/service-accounts/default/email
/computeMetadata/v1/instance/service-accounts/default/identity
/computeMetadata/v1/instance/service-accounts/default/identity?audience=audience
/computeMetadata/v1/instance/service-accounts/default/scopes
/computeMetadata/v1/instance/service-accounts/default/token
/computeMetadata/v1/instance/service-accounts/default/token?scopes=comma-separated-list-of-scopes

Révoquer l'accès

Révoquez l'accès au compte de service Google à l'aide d'IAM :
gcloud
```
gcloud iam service-accounts remove-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME]" \
  GSA_NAME@GSA_PROJECT_ID.iam.gserviceaccount.com
```
Remplacez l'élément suivant :
- PROJECT_ID : conteneur d'ID de projet dans le cluster GKE.
- K8S_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 Google.
- GSA_PROJECT_ID : ID du projet contenant le compte de service Google.
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
```
Cette action nécessite des autorisations iam.serviceAccounts.setIamPolicy sur le compte de service.

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@PROJECT_ID.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 \
  --namespace K8S_NAMESPACE \
  KSA_NAME \
  iam.gke.io/gcp-service-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

Dépannage

Un pod ne peut pas s'authentifier auprès de Google Cloud

Si votre application ne peut pas s'authentifier auprès de Google Cloud, assurez-vous que ces paramètres sont correctement configurés :

Assurez-vous d'avoir activé l'API des identifiants de compte de service IAM dans le projet contenant le cluster GKE.

Activer l'API des identifiants IAM
Vérifiez que Workload Identity est activé sur le cluster en vérifiant qu'il possède un pool d'identités de charge de travail défini :
```
gcloud container clusters describe CLUSTER_NAME \
  --format="value(workloadIdentityConfig.workloadPool)"
```

Assurez-vous que le serveur de métadonnées GKE (GKE_METADATA) est configuré sur le pool de nœuds où votre application s'exécute :

gcloud container node-pools describe NODEPOOL_NAME \
  --cluster=CLUSTER_NAME \
  --format="value(config.workloadMetadataConfig.mode)"

Assurez-vous que le compte de service Kubernetes est correctement annoté.

kubectl describe serviceaccount \
  --namespace K8S_NAMESPACE \
  KSA_NAME

Il doit contenir une annotation au format suivant :

iam.gke.io/gcp-service-account: GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

Assurez-vous que le compte de service Google est correctement configuré.

gcloud iam service-accounts get-iam-policy \
  GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

Vérifiez qu'il existe une liaison au format suivant :

- members:
  - serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME]
  role: roles/iam.workloadIdentityUser

Si vous disposez d'une règle de réseau de cluster, assurez-vous que la sortie vers 127.0.0.1/32 sur le port 988 est autorisée :
```
kubectl describe networkpolicy NETWORK_POLICY_NAME
```

Erreurs d'expiration au démarrage du pod

Le serveur de métadonnées GKE a besoin de quelques secondes pour pouvoir commencer à accepter les requêtes sur un pod nouvellement créé. Par conséquent, les tentatives d'authentification à l'aide de Workload Identity dans les premières secondes de la vie d'un pod peuvent échouer pour les applications et les bibliothèques clientes Google Cloud configurées avec un délai avant expiration court.

En cas d'erreurs d'expiration, vous pouvez modifier le code de l'application pour attendre quelques secondes et réessayer. Vous pouvez également déployer un conteneur initContainer qui attend que le serveur de métadonnées GKE soit prêt avant d'exécuter le conteneur principal du pod.

Voici un pod avec un exemple de conteneur initContainer :

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-initcontainer
spec:
  serviceAccountName: ksa-name
  initContainers:
  - image:  gcr.io/google.com/cloudsdktool/cloud-sdk:326.0.0-alpine
    name: workload-identity-initcontainer
    command:  '/bin/bash'
    - '-c'
    - |
      curl -s -H 'Metadata-Flavor: Google' 'http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token' --retry 30 --retry-connrefused --retry-max-time 30 > /dev/null || exit 1
  containers:
  - image: gcr.io/your-project/your-image
    name: your-main-application-container

Désactiver Workload Identity sur un cluster

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
```
Cette action nécessite des autorisations container.clusters.update sur le cluster.

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. Les administrateurs qui ont pris des mesures pour isoler les charges de travail des ressources Google Cloud, telles que la désactivation de la création de comptes de service ou la désactivation de la création de clés de compte de service, peuvent également désactiver Workload Identity pour votre organisation.

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

Alternatives à Workload Identity

Il existe deux méthodes alternatives permettant d'accéder aux API Cloud à partir de GKE. Avec le lancement de Workload Identity, ces approches ne sont plus recommandées en raison des compromis qu'elles nécessitent.

Exportez les clés de compte de service et stockez-les en tant que secrets Kubernetes. Les clés de compte de service Google expirent au bout de 10 ans et sont renouvelées manuellement. L'exportation de clés de compte de service permet d'élargir le champ d'application d'une brèche de sécurité si celle-ci n'a pas été détectée.
Utilisez le compte de service Compute Engine de vos nœuds. Vous pouvez exécuter des pools de nœuds en tant que compte de service IAM dans votre projet. Si vous ne spécifiez pas de compte de service lors de la création du pool de nœuds, GKE utilisera le compte de service Compute Engine par défaut du projet. Le compte de service Compute Engine est partagé par toutes les charges de travail déployées sur ce nœud. Cela peut entraîner un surprovisionnement des autorisations.

Étape suivante

Consultez la présentation de la sécurité dans GKE.
Apprenez-en plus sur les pods.
Obtenez plus d'informations sur la protection des métadonnées de cluster.
Découvrez les comptes de service Google.

Utiliser Workload Identity

Présentation

Terminologie

Concepts

Uniformité de l'identité entre les clusters

Limites

Avant de commencer

Utiliser gcloud init

Utiliser gcloud config

Activer Workload Identity sur un cluster

Migrer des applications vers Workload Identity

Option 1 : Créer un pool de nœuds avec Workload Identity (recommandé)

Option 2 : Modifier le pool de nœuds

S'authentifier sur Google Cloud

gcloud

Config Connector

gcloud

Config Connector

kubectl

yaml

kubectl

yaml

Utiliser Workload Identity à partir de votre code

Comprendre le serveur de métadonnées GKE

Révoquer l'accès

gcloud

Config Connector

Dépannage

Un pod ne peut pas s'authentifier auprès de Google Cloud

Erreurs d'expiration au démarrage du pod

Désactiver Workload Identity sur un cluster

Désactiver Workload Identity dans votre organisation

Alternatives à Workload Identity

Étape suivante