abla.adem

Recent Notes

GCP

1 min read

Gouvernance et gestion des identités GCP

☁️ 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

Link to original

Architecture réseau multi-projets

🌐 Architecture Réseau GCP Multi-Projets : Connectivité et Partage

1. Le Réseau Multi-Projets : Connecter (ou partager) les VPC

GCP propose trois modèles, à ne pas confondre.

VPC Network Peering (la connexion point à point)

  • Le principe : Connexion directe 1-à-1 entre deux VPC (même organisation ou non), le trafic passe par le réseau privé de Google.
  • La limite majeure (pas de transitivité) : identique à AWS — si VPC A ↔ VPC B et VPC B ↔ VPC C, alors A ne peut pas parler à C. Il faut peering directement A ↔ C.
  • À l’échelle : même explosion combinatoire qu’avec le VPC Peering AWS.

Shared VPC (le modèle natif et recommandé sur GCP)

C’est la différence structurelle majeure avec AWS : là où AWS partage des subnets via RAM (mécanisme optionnel parmi d’autres), GCP construit son modèle multi-projets autour du Shared VPC.

  • Le principe : un Host Project possède le VPC et ses subnets. Des Service Projects y sont rattachés (“attached”) et peuvent y déployer des ressources (VM, GKE, Cloud SQL) — sans jamais posséder le réseau eux-mêmes.
  • Pas de peering nécessaire : les Service Projects sont dans le même VPC que le Host Project, donc aucune connexion à établir — la communication est native.
  • Séparation des responsabilités :
    • Équipe Réseau (Host Project) : gère le VPC, les plages IP, les routes, les Cloud NAT, les Firewall Rules globales.
    • Équipes Applicatives (Service Projects) : déploient leurs ressources sur les subnets qu’on leur a attribués, gèrent uniquement leur IAM et leurs ressources applicatives.

Network Connectivity Center (le hub centralisé)

Équivalent du Transit Gateway AWS — un hub qui connecte VPC, VPN et Interconnect entre eux avec routage transitif complet (hub-and-spoke), utile quand le Shared VPC seul ne suffit pas (multi-organisation, hybrid cloud complexe, interconnexion de VPC déjà existants et non fusionnables en Shared VPC).

2. Comparatif des trois modèles

VPC PeeringShared VPCNetwork Connectivity Center
TransitivitéNonN/A (un seul VPC)Oui
Cas d’usage2-3 VPC isolés, cross-orgMulti-équipes dans une même org, standard GCPHybrid cloud, beaucoup de spokes (VPC + VPN + Interconnect)
Gestion IPChaque VPC garde son CIDRUn seul plan d’adressage, pas de chevauchement possible par designChaque spoke garde son CIDR, doit éviter le chevauchement
ComplexitéFaibleFaible à modérée (setup initial)Élevée

3. L’Overlapping IP : le même ennemi que sur AWS

Le problème est identique : deux réseaux avec le même bloc CIDR (ex. 10.0.0.0/16) ne peuvent pas être routés l’un vers l’autre sans ambiguïté.

  • VPC Peering : GCP bloque la création du peering si les CIDR se chevauchent, comme AWS.
  • Shared VPC : l’overlapping est impossible par design — un seul VPC, un seul plan d’adressage, GCP empêche de créer deux subnets se chevauchant.
  • Network Connectivity Center : comme le Transit Gateway AWS, il laisse attacher des spokes avec des IP en conflit, mais le routage entre eux devient impossible ou asymétrique.

Pas d’équivalent direct à AWS IPAM

GCP n’a pas de service de gouvernance IP dédié aussi complet qu’AWS VPC IPAM. Les approches disponibles :

  • Internal Range API : permet de réserver et d’allouer automatiquement des blocs CIDR non chevauchants entre projets (le plus proche d’un “pool IPAM”), mais moins mature/outillé que le produit AWS.
  • Planification manuelle + Terraform : dans la pratique, la plupart des organisations GCP planifient leur adressage à l’avance (documenté, versionné en Terraform) plutôt que de déléguer à un service d’allocation dynamique.

💡 Aide-mémoire Obsidian

  • Par défaut sur GCP : penser Shared VPC avant Peering. C’est le pattern natif et recommandé par Google pour le multi-équipes ; le Peering reste pour des cas ponctuels ou du cross-organisation.
  • Un VPC GCP est global, pas régional — un Shared VPC peut donc contenir des subnets dans toutes les régions, contrairement à un VPC AWS confiné à une région.
  • Network Connectivity Center inter-région : pas besoin de “peering de hub” comme avec deux Transit Gateway AWS — un seul NCC couvre déjà toutes les régions.
  • Règle de base IP : comme sur AWS, toujours planifier l’adressage avant de créer les projets et VPC — encore plus vrai ici vu l’absence d’un IPAM aussi complet.
  • Sous-réseaux : privilégier des subnets dimensionnés au besoin réel (/24, /20) plutôt que de sur-allouer, même si l’espace CIDR global du VPC est en théorie très large.

