Le compte de service partagé est l’une des formes les plus courantes de dette IAM dans les plateformes de données. Un seul etl-service-account@project.iam.gserviceaccount.com exécute des DAGs Airflow, des Cloud Run Jobs, des requêtes planifiées, et peut-être un cron job sur une instance Compute Engine que personne ne se souvient avoir créée. Quand quelque chose se casse ou que les coûts augmentent, vous ne pouvez pas déterminer quel workload en est la cause. Quand vous devez faire tourner les credentials, vous risquez de tout casser simultanément.
La solution est un compte de service par workload, nommé pour être auto-documenté dans les logs.
La convention de nommage
{préfixe-plateforme}-{nom-workload}@project.iam.gserviceaccount.comPréfixes de plateforme par environnement de calcul :
crj— Cloud Run Jobcmp— Cloud Composer (Airflow)wlif— Workload Identity Federation (auth sans clé pour les systèmes externes)crf— Cloud Run Function (anciennement Cloud Functions)gce— Compute Enginegke— Workload GKE
Exemples :
crj-dbt-daily@project.iam.gserviceaccount.comcrj-dbt-hourly@project.iam.gserviceaccount.comcmp-extraction-dag@project.iam.gserviceaccount.comcmp-transformation-dag@project.iam.gserviceaccount.comwlif-github-actions@project.iam.gserviceaccount.comwlif-terraform-ci@project.iam.gserviceaccount.comQuand vous voyez une requête apparaître inopinément dans INFORMATION_SCHEMA.JOBS_BY_PROJECT, le nom du compte de service vous indique immédiatement quel workload l’a exécutée et sur quelle plateforme de calcul elle se trouve. Vous pouvez aller directement à la console Cloud Run Job, la liste des DAGs Composer, ou le workflow GitHub Actions — sans cross-référencement nécessaire.
Pourquoi le préfixe de plateforme est important
Les comptes de service apparaissent dans les logs, les rapports de coûts, et les pistes d’audit sans autre contexte. Sans le préfixe, dbt-daily et dbt-hourly se ressemblent. Avec le préfixe crj-, vous savez que les deux vivent dans Cloud Run Jobs et où chercher lors d’une investigation.
Le préfixe crée également des regroupements naturels dans les listes alphabétiques. Tous les comptes de service Cloud Composer se regroupent ensemble. Tous les comptes Workload Identity Federation se regroupent ensemble. Le tri par email de compte de service dans une vue de la console GCP devient significatif plutôt qu’arbitraire.
Restriction minimale des permissions
Chaque compte de service ne reçoit que ce dont son workload a besoin. Pour un Cloud Run Job qui exécute dbt quotidiennement :
# Créer le compte de servicegcloud iam service-accounts create crj-dbt-daily \ --display-name="Cloud Run Job - exécution dbt quotidienne" \ --project=VOTRE_PROJECT_ID
# Accorder dataEditor sur les datasets où dbt écritgcloud projects add-iam-policy-binding VOTRE_PROJECT_ID \ --member="serviceAccount:crj-dbt-daily@VOTRE_PROJECT_ID.iam.gserviceaccount.com" \ --role="roles/bigquery.dataEditor"
# Accorder jobUser pour exécuter des requêtesgcloud projects add-iam-policy-binding VOTRE_PROJECT_ID \ --member="serviceAccount:crj-dbt-daily@VOTRE_PROJECT_ID.iam.gserviceaccount.com" \ --role="roles/bigquery.jobUser"Pour un DAG Composer en lecture seule qui ne vérifie que le statut des jobs :
gcloud iam service-accounts create cmp-status-check \ --display-name="Composer - DAG de vérification du statut" \ --project=VOTRE_PROJECT_ID
# dataViewer uniquement — ce workload n'écrit jamaisgcloud projects add-iam-policy-binding VOTRE_PROJECT_ID \ --member="serviceAccount:cmp-status-check@VOTRE_PROJECT_ID.iam.gserviceaccount.com" \ --role="roles/bigquery.dataViewer"
gcloud projects add-iam-policy-binding VOTRE_PROJECT_ID \ --member="serviceAccount:cmp-status-check@VOTRE_PROJECT_ID.iam.gserviceaccount.com" \ --role="roles/bigquery.jobUser"Le principe : les workloads en lecture reçoivent dataViewer, les workloads en écriture reçoivent dataEditor, tous les workloads ont besoin de jobUser pour réellement exécuter des requêtes. N’accordez pas dataEditor aux workloads qui ne font que lire. L’audit finira par détecter les sur-permissions ; IAM Recommender le signalera. Mieux vaut commencer avec le bon périmètre.
Impersonation de compte de service pour le développement local
Les comptes de service par workload résolvent également le problème des credentials en développement local sans distribuer des clés. Accordez aux ingénieurs la capacité d’usurper l’identité du compte de service concerné :
gcloud iam service-accounts add-iam-policy-binding \ crj-dbt-daily@project.iam.gserviceaccount.com \ --member="user:ingenieur@votredomaine.com" \ --role="roles/iam.serviceAccountTokenCreator"L’ingénieur s’authentifie localement avec sa propre identité et usurpe l’identité du compte de service :
gcloud auth application-default login \ --impersonate-service-account=crj-dbt-daily@project.iam.gserviceaccount.com
dbt runLe mécanisme GCP Application Default Credentials gère l’échange de credentials. Le journal d’audit enregistre à la fois l’identité humaine et le compte de service qu’elle a usurpé. Pas de clés à faire tourner, pas de credentials à fuiter, et vous savez exactement qui a exécuté quoi et sous quel compte.
Migrer depuis un compte partagé
Quand vous divisez un compte de service partagé existant en comptes par workload :
- Lancez la requête de détection de compte de service partagé pour comprendre ce que le compte fait réellement
- Créez de nouveaux comptes de service pour chaque workload, limités à ce que l’historique de requêtes de ce workload montre qu’il accède réellement
- Mettez à jour les configurations de workload une par une (commencez par les workloads les moins risqués et les moins sollicités)
- Surveillez
INFORMATION_SCHEMA.JOBS_BY_PROJECTpour confirmer que le nombre de jobs de l’ancien compte tombe à zéro - Désactivez l’ancien compte de service (ne le supprimez pas immédiatement — laissez une semaine pour confirmer que rien ne manque)
- Supprimez l’ancien compte une fois que vous êtes sûr que rien n’en dépend
N’essayez pas de tout diviser en même temps. Le compte partagé est partagé parce que c’était pratique ; défaire cette commodité nécessite un séquençage prudent.