GCP Workload Identity Federation permet d’autoriser des identités externes (par exemple depuis l’Identity‑Provider de l’entreprise, un runner CI/CD ou AWS) pour des ressources GCP sans clés de Service‑Account Google permanentes. Le résultat est un Keyless Access avec des tokens de courte durée échangés automatiquement. Dans cet article, j’explique de manière pragmatique les prérequis, l’architecture, les pièges typiques, les étapes de vérification, les étapes d’implémentation concrètes ainsi que les mesures d’audit et de monitoring, afin que l’exploitation reste sécurisée et auditable.
Pourquoi Workload Identity Federation ?
Workload Identity Federation (WIF) est un mécanisme d’échange de tokens : un token émis en externe (souvent un OIDC‑JWT ; OIDC signifie OpenID Connect, une couche d’identité sur OAuth 2.0) est échangé via le Google Security Token Service (STS) contre un token d’accès Google temporaire. Des identifiants de courte durée réduisent le risque de fuites de clés permanentes, car les tokens expirent automatiquement. Ils simplifient en outre la rotation et garantissent que les autorisations sont gérées de manière centralisée via les rôles IAM.
Composants essentiels, brièvement expliqués
Un aperçu rapide des termes centraux :
- Workload Identity Pool: collection d’identités externes de confiance. Techniquement, une ressource GCP qui regroupe les providers.
- Provider: définit une source d’identité externe comme un issuer OIDC ou un endpoint AWS STS. Contient l’issuer URI et les audiences autorisées.
- Service Account: identité interne GCP avec des rôles ; des principals externes peuvent se faire passer pour ce Service Account via impersonation.
- STS (Security Token Service): le endpoint Google pour l’échange de tokens (subject_token → access_token).
- JWKS (JSON Web Key Set): clés publiques de l’IdP utilisées pour la vérification des JWT. Les rotations provoquent souvent des interruptions si elles ne sont pas gérées correctement.
Prérequis et première décision d’architecture
Vérifiez au préalable les prérequis organisationnels et techniques : droits IAM appropriés pour créer des pools et des providers, un IdP stable avec un endpoint JWKS disponible, des systèmes synchronisés via NTP (l’heure est centrale pour la validité des tokens) et un projet d’audit pour la conservation à long terme des logs. Décidez également si vous n’autorisez par provider que certaines audiences et quels claims doivent être utilisés comme attributs (p. ex. repo‑ID, subject, email).
Guide d’implémentation concret
L’ordre est important : Pool → Provider → Service Account → Binding → Test. Vous trouverez ci‑dessous des étapes basées sur des commandes à exécuter dans des projets de test.
1) Identity Pool anlegen
gcloud iam workload-identity-pools create my-pool
--project=PROJECT_ID
--location="global"
--display-name="My Identity Pool"
2) OIDC Provider anlegen
gcloud iam workload-identity-pools providers create-oidc my-oidc-provider
--project=PROJECT_ID
--location="global"
--workload-identity-pool="my-pool"
--display-name="AzureAD Provider"
--issuer-uri="https://login.microsoftonline.com/TENANT_ID/v2.0"
--allowed-audiences="api://my-app-client-id"
Pourquoi c’est important : l’issuer‑URI et les allowed‑audiences empêchent l’acceptation de tokens arbitraires. Les audiences sont les IDs des clients cibles, c’est‑à‑dire l’audience attendue (aud) dans le JWT.
3) Service Account anlegen und Binding mit Attributbedingung
gcloud iam service-accounts create my-app-sa
--project=PROJECT_ID
--display-name="Service Account for federated workloads"
PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format='value(projectNumber)')
gcloud iam service-accounts add-iam-policy-binding my-app-sa@PROJECT_ID.iam.gserviceaccount.com
--project=PROJECT_ID
--role=roles/iam.workloadIdentityUser
--member="principalSet://iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/my-pool/attribute.repository/my-app"
Bonne pratique : utilisez des attributs précis (ici attribute.repository) ou des conditions IAM (conditions) pour restreindre l’accès de manière granulaire.
4) Tester l’échange de jetons
curl -s -X POST https://sts.googleapis.com/v1/token
-H "Content-Type: application/x-www-form-urlencoded"
-d "grant_type=urn:ietf:params:oauth:grant-type:token-exchange&
subject_token_type=urn:ietf:params:oauth:token-type:jwt&
subject_token=EXTERNAL_OIDC_TOKEN&
requested_token_type=urn:ietf:params:oauth:token-type:access_token&
&audience=//iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/my-pool/providers/my-oidc-provider&
scope=https://www.googleapis.com/auth/cloud-platform"
En cas d’échec de l’échange, vérifiez : JWT valide, audience, issuer, accessibilité du JWKS et décalage NTP.
Opérationnaliser GCP Workload Identity Federation
La transition du Proof‑of‑Concept à l’exploitation productive exige des politiques pour le cycle de vie, les tests et l’observabilité. L’opérationnalisation comprend des tests automatisés, la surveillance des taux STS, la surveillance du JWKS et des revues IAM régulières.
Tests automatisés
Planifiez des jobs CI qui effectuent régulièrement un échange complet de jetons et exécutent une opération API minimale (p. ex. lecture des métadonnées d’un bucket). Définissez des seuils pour les temps de réponse et les taux d’erreur. Exemple de script BASH simple qui teste l’échange et l’accès :
#!/bin/bash
# exchange-and-test.sh
EXTERNAL_TOKEN="$1"
PROJECT_NUMBER="$2"
POOL="my-pool"
PROVIDER="my-oidc-provider"
RESPONSE=$(curl -s -X POST https://sts.googleapis.com/v1/token
-H "Content-Type: application/x-www-form-urlencoded"
-d "grant_type=urn:ietf:params:oauth:grant-type:token-exchange&subject_token_type=urn:ietf:params:oauth:token-type:jwt&subject_token=${EXTERNAL_TOKEN}&requested_token_type=urn:ietf:params:oauth:token-type:access_token&audience=//iam.googleapis.com/projects/${PROJECT_NUMBER}/locations/global/workloadIdentityPools/${POOL}/providers/${PROVIDER}&scope=https://www.googleapis.com/auth/cloud-platform")
ACCESS_TOKEN=$(echo "$RESPONSE" | jq -r .access_token)
if [ -z "$ACCESS_TOKEN" ] || [ "$ACCESS_TOKEN" == "null" ]; then
echo "Token exchange failed: $RESPONSE" >&2
exit 2
fi
# Test: list buckets (minimal permission vorausgesetzt)
curl -s -H "Authorization: Bearer ${ACCESS_TOKEN}"
"https://storage.googleapis.com/storage/v1/b?project=PROJECT_ID" | jq .
Surveillance, quotas et limites de taux STS
Tenez compte des quotas de l’API STS : des taux d’échange élevés (p. ex. de nombreux petits jobs CI) peuvent atteindre des limites. Surveillez les taux d’erreur des API Google et configurez le backoff/retry côté client. De plus, configurez des alarmes pour des augmentations inhabituelles d’impersonations ou d’échanges de jetons.
# Beispiel: einfache Log‑Abfrage nach STS Exchanges
gcloud logging read 'protoPayload.methodName="google.iam.sts.v1.Sts.Exchange"' --project=PROJECT_ID --limit=50
Rotation du JWKS et stabilité de l’IdP
Les rotations JWKS chez l’IdP sont une cause fréquente d’incidents : une nouvelle paire de clés est publiée, mais les clients mettent en cache les anciennes clés. Vérifiez la disponibilité du endpoint JWKS, le TTL de cache de vos clients et coordonnez les rotations. Une phase de test avant la mise en production évite des pannes surprises.
Pratiques d’audit et de forensique
L’audit est particulièrement important avec WIF car les tokens éphémères n’apparaissent pas dans les inventaires. Activez au minimum :
- Cloud Audit Logs : Admin Activity (modifications), Data Access (accès API, activation optionnelle), System Event Logs.
- Événements STS et d’usurpation : ils montrent les échanges de tokens et qui s’est fait passer pour un service account.
- Export vers BigQuery pour des analyses long terme et des requêtes forensiques.
Exemple : requête BigQuery pour les événements d’échange
-- Recherche des échanges de tokens et des événements d'usurpation
SELECT
protopayload_auditlog.authenticationInfo.principalEmail AS principal,
timestamp,
protopayload_auditlog.methodName AS method,
resource.labels.project_id AS project_id
FROM `PROJECT_ID.logging_dataset.cloudaudit_googleapis_com_activity_*`
WHERE protopayload_auditlog.methodName LIKE "%workloadIdentityPools%"
OR protopayload_auditlog.methodName LIKE "%Sts.Exchange%"
ORDER BY timestamp DESC
LIMIT 100;
Utilisez ces requêtes aussi pour des alertes automatiques (p. ex. principals inattendus ou taux élevés).
Spécifiquement pour l’exploitation de Zammad
Pour les installations Zammad qui utilisent GCS ou Pub/Sub, les points suivants sont recommandés : limitez les rôles aux actions strictement nécessaires (p. ex. roles/storage.objectCreator au lieu d’un rôle d’administration complet), instrumentez les flux d’upload de sorte que chaque upload génère un événement dans les logs d’audit, et effectuez des contrôles d’intégrité réguliers de la liste d’objets en la comparant aux logs d’audit pour détecter les uploads perdus ou non autorisés. Les configurations Zammad avec des backends de stockage externes doivent disposer de vues de monitoring dédiées afin que les erreurs d’upload, les erreurs d’authentification ou les réponses Permission‑Denied soient immédiatement visibles.
Conception des permissions : permissions minimales et modèle de rôles
Une introduction WIF stable échoue souvent à cause de rôles trop larges. Travaillez avec un modèle de rôles qui supporte les principes suivants : Least Privilege (principe du moindre privilège), Segregation (séparation des rôles lecture/écriture/audit), et Contextual Binding (accès uniquement si les claims sont corrects). Exemples :
- roles/storage.objectViewer : pour les fonctions de lecture
- roles/storage.objectCreator : pour les jobs d’upload
- Rôle personnalisé avec exactement les méthodes d’API requises, si les rôles prédéfinis sont trop larges
Contrôlez chaque rôle via une revue des droits IAM : quelles méthodes d’API sont réellement nécessaires ? Supprimez tout ce qui n’est pas strictement requis.
Migration des clés de compte de service : plan d’abandon par étapes
Élaborez une voie de migration graduelle plutôt qu’une coupure brutale. Phases typiques :
- Inventaire : quels services utilisent des clés de compte de service ? Utilisez le logging et des scans de gestion des secrets.
- Exploitation parallèle : implémentez l’accès WIF en parallèle aux clés existantes ; utilisez des feature flags ou des overrides de configuration.
- Exécution de test : tests proches de la production avec shadow‑traffic ou projets de test.
- Retrait progressif : rotation et révocation des clés après des tests réussis, suppression des clés dans Secret Manager.
Important : conservez une option de restauration éprouvée (p. ex. une clé recréée temporairement et strictement limitée) en cas de panne imprévue, documentée et vérifiable en audit.
Créer une clé d’urgence de manière sécurisée et la supprimer ensuite
Uniquement en cas d’urgence réelle : créez la clé, stockez-la chiffrée et supprimez-la immédiatement après la RESTauration. Exemple :
# Erzeuge temporären SA‑Key und speichere in Secret Manager
gcloud iam service-accounts keys create /tmp/temp-key.json
--iam-account=my-app-sa@PROJECT_ID.iam.gserviceaccount.com
# Upload in Secret Manager (verschlüsselt durch KMS)
gcloud secrets create emergency-sa-key --data-file=/tmp/temp-key.json --replication-policy="automatic"
# Nach Wiederherstellung: löschen
rm /tmp/temp-key.json
gcloud secrets delete emergency-sa-key --quiet
Vérifications pratiques pour le dépannage
Étapes de vérification systématiques en cas d’échec du Token‑Exchange :
- Validation JWT : Issuer (iss), Audience (aud), exp/nbf. Utilisez jwt‑inspektor ou des vérifications basées sur jq.
- Accessibilité du JWKS : curl > status, vérifiez les Key IDs (kid).
- Décalage NTP : ntpq -p ou chronyc tracking.
- IAM‑Binding : vérifiez que le principalSet est correctement référencé (PROJECT_NUMBER, Pool, Provider, Attribute).
- Cloud Audit Logs : recherchez des entrées Sts.Exchange et des messages d’erreur.
# JWKS Check
curl -s https://login.microsoftonline.com/TENANT_ID/discovery/v2.0/keys | jq '.keys[] | {kid, kty, use}'
# NTP check (chrony)
chronyc tracking
# Check Sts.Exchange failures in logs
gcloud logging read 'protoPayload.methodName:"Sts.Exchange" AND severity>=ERROR' --project=PROJECT_ID --limit=50
Stratégie de repli (technique et organisationnelle)
Définissez des procédures d’urgence claires et testées : génération temporaire de clés et gestion contrôlée des secrets (Secret Manager), Provider secondaires dans les pools, ainsi que rollbacks documentés vers les mécanismes d’authentification précédents. Chaque cas d’exception doit être enregistré, limité dans le temps et audité après clôture. Sur le plan organisationnel, un Incident‑Owner doit être désigné et un plan de communication clair doit exister pour informer les équipes concernées et décrire les mesures de révocation.
Actions concrètes pour le déploiement en production
- Tests d’Exchange automatisés dans la CI avec mécanismes d’alerte.
- Monitoring du JWKS et coordination des rotations avec les opérateurs IdP.
- Export de tous les logs pertinents (Audit, STS, Impersonation) vers un BigQuery‑Dataset sécurisé.
- Examens IAM réguliers et utilisation de Custom Roles plutôt que de rôles larges (par ex. roles/editor).
- Documenter et tester le processus de clé d’urgence.
Conclusion
GCP Workload Identity Federation est une méthode efficace et sécurisée pour permettre à des workloads hétérogènes d’accéder à GCP sans clés. L’effort opérationnel porte sur les attributs/conditions fins, la stabilité du JWKS, la surveillance des quotas STS et une configuration d’audit robuste. Pour les intégrations Zammad et les runners CI/CD hors de GCP, WIF offre une alternative maintenable aux clés — à condition que tests, monitoring et plans de repli soient prévus dès le départ. Avec un plan de migration gradué, des rôles clairs et des runbooks vérifiables, vous réduisez les risques et établissez un processus auditable et reproductible pour l’accès sans clé.
Aperçu succinct : To‑Dos indispensables
- Test : exécuter automatiquement le Token Exchange depuis l’environnement cible.
- Monitoring : surveiller les taux STS, les événements d’impersonation et la disponibilité du JWKS.
- Audit : exporter les logs, préparer des requêtes BigQuery, configurer des alertes.
- Sécurité : rôles IAM minimaux, RESTrictions Audience/Claim, revue IAM régulière.
- Fallback : clés de compte de service à courte durée uniquement en cas d’urgence, puis les faire pivoter et supprimer.
Exploitation & recommandations d’architecture
Sur le terrain, on met souvent en place un proxy d’échange de jetons local : il réduit les appels STS directs, mutualise les caches JWKS, implémente la logique de backoff/circuit‑breaker et fournit des métriques centralisées. Veillez à ce que le cache respecte strictement la TTL des tokens : des tokens locaux prolongés créent des fenêtres de révocation incontrôlables. Placez le proxy dans un segment réseau sécurisé avec un egress restreint et limitez fortement ses droits. Consignez l’ID du principal d’origine comme champ de trace distinct, afin que les requêtes d’audit puissent corréler les échanges avec des accès API ultérieurs. Définissez des SLA pour la disponibilité de l’échange et un fallback testé et limité dans le temps (clé fortement restreinte, rotation automatique). Ainsi, les intégrations dans un logiciel d’entreprise sur mesure peuvent être exploitées de manière stable et maîtrisée vis‑à‑vis des risques.
Les identifiants à durée de vie courte (Short‑Lived Credentials) sont également importants pour ce sujet. Cet article replace ces aspects de façon claire et montre ce qui compte au quotidien.