abla.adem

Recent Notes

Gouvernance et gestion des identités GCP

5 min read

☁️ Gouvernance et Gestion des Identités GCP : Le Guide Complet

Cette synthèse regroupe les concepts clés de la gestion multi-projets, de la sécurité des identités et de la conformité automatisée sur GCP.

🏗️ 1. Structure de l’Organisation (Resource Manager)

Voir Resource Manager et Organisation GCP pour le détail complet de la hiérarchie Organization → Folders → Projects.

  1. Organization : la racine, liée au domaine Cloud Identity / Google Workspace. Jamais limitée par ses propres Organization Policies au niveau où elles sont définies.
  2. Folders : regroupent les projets par environnement ou fonction, héritage descendant des policies.
  3. Projects : l’unité de base, hébergeant les ressources et leur facturation.

🛡️ 2. Contrôle et Garde-fous (Organization Policy Service)

Les Organization Policy constraints sont l’équivalent des SCP AWS : elles définissent les permissions maximales pour un Folder ou un Project.

  • Logique de filtre : une constraint ne donne pas de droits, elle restreint ce qu’un utilisateur ou une IAM Policy peut autoriser en dessous.
  • Priorité du DENY : un refus explicite l’emporte toujours sur une autorisation (comme sur AWS).
  • IAM Deny Policies : couche de refus explicite indépendante des rôles, appliquée directement sur des principals — complète les Organization Policies (qui portent sur des ressources/comportements, pas des identités).

👤 3. Gestion des Identités (IAM & Fédération)

L’identité repose sur des credentials courte durée via Workload/Workforce Identity Federation, à l’inverse des clés de service account statiques (équivalent des clés IAM long-lived AWS, à éviter).

Cloud Identity & Workforce Identity Federation

Le pont entre l’annuaire d’entreprise (Active Directory, Okta) et GCP — équivalent d’IAM Identity Center (ex-SSO) :

  • Workforce Identity Federation : fédère un fournisseur d’identité externe (SAML/OIDC) pour donner accès à la console/API GCP sans compte Google natif.
  • Workload Identity Federation : permet à une charge de travail (CI/CD externe, autre cloud, ou pods GKE — voir Workload Identity) d’obtenir des credentials GCP temporaires sans télécharger de clé JSON de service account.

RBAC vs ABAC

  • RBAC (rôles prédéfinis/personnalisés) : IAM attribue des rôles (Basic, Predefined, Custom) à des principals sur des ressources. Facile à auditer, mais peut entraîner une prolifération de rôles custom à grande échelle.
  • ABAC (IAM Conditions) : des conditions basées sur des attributs (tags de ressources, heure, adresse IP) permettent d’exprimer des règles d’accès dynamiques sans multiplier les rôles — équivalent des tags ABAC AWS.

📊 4. Conformité et Remédiation

  1. Cloud Asset Inventory : le “radar” — historise et interroge l’état de toutes les ressources de l’organisation, à travers projets et régions.
  2. Security Command Center : agrège les findings de sécurité et de conformité de tous les projets dans une vue unique (équivalent de l’agrégateur AWS Config + GuardDuty + Security Hub combinés).
  3. Remédiation automatisée : via Cloud Functions/Workflows déclenchés par des findings SCC, ou Policy Controller (Config Sync + OPA/Gatekeeper) pour bloquer/corriger en continu — équivalent des documents SSM Automation AWS.

🔄 5. Cycle de Vie et Transfert de Projets

Déplacement (Move)

Déplacer un projet entre deux Folders est quasi instantané : le projet perd immédiatement les Organization Policies de l’ancien Folder et adopte celles du nouveau — identique au comportement AWS lors d’un déplacement de compte entre OU.

Détachement de l’Organization

Pour qu’un projet quitte une Organization et devienne indépendant :

  1. Un utilisateur avec le rôle Owner sur le projet est requis.
  2. Un Billing Account valide doit rester rattaché.
  3. L’opération se fait via Resource Manager (gcloud projects move en sens inverse / détachement), sans “handshake” bilatéral comme sur AWS.

⚖️ 6. Algorithme de Décision IAM

Si un seul élément de cette chaîne contient un refus (Organization Policy violée ou IAM Deny), l’accès est refusé, quel que soit le nombre d’Allow accordés ailleurs dans la hiérarchie. Si aucun Allow n’est trouvé à aucun niveau, l’accès est refusé par défaut.

💡 Aide-mémoire Obsidian

  • Éviter les clés de service account statiques : toujours préférer Workload Identity Federation (workloads) ou Workforce Identity Federation (humains) aux clés JSON exportées.
  • Tagging pour l’ABAC : utiliser les labels de ressources + IAM Conditions pour éviter l’explosion de rôles custom à mesure que l’organisation grandit.
  • Délégation : centraliser Security Command Center et Cloud Asset Inventory dans un projet “Security” dédié, à l’image du compte Security AWS.
  • Prévention par région : les Organization Policies permettent de restreindre les régions autorisées (constraints/gcp.resourceLocations), équivalent du blocage de région par SCP sur AWS.

En relation avec

Graph View

Backlinks