IAM GCP : utilisateurs, rôles, service accounts, MFA — tutoriel ACE 2026

Maîtriser IAM Google Cloud — utilisateurs, groupes, rôles basiques et prédéfinis, rôles custom, service accounts et MFA — pour passer le domaine 4 de l’examen ACE et sécuriser correctement votre lab. Tutoriel pas-à-pas du cluster Associate Cloud Engineer (ACE).

📍 Article principal du cluster : Devenir Google Cloud Associate Cloud Engineer (ACE) — Guide complet 2026
Cet article fait partie du cluster « GCP ACE ». Pour la vue d’ensemble de la certification, lire d’abord le pilier.

Introduction

Identity and Access Management — IAM — est le domaine où tombent une bonne moitié des questions de l’examen ACE. Ce n’est pas un hasard : c’est aussi le domaine où les erreurs réelles ont les conséquences les plus dramatiques en production. Donner par mégarde le rôle Owner à un service account exposé sur Internet, ou laisser une clé JSON traîner sur un dépôt GitHub public, et voilà 12 000 USD de minage de crypto sur votre compte en deux jours. Ce tutoriel pose les fondations pratiques d’IAM Google Cloud : les trois types de rôles, l’héritage de permissions, la création propre d’un service account, et la migration recommandée vers Workload Identity Federation pour éviter les clés JSON. Tout est validé sur la documentation officielle Google Cloud à fin avril 2026.

Prérequis

• Compte Google Cloud Free Trial actif (cf. Créer un compte GCP gratuit 300 USD sans risque de facturation).
• Projet GCP créé et lié au compte de facturation, par exemple lab-ace-2026.
• gcloud CLI installé localement, ou utilisation directe de Cloud Shell.
• Une deuxième adresse Gmail de test pour expérimenter les invitations utilisateur.
• Niveau attendu : débutant en cloud, à l’aise avec un terminal Linux.
• Temps estimé : 60 à 90 minutes pour suivre toutes les étapes avec lab.

Étape 1 — Comprendre les trois éléments fondamentaux

Avant de cliquer sur quoi que ce soit, fixez les trois concepts qui structurent toutes les questions IAM de l’examen ACE. La documentation officielle les nomme Principal, Role et Resource. Un principal est l’identité à qui on accorde des permissions : un utilisateur Google (alice@example.com), un groupe (devops@example.com), un domaine (example.com), un service account (sa-app@projet.iam.gserviceaccount.com), un identifiant Workforce Identity Federation, ou la valeur spéciale allUsers pour Internet entier. Un rôle est une collection de permissions élémentaires au format service.resource.action (par exemple compute.instances.create ou storage.objects.get). Une ressource est un objet Google Cloud sur lequel on attribue le rôle : un projet, un bucket, une VM, voire un objet précis dans un bucket.

Ce que vous attribuez réellement, c’est un binding — une association principal + role + ressource. Un binding peut être restreint par une IAM condition : par exemple « Alice a le rôle Storage Object Viewer sur le bucket logs-prod uniquement de 8h à 20h les jours ouvrés ». Comprendre cette mécanique évite de répondre à côté à 90 % des questions IAM piégées de l’examen.

Étape 2 — Maîtriser les trois types de rôles

Google Cloud distingue officiellement trois types de rôles, et l’examen attend que vous sachiez les distinguer parfaitement. La doc officielle utilise les termes anglais ci-dessous — apprenez-les tels quels.

Basic roles (anciennement « primitive roles » dans la documentation legacy). Quatre rôles très larges, hérités du premier modèle IAM de GCP : roles/owner, roles/editor, roles/viewer, roles/browser. Ils donnent un accès cross-service à toutes les ressources d’un projet. Google déconseille leur usage en production : ils violent le principe de moindre privilège. À l’examen, retenez que les basic roles existent mais ne sont jamais la bonne réponse à une question « quel rôle accorderiez-vous ? ».