En relation avec

Link to original

Réseau GCP

🌐 La Bible du Réseau GCP : Du VPC Global au Load Balancing Anycast

Ce guide détaille comment les données circulent, sont protégées, routées et accélérées sur GCP — en insistant sur les différences structurelles avec AWS, plus qu’avec le monde on-premise (déjà couvert côté AWS).

1. Fondations : un VPC global, pas régional

La différence la plus importante avec AWS.

  • Sur AWS : un VPC est confiné à une région. Pour couvrir plusieurs régions, il faut du VPC Peering ou un Transit Gateway inter-régions.
  • Sur GCP : un VPC est une ressource globale. Ses subnets, eux, sont régionaux — un seul VPC peut donc avoir des subnets à Paris, Francfort et Tokyo, tous capables de se parler nativement sans peering ni passerelle.

Pas d’Internet Gateway explicite

  • Sur AWS : il faut créer et attacher un objet Internet Gateway (IGW) au VPC.
  • Sur GCP : chaque VPC dispose implicitement d’une route par défaut (0.0.0.0/0) vers une passerelle Internet gérée par Google. Aucune ressource à créer ni attacher — il suffit qu’une instance ait une IP externe (ou passe par Cloud NAT) pour sortir.

Les Routes (globales, pas par subnet)

  • Sur AWS : une table de routage est associée à un ou plusieurs subnets.
  • Sur GCP : les routes sont définies au niveau du VPC entier (portée globale), et peuvent être restreintes à des instances via des tags réseau ou des comptes de service. Le “scoping” se fait par tag, pas par association à un subnet.

vNIC et IP alias

Chaque instance a une interface réseau virtuelle (vNIC) avec une IP primaire, et peut recevoir des IP alias ranges — un mécanisme central pour les clusters GKE en mode VPC-native (voir Node pools et autoscaling), où chaque pod reçoit une IP routable directement depuis une alias range du subnet.

2. Le NAT : Cloud NAT, sans ressource dédiée

Le principe du PAT (Port Address Translation, “plusieurs pour un”) est identique à AWS, mais l’implémentation diffère :

  • Cloud NAT : ce n’est pas une “gateway” avec sa propre IP comme le NAT Gateway AWS — c’est une configuration attachée à un Cloud Router. Entièrement managé, il alloue et gère automatiquement les ports NAT (pas de limite fixe de connexions à surveiller comme sur AWS NAT Gateway).
  • NAT par instance (legacy) : équivalent de la NAT Instance AWS — une VM avec IP forwarding activé et une route statique pointant vers elle. Déconseillé : limité par le CPU/RAM de la VM, aucune haute disponibilité native.

3. Sécurité : un seul niveau — les Firewall Rules

Différence structurelle majeure avec AWS. Là où AWS empile deux couches (Security Group au niveau instance + NACL au niveau subnet), GCP n’a qu’un seul système : les VPC Firewall Rules.

CaractéristiqueSecurity Group + NACL (AWS)Firewall Rules (GCP)
NiveauInstance (SG, stateful) + Subnet (NACL, stateless) — deux couchesLe VPC entier, ciblé par tags réseau ou comptes de service — une seule couche
ÉtatSG stateful / NACL statelessToujours stateful
Type de règleSG : Allow uniquement / NACL : Allow et DenyAllow et Deny (comme la NACL), mais stateful (comme le SG)
ApplicationSG attaché à l’ENI / NACL attaché au subnetRègle globale au VPC, filtrée par target tags ou service account, avec une priorité numérique (0 = plus prioritaire)

Il n’y a donc pas de double filtrage à raisonner (contrairement à SG + NACL) : une seule liste de règles ordonnées par priorité décide de tout le trafic, ingress et egress.

4. Architectures Multi-VPC : Peering vs Shared VPC vs Hub & Spoke

VPC Network Peering (le maillage)

  • Connexion directe 1-à-1, pas de transitivité (identique à AWS).
  • Chaque VPC garde sa propre route par défaut vers Internet.

Shared VPC (le modèle natif GCP)

  • Un Host Project possède le VPC, des Service Projects y déploient leurs ressources sans jamais peering — voir Architecture réseau multi-projets pour le détail.
  • Sans équivalent direct côté AWS (le VPC Sharing via RAM existe mais reste une option parmi d’autres, pas le modèle par défaut).

Network Connectivity Center (le hub-and-spoke)

  • Équivalent du Transit Gateway : hub central pour VPC, VPN et Interconnect, routage transitif complet.

5. Connectivité Hybride & Privée

