Dans mon article précédent sur l’expiration des App Registrations sur Azure, nous avions mis en place un suivi automatisé des secrets applicatifs. Sur Google Cloud Platform (GCP), le problème historique est encore plus critique : contrairement aux secrets Azure qui expirent par défaut au bout de 1 ou 2 ans, une clé JSON téléchargée depuis un Service Account GCP possède par défaut une date d’expiration fixée à l’année 9999 !

Si ce fichier credentials.json fuite dans un dépôt Git ou sur le poste d’un développeur, l’attaquant dispose d’un accès permanent à votre projet GCP.

1. L’approche 2021 : inventorier et alerter sur les clés JSON de plus de 90 jours

La première étape d’hygiène consiste à recenser toutes les clés gérées par l’utilisateur (USER_managed) à l’échelle de l’organisation via Cloud Asset Inventory ou un job d’audit, et à exposer la métrique dans Cloud Monitoring / Grafana :

# Lister toutes les clés de Service Account créées manuellement sur un projet GCP
for sa in $(gcloud iam service-accounts list --format="value(email)"); do
  gcloud iam service-accounts keys list --iam-account="$sa" \
    --managed-by=user \
    --format="table(name.basename(), validAfterTime, validBeforeTime)"
done

Dans Cloud Monitoring, la métrique native iam.googleapis.com/service_account/key/authn_events_count permet également d’identifier les vieilles clés qui sont réellement encore utilisées en production avant de les révoquer.

2. MàJ 2026 Zéro clé JSON grâce à Workload Identity Federation (WIF)

En 2026, télécharger un fichier JSON de clé privée de Service Account est devenu un anti-pattern formellement bloqué par la contrainte d’Organization Policy : constraints/iam.disableServiceAccountKeyCreation !

À la place, Workload Identity Federation (WIF) permet à n’importe quelle charge de travail externe (pipeline GitHub Actions, GitLab, cluster Kubernetes on-premise, VM AWS ou Azure) d’obtenir un jeton GCP à durée de vie courte (1 heure) sans jamais détenir de clé statique :

Configuration déclarative Terraform en 30 lignes (Sans Secret)

Voici comment autoriser uniquement la branche main d’un dépôt GitHub ou d’un émetteur OIDC interne à endosser un rôle GCP :

resource "google_iam_workload_identity_pool" "prod_pool" {
  workload_identity_pool_id = "homelab-oidc-pool"
  display_name              = "Pool OIDC Zero-Secret"
}

resource "google_iam_workload_identity_pool_provider" "github_provider" {
  workload_identity_pool_id          = google_iam_workload_identity_pool.prod_pool.workload_identity_pool_id
  workload_identity_pool_provider_id = "github-oidc"
  issuer_uri                         = "https://token.actions.githubusercontent.com"

  attribute_mapping = {
    "google.subject"       = "assertion.sub"
    "attribute.repository" = "assertion.repository"
    "attribute.ref"        = "assertion.ref"
  }

  # Garde-fou Zero-Trust : filtre cryptographique à l'entrée du pool
  attribute_condition = "assertion.repository == 'ravindrajob/InfraAtHome' && assertion.ref == 'refs/heads/main'"
}

Pourquoi WIF change radicalement la posture de sécurité

• Suppression totale du vecteur de fuite de clé .json : il n’existe plus aucun secret longue durée à voler ou à faire tourner ;
• Moindre privilège granulaire par attribut OIDC : la condition IAM vérifie cryptographiquement l’identité du dépôt, de la branche ou du namespace Kubernetes appelant ;
• En 2026 (Direct Resource Access) : WIF n’a même plus besoin d’impersonner un Service Account intermédiaire (Service Account Impersonation) : vous pouvez accorder directement les permissions IAM au principalSet://iam.googleapis.com/projects/.../workloadIdentityPools/... !