La resource hierarchy come fondamenta

La resource hierarchy di Google Cloud e’ l’ossatura su cui poggia tutto il resto: organization al vertice, poi le folder (per business unit, ambiente o team) e infine i project, che rappresentano il confine di billing, quota e isolamento delle risorse. Il punto chiave per l’esame e’ l’ereditarieta’: sia i binding IAM sia le organization policy definite a un livello superiore fluiscono verso il basso. Applicare un controllo una volta a livello di organization o folder e’ quindi piu’ robusto e manutenibile che replicarlo su ogni singolo project. Progettare bene la gerarchia (per esempio separare prod e non-prod in folder distinte) permette di differenziare guardrail e permessi senza moltiplicare il lavoro.

Landing zone e Infrastructure as Code

La landing zone e’ l’insieme di fondamenta che predisponi prima dei workload: gerarchia, IAM con least privilege basato su gruppi, networking (tipicamente Shared VPC con topologia hub-and-spoke), logging e monitoring centralizzati, e i guardrail di sicurezza. Costruirla a mano non e’ ripetibile ne’ auditabile: qui entra l’Infrastructure as Code.

Con Terraform descrivi lo stato desiderato in modo dichiarativo e lo applichi via pipeline (plan -> review -> apply). Il trade-off e’ che devi gestire lo state file e i runner. Config Controller e’ invece un servizio gestito che porta il modello GitOps/KRM (Config Connector + Policy Controller + Config Sync) al provisioning delle risorse Google Cloud: riconcilia in continuo lo stato desiderato e corregge il drift senza che tu gestisca state o esecutori. Scegli Terraform quando vuoi il controllo di una pipeline CI/CD classica; scegli Config Controller quando vuoi riconciliazione continua e correzione automatica del drift.

Il Cloud Foundation Toolkit (CFT) offre moduli e blueprint Terraform opinionati e gia’ validati per costruire la landing zone senza reinventare le basi. Il suo componente piu’ citato e’ la project factory, che crea project in modo ripetibile e coerente (billing, API abilitate, service account, label): e’ l’alternativa allo scripting manuale quando devi generare decine di progetti conformi.

Guardrail preventivi con le organization policy

Le organization policy sono guardrail preventivi: impostano constraint che bloccano configurazioni non conformi prima che vengano create, a differenza dei controlli detective (come Security Command Center) che segnalano dopo il fatto. Esempi tipici: limitare le region consentite, disabilitare la creazione di chiavi per i service account, vietare gli IP pubblici. Definite in cima alla gerarchia ed ereditate, garantiscono che ogni nuovo project nasca gia’ dentro i binari. Insieme a IAM (chi puo’ fare cosa) e alle fondamenta di rete, formano il perimetro di sicurezza della landing zone.

GitOps con Config Sync

Config Sync applica il modello GitOps allo stato desiderato dei cluster GKE e delle fleet: la configurazione in formato KRM vive in Git come single source of truth, e l’agente la riconcilia in continuo sul cluster, correggendo qualsiasi drift manuale. Abbinato a Policy Controller (admission basato su policy), impedisce che finiscano nel cluster oggetti non conformi. Rispetto a un kubectl apply manuale, riduce il toil e rende ogni cambiamento tracciabile, revisionabile e reversibile via pull request.

Trappole tipiche d’esame

  • Drift continuo sulle risorse GCP da correggere automaticamente -> Config Controller/Config Sync: la riconciliazione continua GitOps rimedia il drift da sola; un terraform apply schedulato e’ piu’ fragile e non e’ la risposta preferita.
  • Bloccare la creazione di risorse in region non consentite -> organization policy, non SCC: l’org policy e’ preventiva e blocca a monte; Security Command Center e’ detective e segnala soltanto dopo il fatto.
  • Creare decine di project conformi in modo ripetibile -> project factory del CFT: console o scripting manuale non scalano ne’ garantiscono coerenza; il blueprint e’ la scelta corretta.
  • Applicare un guardrail a tutti i progetti presenti e futuri -> impostalo su organization/folder: grazie all’ereditarieta’ vale ovunque; definirlo project per project e’ l’opzione-trappola.
  • Disabilitare le chiavi dei service account sull’intera org -> constraint iam.disableServiceAccountKeyCreation: e’ un controllo preventivo via org policy, non un alert di audit da configurare a posteriori.
  • Provisioning della gerarchia e della landing zone -> Terraform/Config Controller, non Config Sync: Config Sync gestisce lo stato desiderato di cluster e fleet, non crea l’organization hierarchy.