Predefined roles. Plus de mille rôles maintenus par Google, ciblés par service et par fonction. Format roles/<service>.<function> : roles/compute.instanceAdmin, roles/storage.objectViewer, roles/cloudsql.editor. C’est la bonne réponse 80 % du temps à l’examen. Vous devez connaître par cœur une vingtaine de rôles classiques : Compute Admin, Compute Instance Admin (v1), Storage Admin, Storage Object Admin, Storage Object Viewer, BigQuery Admin, BigQuery Data Viewer, IAM Security Admin, Logs Viewer, Monitoring Viewer.

Custom roles. Vous les créez à partir d’une liste précise de permissions. Utiles quand aucun rôle prédéfini ne correspond exactement et qu’il faut respecter le moindre privilège. Limites officielles : un custom role peut contenir jusqu’à 3000 permissions et est attaché à un projet ou à une organisation, pas à un dossier.

Étape 3 — Comprendre la hiérarchie et l’héritage

Les permissions IAM s’héritent de haut en bas dans la hiérarchie organisation → dossier → projet → ressource. C’est un point régulièrement testé à l’examen. Une question type : « Alice a le rôle Editor sur le dossier ProductionFolder ; quel est son niveau d’accès sur le projet shop-front, enfant du dossier ProductionFolder ? ». Réponse : Editor sur shop-front, par héritage. Le rôle attribué au niveau supérieur s’applique à tous les enfants sauf si une politique Deny bloque explicitement l’action plus bas.

Les IAM Deny policies sont une mécanique récente qui permet de bloquer explicitement des permissions, indépendamment des bindings d’allow. Elles écrasent toujours les allows, suivant la règle « deny wins ». Le Principal Access Boundary est un autre mécanisme avancé qui plafonne les permissions maximales d’un principal, peu importe les bindings qui lui sont attribués. Ces deux mécanismes apparaissent rarement à l’examen ACE mais peuvent être mentionnés dans une question piège — savoir qu’ils existent suffit.

Étape 4 — Inviter un utilisateur et lui assigner un rôle

Mettons les concepts en pratique. Vous allez inviter une seconde adresse Gmail (votre adresse de test) à votre projet et lui donner le rôle Storage Object Viewer pour qu’elle puisse lister les buckets sans pouvoir les modifier.

# Recuperer l'email cible (ex: alice.test@gmail.com)
EMAIL="alice.test@gmail.com"
PROJECT="lab-ace-2026"

# Ajouter un binding au niveau du projet
gcloud projects add-iam-policy-binding $PROJECT \
  --member="user:$EMAIL" \
  --role="roles/storage.objectViewer"

# Verifier le binding
gcloud projects get-iam-policy $PROJECT \
  --flatten="bindings[].members" \
  --filter="bindings.members:$EMAIL"

L’utilisateur invité reçoit un email d’invitation. Une fois acceptée, il peut se connecter à console.cloud.google.com, sélectionner votre projet, et constater qu’il voit la liste des buckets mais ne peut ni lire les objets ni en créer. Pour lire les objets, il faudrait roles/storage.objectViewer au niveau du bucket et roles/storage.legacyObjectReader ou un rôle équivalent. Pour retirer le binding, utilisez gcloud projects remove-iam-policy-binding avec les mêmes arguments.

Étape 5 — Créer un rôle custom adapté à un cas concret

Imaginons que vous voulez donner à un développeur la possibilité de redémarrer les VMs Compute Engine mais pas d’en créer ni d’en supprimer — un cas typique d’opérateur de support niveau 1. Aucun rôle prédéfini ne correspond exactement. C’est le moment d’un custom role.

# Definir la liste des permissions necessaires
cat > /tmp/role-restart.yaml <<'EOF'
title: "VM Restarter"
description: "Peut redemarrer une VM Compute Engine, sans creer ni supprimer."
stage: "GA"
includedPermissions:
  - compute.instances.start
  - compute.instances.stop
  - compute.instances.reset
  - compute.instances.get
  - compute.instances.list
  - compute.zones.get
  - compute.zones.list
EOF

# Creer le custom role au niveau du projet
gcloud iam roles create vmRestarter \
  --project=lab-ace-2026 \
  --file=/tmp/role-restart.yaml

# Attribuer le custom role a un utilisateur
gcloud projects add-iam-policy-binding lab-ace-2026 \
  --member="user:devops@example.com" \
  --role="projects/lab-ace-2026/roles/vmRestarter"

Le rôle est désormais disponible dans le projet. Il apparaîtra dans la console IAM avec le titre « VM Restarter ». Notez le champ stage qui peut prendre les valeurs ALPHA, BETA, GA ou DISABLED — utile pour piloter le cycle de vie d’un rôle custom dans un contexte d’organisation. Pour mettre à jour la liste des permissions, modifiez le YAML et utilisez gcloud iam roles update vmRestarter --project=lab-ace-2026 --file=/tmp/role-restart.yaml.

Étape 6 — Créer un service account user-managed

Les service accounts sont des comptes spéciaux destinés à être utilisés par des applications, pas par des humains. La doc officielle distingue trois types : user-managed (que vous créez et gérez), default (créés automatiquement par certains services, comme le Compute Engine default service account), et service agents (créés par Google pour son propre compte, comme l’agent Cloud Build).

# Creer un service account user-managed pour une app analytique
gcloud iam service-accounts create sa-analytics-reader \
  --display-name="SA Analytics Reader" \
  --description="Lit les buckets analytics, ecrit dans BigQuery" \
  --project=lab-ace-2026

# Recuperer l'email complet du SA
SA_EMAIL="sa-analytics-reader@lab-ace-2026.iam.gserviceaccount.com"

# Lui donner deux roles predefinis precis
gcloud projects add-iam-policy-binding lab-ace-2026 \
  --member="serviceAccount:$SA_EMAIL" \
  --role="roles/storage.objectViewer"

gcloud projects add-iam-policy-binding lab-ace-2026 \
  --member="serviceAccount:$SA_EMAIL" \
  --role="roles/bigquery.dataEditor"

Le service account est créé. Vous pouvez le lister dans IAM & admin → Service Accounts. Notez son email exact : c’est cette identité que vous utiliserez dans toutes les APIs et configurations qui doivent agir au nom de l’application. Important : Google recommande explicitement de ne pas générer de clé JSON sauf nécessité absolue, et de privilégier des alternatives plus sûres détaillées à l’étape suivante.

Étape 7 — Préférer les alternatives aux clés JSON

La documentation officielle Google Cloud le formule ainsi : Service account keys are a security risk if not managed correctly. Choose a more secure alternative whenever possible. Les clés JSON sont des credentials persistants exfiltrables : un commit accidentel sur GitHub, une fuite de logs, et c’est l’incident. Les alternatives officielles sont au nombre de quatre.

Attached service accounts. Au lieu de générer une clé, attachez le service account directement à la ressource qui doit agir. Une VM Compute Engine, un job Cloud Run, un cluster GKE peuvent tous porter une identité de service account et obtenir des credentials de courte durée automatiquement via le metadata server.

# Attacher le SA a une VM lors de la creation
gcloud compute instances create app-vm \
  --zone=europe-west9-a \
  --machine-type=e2-small \
  --service-account=$SA_EMAIL \
  --scopes=https://www.googleapis.com/auth/cloud-platform

Workload Identity Federation. Pour des charges de travail externes à GCP — typiquement un pipeline GitHub Actions ou un cluster Kubernetes auto-hébergé — Workload Identity Federation permet d’authentifier sans clé JSON, en échangeant un token externe (OIDC, SAML) contre des credentials Google Cloud de courte durée. C’est la méthode recommandée pour tout CI/CD moderne.

Workload Identity pour GKE. Variante spécifique aux clusters Google Kubernetes Engine. Vous mappez un Kubernetes Service Account à un Google Service Account ; les pods obtiennent les credentials sans embarquer de clé. C’est le standard pour toutes les nouvelles applications GKE.

Short-lived credentials. Vous pouvez générer des tokens d’accès qui expirent en quelques heures via la commande gcloud auth print-access-token ou l’API IAM Credentials, sans jamais matérialiser un fichier JSON.

Étape 8 — Activer la vérification 2 étapes (MFA)

La protection MFA n’est pas configurable au niveau du projet GCP — c’est une protection du compte Google qui s’active sur myaccount.google.com. Google la requiert obligatoirement depuis 2024 pour tous les comptes ayant accès à Google Cloud, mais cela vaut quand même la peine de la vérifier explicitement.

# Page de gestion de la securite du compte Google
https://myaccount.google.com/security

# Activer la verification 2 etapes (2-Step Verification)
# Methodes recommandees, par ordre de robustesse :
# 1. Cle de securite physique YubiKey
# 2. Application Authenticator (Google Authenticator, 1Password, Authy)
# 3. Notifications Google sur smartphone
# 4. SMS (a eviter, vulnerable au SIM swapping)

Pour les organisations qui utilisent Cloud Identity ou Google Workspace, l’admin peut imposer la 2FA à tous les utilisateurs via les politiques de sécurité du domaine. C’est obligatoire pour tout accès au moindre projet sensible. Sur l’examen ACE, on attend que vous sachiez que la MFA est gérée au niveau du compte Google et non du projet GCP — un piège classique.

Étape 9 — Audit des permissions avec IAM Recommender

IAM Recommender est un service automatique inclus dans GCP qui analyse les permissions effectives de chaque principal sur les 90 derniers jours et propose de retirer celles qui n’ont jamais été utilisées. C’est un outil précieux à connaître pour l’examen et indispensable en production pour appliquer le moindre privilège dans la durée.

# Lister les recommandations IAM pour le projet
gcloud recommender recommendations list \
  --recommender=google.iam.policy.Recommender \
  --project=lab-ace-2026 \
  --location=global

# Detail d'une recommandation
gcloud recommender recommendations describe RECOMMENDATION_ID \
  --recommender=google.iam.policy.Recommender \
  --project=lab-ace-2026 \
  --location=global

Si IAM Recommender n’a pas encore généré de recommandations, c’est normal en début de lab — le service a besoin d’au moins quelques semaines de logs d’utilisation pour être pertinent. Sur un projet de production avec plusieurs mois d’historique, attendez-vous à des dizaines de recommandations utiles. Appliquer une recommandation revient à exécuter le binding modifié proposé.

Étape 10 — Cleanup

Comme toujours, retirez les ressources créées pour ne pas laisser de bindings ouverts qui pourraient devenir un problème de sécurité plus tard.

# Supprimer le service account
gcloud iam service-accounts delete $SA_EMAIL \
  --project=lab-ace-2026

# Desactiver le custom role (recommande avant suppression)
gcloud iam roles update vmRestarter \
  --project=lab-ace-2026 \
  --stage=DISABLED

# Supprimer le custom role definitivement (apres 7 jours)
gcloud iam roles delete vmRestarter \
  --project=lab-ace-2026

# Retirer un binding utilisateur
gcloud projects remove-iam-policy-binding lab-ace-2026 \
  --member="user:alice.test@gmail.com" \
  --role="roles/storage.objectViewer"

Note importante : Google recommande de désactiver les service accounts inutilisés plutôt que les supprimer immédiatement, car la suppression peut casser des dépendances cachées (logs anciens qui font référence à l’identité par exemple). Désactivez d’abord, attendez quelques jours qu’aucune erreur ne remonte, puis supprimez.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Comptes équipe distribuée. Pour une PME tech à Dakar ou Abidjan avec une équipe distribuée, créez un compte Cloud Identity gratuit (limité à 50 utilisateurs sur la version free) plutôt que de gérer des bindings sur des Gmail personnels. Cela permet de centraliser la 2FA et de désactiver d’un clic l’accès d’un collaborateur qui quitte l’entreprise.

