Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

Workload Identity GKE

cloud

Définition

Workload Identity est le mécanisme recommandé par Google pour permettre aux pods GKE (Google Kubernetes Engine) d'appeler des APIs Google Cloud Platform (GCS, Pub/Sub, Spanner, Secret Manager) de manière sécurisée, sans stocker de clés JSON de Service Account dans le cluster ou dans des Secrets Kubernetes. Il établit une correspondance de confiance entre un Kubernetes Service Account et un GCP Service Account. Workload Identity fonctionne via le mécanisme OIDC (OpenID Connect). GKE agit comme un fournisseur d'identité OIDC et émet des tokens pour les ServiceAccounts Kubernetes. Ces tokens peuvent être présentés à Google Cloud IAM, qui les valide et génère des tokens d'accès GCP court-durée pour le Service Account GCP correspondant. L'application dans le pod utilise les ADC (Application Default Credentials) : le SDK Google Cloud récupère automatiquement le token depuis le metadata server GKE. La configuration de Workload Identity nécessite trois étapes. Premièrement, activer Workload Identity sur le cluster GKE et les node pools (--workload-pool=PROJECT_ID.svc.id.goog). Deuxièmement, créer un GCP Service Account avec les permissions IAM nécessaires. Troisièmement, créer un Kubernetes Service Account dans le namespace approprié et établir la correspondance via une annotation (iam.gke.io/gcp-service-account: gsa-name@project-id.iam.gserviceaccount.com) sur le KSA, combinée avec le rôle roles/iam.workloadIdentityUser accordé au principal serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME] sur le GSA. Les avantages sécurité de Workload Identity par rapport aux clés JSON sont majeurs : pas de clés longue durée stockées dans le cluster (chaque pod obtient des tokens de courte durée renouvelés automatiquement), révocation immédiate possible (révoquer l'accès IAM du GSA suffit), et logging complet via Cloud Audit Logs de toutes les utilisations du GSA. Workload Identity Federation (WIF) étend ce mécanisme à d'autres environnements : GitHub Actions, GitLab CI, AWS, Azure, et tout fournisseur OIDC externe peuvent s'authentifier à GCP sans clés JSON via la même mécanique de correspondance de confiance.

Configuration pas à pas

1. Activer WI : gcloud container clusters update CLUSTER --workload-pool=PROJECT_ID.svc.id.goog. 2. Créer GSA : gcloud iam service-accounts create my-app-gsa. 3. Accorder les permissions GCP au GSA (ex: roles/storage.objectViewer). 4. Créer KSA : kubectl create serviceaccount my-app-ksa -n my-namespace. 5. Annoter le KSA : kubectl annotate serviceaccount my-app-ksa -n my-namespace iam.gke.io/gcp-service-account=my-app-gsa@PROJECT_ID.iam.gserviceaccount.com. 6. Lier KSA au GSA : gcloud iam service-accounts add-iam-policy-binding my-app-gsa@PROJECT_ID.iam.gserviceaccount.com --role roles/iam.workloadIdentityUser --member serviceAccount:PROJECT_ID.svc.id.goog[my-namespace/my-app-ksa].

Validation et debugging

Testez la configuration depuis un pod utilisant le KSA annoté : curl -H 'Metadata-Flavor: Google' 'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/email' doit retourner l'email du GSA. Si l'annotation est incorrecte ou le binding IAM manquant, vous obtiendrez l'email du SA du nœud GKE. Utilisez kubectl exec pour tester depuis le pod et gcloud auth print-access-token dans le pod pour vérifier l'identité effective.

Workload Identity et sécurité multi-tenant

Dans un cluster GKE multi-tenant (plusieurs équipes partageant un cluster), Workload Identity avec des namespaces et des KSAs dédiés par application assure une isolation IAM forte : chaque application accède uniquement aux ressources GCP pour lesquelles son GSA a des permissions. Auditez régulièrement les bindings iam.workloadIdentityUser avec : gcloud iam service-accounts get-iam-policy GSA_EMAIL pour lister quels KSAs peuvent impersonner chaque GSA.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis