🏗️ Resource Manager et Organisation GCP : La Hiérarchie de Gouvernance
Contrairement à AWS qui package sa gouvernance dans un service unique (Control Tower), GCP répartit ces responsabilités entre plusieurs briques natives : Resource Manager (hiérarchie), Organization Policy Service (garde-fous) et des modules Terraform (landing zone). Il n’existe pas de produit “clé en main” équivalent — la landing zone se construit via Infrastructure as Code (Cloud Foundation Toolkit / terraform-example-foundation).
🏗️ 1. La hiérarchie des ressources (Resource Manager)
C’est le squelette sur lequel tout repose :
- Organization : La racine, liée à ton domaine Google Workspace / Cloud Identity. Équivalent du Management Account AWS — jamais limitée par ses propres Organization Policies au niveau supérieur.
- Folders : Conteneurs hiérarchiques (imbricables, contrairement aux OU AWS qui sont un seul niveau logique) permettant de regrouper les projets par environnement (Prod, Dev) ou par fonction (Security, Network). Les policies appliquées à un Folder sont héritées par tous les projets et sous-folders qu’il contient.
- Projects : L’unité de base GCP. Chaque ressource (VM, bucket, cluster GKE) appartient à un seul projet, qui porte son propre ID unique, sa facturation et ses APIs activées. Équivalent d’un compte membre AWS, mais bien plus léger à créer (pas de compte email séparé).
🏠2. Project Factory (l’usine à projets)
L’équivalent de l’Account Factory de Control Tower n’est pas un service managé mais un module Terraform (terraform-google-project-factory, partie du Cloud Foundation Toolkit) :
- Automatisation : Crée un projet standardisé avec APIs activées, IAM bindings, rattachement au Shared VPC, budget et labels — en une seule apply, au lieu de configurer chaque projet à la main.
- Standardisation : Chaque projet “vendu” (vended project) sort avec les mêmes garde-fous (logging activé, Organization Policies héritées, quotas par défaut).
🛡️ 3. Les garde-fous : Organization Policy Service
Équivalent des SCP AWS — des contraintes (constraints) appliquées à un nœud de la hiérarchie et héritées vers le bas.
| Catégorie | AWS | GCP | Exemple |
|---|---|---|---|
| Préventif | SCP (Service Control Policy) | Organization Policy constraints | constraints/compute.vmExternalIpAccess — interdire les IP publiques sur les VM |
| DĂ©tectif | AWS Config rules | Security Command Center (Security Health Analytics) | DĂ©tecter un bucket Cloud Storage public |
| Proactif | CloudFormation Hooks | Policy Controller (Config Sync + OPA/Gatekeeper) ou terraform validate avec Policy as Code | Bloquer un terraform apply qui violerait une contrainte avant déploiement |
- Priorité du DENY : comme sur AWS, une contrainte de refus l’emporte toujours sur une autorisation à un niveau inférieur de la hiérarchie.
- IAM Deny policies : GCP a ajouté une couche de refus explicite indépendante des rôles IAM (equivalent conceptuel aux permission boundaries / SCP côté identité plutôt que ressource).
📊 4. Le tableau de bord centralisé : Security Command Center
SCC agrège, au niveau Organization, les findings de sécurité et de conformité de tous les projets — c’est l’équivalent du dashboard Control Tower + AWS Config Aggregator combinés :
- Vue unique de la posture de sécurité (misconfigurations, vulnérabilités, menaces actives)
- Policy Intelligence (Policy Analyzer, Policy Simulator) pour visualiser qui a accès à quoi avant de changer une policy
💡 Aide-mémoire Obsidian
- Pas de “drift” au sens Control Tower : GCP n’a pas de service wrapper à désynchroniser — les Organization Policies et IAM bindings sont la source de vérité elle-même, pas une couche gérée par-dessus. Le risque équivalent est un changement manuel hors Terraform (drift IaC classique).
- Landing Zone as Code : privilégier
terraform-example-foundation(Google) dès le départ plutôt que de construire l’arborescence Organization/Folders/Projects à la main. - Un projet = un blast radius : contrairement à AWS où tout peut vivre dans un compte, la discipline GCP pousse naturellement à multiplier les projets (facturation et IAM isolés par défaut).
- Billing Account séparé : un Billing Account n’est pas un nœud de la hiérarchie Organization — il est lié à des projets, ce qui permet de centraliser la facturation indépendamment de la structure Folders.
En relation avec
- Gouvernance — Vue d’ensemble — hub gouvernance GCP
- Gouvernance et gestion des identités GCP — IAM et identités
- Organization Policy Service / Security Command Center — garde-fous et dashboard détaillés
- Cloud Identity — annuaire sur lequel repose l’Organization
- AWS Control Tower — équivalent conceptuel côté AWS