Service accounts pour Wave/Orange Money intégrations. Si votre app sénégalaise reçoit des callbacks Wave Money et appelle Cloud Functions, utilisez un service account dédié sa-wave-callback avec uniquement la permission cloudfunctions.functions.invoke sur la fonction concernée. Pas de Editor, pas de Owner — moindre privilège strict.

Délégation aux étudiants en formation. Pour les centres de formation comme ITSkillsCenter qui font des labs en groupe, le pattern recommandé est : un projet par étudiant + un binding roles/editor au niveau projet pour l’étudiant + un budget alert à 50 USD par projet. Ainsi chacun peut casser son lab sans toucher aux autres.

Audit des permissions sortantes. Quand un consultant freelance termine sa mission, exécutez gcloud projects get-iam-policy pour lister tous les bindings le concernant et retirez-les avec remove-iam-policy-binding. À défaut, son accès reste actif indéfiniment et c’est une porte ouverte.

Tutoriels frères

• VPC GCP : subnets, firewall, Cloud NAT, peering — la sécurité réseau qui complète la sécurité d’identité.
• Compute Engine : déployer une VM Linux et Windows — la première VM, où vous attacherez votre service account.

Pour aller plus loin

• 🔝 Retour au pilier : Devenir Google Cloud Associate Cloud Engineer (ACE) — Guide complet 2026
• Documentation officielle IAM : cloud.google.com/iam/docs/overview
• Service accounts best practices : cloud.google.com/iam/docs/best-practices-service-accounts
• Workload Identity Federation : cloud.google.com/iam/docs/workload-identity-federation
• Suggestion suivante : VPC GCP — subnets, firewall, Cloud NAT, peering

FAQ

Quelle est la différence entre Owner et Editor ?
Owner inclut Editor + la capacité de modifier les bindings IAM et de gérer la facturation. Editor peut tout créer/modifier/supprimer dans le projet mais ne peut pas changer les permissions. À l’examen, Owner est presque toujours la mauvaise réponse — préférez Editor ou un rôle prédéfini ciblé.

Quand créer un custom role plutôt qu’utiliser un predefined ?
Quand aucun predefined ne correspond exactement à votre besoin de moindre privilège. Si un predefined existant donne 5 permissions dont vous n’avez besoin que de 3, et que les 2 supplémentaires sont risquées, créez un custom. Sinon, predefined.

Combien de service accounts peut-on créer par projet ?
Le quota par défaut est de 100 service accounts par projet. C’est augmentable sur demande au support. Pour un lab d’apprentissage, vous n’en aurez besoin que de 5-10.

Comment auditer qui a fait quoi sur le projet ?
Cloud Audit Logs trace toutes les actions IAM (Admin Activity logs activés par défaut). Filtrer dans Cloud Logging avec logName=~".*Activity" donne la liste des actions privilégiées. Couvert dans le tutoriel Cloud SQL + monitoring du cluster.

Workload Identity Federation marche-t-il avec GitHub Actions ?
Oui, c’est même un de ses cas d’usage les plus courants depuis 2022. Vous créez un Workload Identity Pool, un provider OIDC pour github.com, et vos workflows GitHub peuvent obtenir des credentials GCP de courte durée sans secret stocké. La doc Google Cloud fournit un tutoriel pas-à-pas dédié.

Le compte de facturation a-t-il son propre IAM séparé du projet ?
Oui. Les rôles Billing Account Administrator, Billing Account User et Billing Account Viewer s’attribuent au niveau du compte de facturation, pas du projet. Ils contrôlent qui peut lier ou délier un projet à ce compte de facturation, voir les factures, etc. C’est un point régulièrement testé à l’examen.

Mots-clés : IAM Google Cloud, service accounts GCP, Workload Identity Federation, custom role GCP, MFA Google Cloud, ACE certification IAM, predefined roles, basic roles, Cloud Identity Afrique