Cloud VPN (HA VPN)

  • Tunnel IPSec chiffré via Internet. Contrairement au VPN Site-to-Site AWS (une seule passerelle par défaut), HA VPN garantit 99.99% de SLA en établissant automatiquement deux tunnels sur deux IP externes distinctes.
  • Nécessite un Cloud Router (BGP) pour l’échange dynamique de routes — pas de routage statique recommandé en production.

Cloud Interconnect (la fibre dédiée)

  • Dedicated Interconnect : connexion physique directe dans un point de présence Google (10 ou 100 Gbps), équivalent de Direct Connect.
  • Partner Interconnect : via un partenaire réseau, pour les débits plus faibles ou les sites sans accès à un point de présence Google.
  • VLAN Attachments : équivalent des Virtual Interfaces (VIF) AWS — les “tuyaux” logiques créés dans la connexion physique.

Private Service Connect (l’accès privé aux services)

  • Pour parler aux APIs Google ou à des services tiers/internes sans passer par Internet ni payer de Cloud NAT.
  • Private Google Access : gratuit, simple option activée sur un subnet, équivalent du Gateway Endpoint AWS (S3, DynamoDB) — juste une route, pas de ressource facturée.
  • Private Service Connect (endpoints) : payant, dépose une IP interne dans ton subnet pointant vers un service producteur (comme une Interface Endpoint / PrivateLink AWS).

6. Diffusion Globale et Répartition de Charge

Cloud CDN : le cache mondial

  • Fonctionne en s’adossant à un Cloud Load Balancer — pas de ressource “CDN” indépendante comme CloudFront. Cache aux edge PoPs de Google si le contenu est un hit, sinon va chercher à l’origine (Cloud Storage, Compute Engine, backend GKE).

Cloud Load Balancing : global et anycast, par défaut

  • Différence majeure avec AWS : il n’existe pas de produit séparé équivalent à Global Accelerator. Le Load Balancer HTTP(S) externe de GCP est nativement global : une seule IP anycast, le trafic entre sur le réseau privé de Google (Premium Tier) au point de présence le plus proche de l’utilisateur, puis voyage sur le backbone Google jusqu’au backend — exactement ce que fait Global Accelerator sur AWS, mais intégré par défaut.
  • Standard Tier : option moins chère, le trafic reste sur l’Internet public plus longtemps avant d’entrer sur le réseau Google — plus proche d’un ELB “régional” classique.
  • Types : Global external Application Load Balancer (L7, HTTP(S)), Global external proxy Network Load Balancer (L4, TCP/SSL), Regional/Internal Load Balancers pour le trafic interne au VPC.
  • Network Endpoint Groups (NEG) : routage direct vers des pods GKE plutôt que vers des nœuds entiers.

7. L’Intelligence du Routage : Cloud DNS vs Load Balancer

Même distinction qu’AWS entre le DNS (macro, avant la connexion) et le Load Balancer (micro, après la connexion) :

  • Cloud DNS (le GPS global) : résout un nom vers une IP, “stateless” — ne voit ni le CPU ni la RAM des serveurs, décide via des règles déclaratives.
  • Load Balancer (le vigile local) : reçoit la connexion sur l’IP donnée par Cloud DNS (ou directement, puisque le LB a déjà une IP anycast fixe) et distribue les paquets aux backends.

Routing policies Cloud DNS (mêmes concepts que Route 53) :

  1. Simple : un nom → une IP fixe.
  2. Weighted Round Robin : répartition pondérée façon “dé virtuel”, comme le Weighted Routing de Route 53.
  3. Geolocation : route selon la localisation géographique déduite de l’IP du client.
  4. Failover / Health Checks : bascule vers une IP de secours si les sondes échouent.

⚠️ Même piège qu’avec Route 53 : Cloud DNS ne connaît jamais la charge réelle du serveur. C’est le rôle du Load Balancer (avec ses propres health checks applicatifs) de vérifier la charge et de retirer un backend saturé de la rotation.

💡 L’Aide-mémoire Ultime de l’Architecte GCP

  • Le VPC est global — penser plan d’adressage à l’échelle mondiale dès le départ, pas région par région.
  • Un seul système de firewall (Firewall Rules) remplace le duo SG + NACL — une seule liste de priorités à auditer.
  • Shared VPC avant Peering pour le multi-équipes — c’est le pattern par défaut sur GCP, contrairement à AWS.
  • Cloud NAT n’a pas d’IP propre à retenir : c’est une config sur un Cloud Router, pas une ressource “boîte noire”.
  • Cloud Load Balancing = ELB + Global Accelerator réunis par défaut en Premium Tier — pas besoin d’un second produit pour l’anycast global.
  • Cloud Interconnect pour une fibre privée dédiée ; Cloud VPN (HA) pour un tunnel chiffré rapide à monter via Internet.
  • Private Service Connect / Private Google Access pour rester 100% privé vers les APIs Google, sans NAT.

En relation avec

Link to original

🗼 Resource Manager : L’Orchestrateur de Gouvernance GCP

Graph View