La resource hierarchy: organization, folder, project

Google Cloud organizza le risorse in una gerarchia a tre livelli: organization (la radice, legata al dominio Cloud Identity o Google Workspace), folder (raggruppamenti intermedi, per esempio per reparto o ambiente) e project. Il project e’ l’unita’ base: contiene le risorse, e’ il confine di fatturazione e di abilitazione delle API, ed e’ identificato da un project ID globalmente unico e immutabile, oltre a un project number generato automaticamente.

Il punto chiave d’esame e’ l’ereditarieta’ IAM: le policy assegnate a un nodo superiore vengono ereditate verso il basso e si sommano (union) con quelle dei figli. Non puoi “togliere” a livello di project un ruolo concesso a livello di organization con una normale allow policy; per restringere servono organization policy o IAM deny policy. Le folder richiedono un nodo organization: senza organization esistono solo project isolati.

Billing account, budget e alert

Un billing account paga per uno o piu’ project, ma ogni project e’ collegato a un solo billing account alla volta. Per collegare un project il ruolo di least privilege e’ roles/billing.user sul billing account (piu’ il permesso di assegnazione sul project); l’amministrazione completa richiede roles/billing.admin. I basic role come roles/owner funzionerebbero ma sono troppo ampi.

I budget definiscono una soglia di spesa e inviano alert via email o Pub/Sub quando la spesa raggiunge le percentuali configurate. Attenzione: un budget non blocca la spesa, e’ solo una notifica. Per fermare i costi al superamento serve un’automazione (alert su Pub/Sub → Cloud Function che disabilita il billing del project). Per l’analisi dettagliata si abilita il billing export su BigQuery, che scrive costi e utilizzo in un dataset interrogabile con SQL, molto piu’ granulare dei report della console.

Abilitare le API e installare il Cloud SDK

Ogni servizio va abilitato sul project prima dell’uso: gcloud services enable compute.googleapis.com, e gcloud services list --enabled per verificare. Un’API non abilitata restituisce errori 403 anche con IAM corretto.

Il Cloud SDK fornisce le CLI: gcloud (risorse GCP), bq (BigQuery) e gcloud storage per Cloud Storage (il vecchio gsutil resta disponibile ma e’ legacy). Dopo l’installazione, gcloud init esegue l’autenticazione (gcloud auth login) e imposta project e regione di default. I componenti aggiuntivi si gestiscono con gcloud components install / gcloud components update.

Cloud Shell e le gcloud config configurations

Cloud Shell e’ una VM effimera nel browser con SDK gia’ installato e gia’ autenticato con il tuo account: ideale per attivita’ rapide senza installare nulla in locale. Solo la home directory (circa 5 GB) e’ persistente; il resto dell’ambiente viene ricreato a ogni sessione.

Quando gestisci piu’ project o account, le gcloud config configurations sono la risposta: ogni configuration e’ un set nominato di proprieta’ (account, project, region, zone). Comandi tipici: gcloud config set project PROJECT_ID per il project attivo, gcloud config configurations create prod, gcloud config configurations activate prod, gcloud config configurations list. Cosi’ passi da un ambiente all’altro senza riautenticarti ogni volta ed eviti l’errore di operare sul project sbagliato.

Trappole tipiche d’esame

  • Il superamento del budget deve fermare la spesa → soluzione: i budget non bloccano nulla; configura un alert su Pub/Sub che innesca una Cloud Function per disabilitare il billing del project.
  • Concedere il minimo per collegare un project al billing → soluzione: roles/billing.user sul billing account, non roles/billing.admin ne’ roles/owner, che sono troppo ampi.
  • Passare rapidamente tra piu’ project/account nella CLI → soluzione: crea piu’ gcloud config configurations e usa activate, invece di rilanciare gcloud init o ripetere gcloud auth login.
  • Analisi costi dettagliata e storica → soluzione: abilita il billing export su BigQuery e interroga in SQL; budget e alert servono solo a notificare, non ad analizzare.
  • Chiamata API che restituisce 403 con IAM corretto → soluzione: l’API del servizio non e’ abilitata sul project; esegui gcloud services enable <api>.
  • Servono folder per separare gli ambienti → soluzione: richiedono un nodo organization (Cloud Identity/Workspace); senza organization hai solo project a se’ stanti.