Fichiers de clés de compte de service vs jetons d'usurpation d'identité

La position officielle de Google sur les fichiers de clés de compte de service est d’utiliser Workload Identity Federation à la place. L’argument de sécurité est légitime, mais les contraintes pratiques du développement local et des workflows d’agents IA signifient que la recommandation ne s’applique pas toujours.

Ce que Google recommande et pourquoi

Workload Identity Federation (WIF) permet à un fournisseur d’identité externe de garantir votre workload afin que Google puisse émettre des identifiants à courte durée de vie sans fichier de clé statique. GitHub Actions OIDC est l’exemple canonique : quand un job CI s’exécute, GitHub affirme « ceci est le workflow X du dépôt Y », Google vérifie cette affirmation, et émet un token d’accès temporaire.

Les avantages de sécurité sont réels :

Pas de fichier de clé statique sur le disque qui peut être volé, accidentellement commité, ou exposé via un log
Les tokens à courte durée de vie limitent la fenêtre d’exposition si des identifiants sont capturés
Les pistes d’audit montrent à la fois l’identité humaine et l’identité du compte de service
La révocation est immédiate — pas besoin de rotation de clé

WIF fonctionne bien en CI/CD. Il ne fonctionne pas du tout pour le développement local car il n’y a pas de fournisseur d’identité externe avec lequel fédérer. Un laptop de développeur qui fait tourner dbt n’est pas GitHub Actions. Il n’y a pas d’endpoint OIDC. La recommandation « pas de fichiers de clés » est largement une recommandation CI/CD qui est appliquée universellement.

Usurpation d’identité de compte de service : le juste milieu

L’usurpation d’identité de compte de service est ce qui se rapproche le plus de WIF pour le développement local :

gcloud auth print-access-token \
  --impersonate-service-account=dbt-runner@acme-prod.iam.gserviceaccount.com

Cette commande génère un token d’accès de 60 minutes. Pas de fichier de clé sur le disque. La piste d’audit montre votre identité personnelle (vous@exemple.com) qui usurpe l’identité du compte de service. Les équipes sécurité apprécient cela car :

Pas d’identifiant statique à voler — le token expire
Piste d’audit claire liant les identités humaine et de compte de service
Révocation individuelle : si vous quittez l’organisation, votre capacité d’usurpation d’identité disparaît

Les contraintes pour les workflows d’agents :

Les tokens expirent. Un token de 60 minutes convient pour un run dbt. C’est un problème pour une session Claude Code de plusieurs heures ou un pipeline automatisé qui tourne toute la nuit. Vous devez rafraîchir les tokens, ce qui nécessite votre identité interactive — quelque chose que les agents ne peuvent pas faire seuls.

Surcoût de configuration. Le compte utilisateur a besoin de roles/iam.serviceAccountTokenCreator sur le compte de service cible. C’est une attribution IAM supplémentaire à gérer.

# S'accorder la permission d'usurper l'identité du compte de service
gcloud iam service-accounts add-iam-policy-binding \
  dbt-runner@acme-prod.iam.gserviceaccount.com \
  --member="user:vous@exemple.com" \
  --role="roles/iam.serviceAccountTokenCreator"

Fichiers de clés : le choix pragmatique

Les fichiers de clés JSON de comptes de service restent l’option la plus fiable pour le développement local et les sessions d’agents IA :

# Créer et télécharger une clé
gcloud iam service-accounts keys create ~/.gcp-keys/acme-dbt-runner.json \
  --iam-account=dbt-runner@acme-prod.iam.gserviceaccount.com

Défini via variable d’environnement, tout outil qui respecte les ADC le récupère :

export GOOGLE_APPLICATION_CREDENTIALS="$HOME/.gcp-keys/acme-dbt-runner.json"

Les fichiers de clés fonctionnent dans tous les scénarios — sessions interactives, environnements non-interactifs, agents IA, conteneurs sandboxés. Ils n’expirent pas en milieu de session. Il n’y a pas de problème de rafraîchissement.

Les risques de sécurité sont réels et nécessitent une gestion active :

Les fichiers de clés sont des identifiants statiques. S’ils sont volés, ils fonctionnent jusqu’à la révocation. Une clé compromise peut s’authentifier en tant que compte de service depuis n’importe où.

Les agents IA enregistrent leur activité. Un log de conversation mal épuré avec Claude Code pourrait exposer un chemin de clé ou même le contenu de la clé si vous discutez d’identifiants pendant une session. C’est la surface d’attaque spécifique qui rend les tokens à courte durée de vie préférables pour les travaux sensibles.

Les clés peuvent être commitées accidentellement. Malgré les entrées .gitignore, les fichiers de clés finissent dans des dépôts. La détection automatisée (GitGuardian, GitHub secret scanning) aide mais n’élimine pas le risque.

Hygiène pragmatique des clés

Si vous utilisez des fichiers de clés de comptes de service — et pour la plupart des workflows de consulting, vous le ferez — faites-le avec discipline :

Un compte de service par projet client. Créé à l’intérieur du projet du client, pas dans un projet partagé. Si une clé est compromise, elle ne peut accéder qu’aux ressources de ce client.

# Créer dans le projet client, pas un projet d'infrastructure partagé
gcloud iam service-accounts create dbt-runner \
  --display-name="dbt Runner" \
  --project=acme-analytics-prod

Rôles minimums requis. Pour dbt sur BigQuery : roles/bigquery.user (exécuter des requêtes) et roles/bigquery.dataEditor (créer des tables dans les datasets cibles). Rien de plus large.

gcloud projects add-iam-policy-binding acme-analytics-prod \
  --member="serviceAccount:dbt-runner@acme-analytics-prod.iam.gserviceaccount.com" \
  --role="roles/bigquery.user"

gcloud projects add-iam-policy-binding acme-analytics-prod \
  --member="serviceAccount:dbt-runner@acme-analytics-prod.iam.gserviceaccount.com" \
  --role="roles/bigquery.dataEditor"

Rotation à 90 jours. Nouvelle clé, révocation de l’ancienne, mise à jour des références. La ressource time_rotating de Terraform peut automatiser cela.

Permissions du système de fichiers. Les fichiers de clés ne doivent pas être lisibles par tous.

chmod 600 ~/.gcp-keys/acme-dbt-runner.json

Exclus de la synchronisation cloud. ~/.gcp-keys/ ne doit pas être dans iCloud, Google Drive, Dropbox ou tout autre service de synchronisation. Et explicitement dans .gitignore pour tout projet qui référence des chemins de clés.

Évaluation

Pour les travaux de production sensibles où les identifiants sont activement discutés (par exemple, les sessions de débogage), les jetons d’usurpation d’identité sont préférables : pas de fichier statique sur le disque et une piste d’audit claire.

Pour les builds dbt quotidiens sur plusieurs projets clients, y compris les sessions d’agents IA qui ont besoin d’une authentification persistante, les fichiers de clés de comptes de service avec une bonne hygiène sont le choix le plus pratique. La gestion du rafraîchissement de tokens sur plusieurs sessions d’agents de longue durée introduit une complexité opérationnelle qui surpasse généralement l’amélioration de sécurité pour la plupart des workflows d’analytics engineering.