Service account: un’identità per i workload

Un service account è un’identità che appartiene a un’applicazione o a una VM, non a una persona: gli umani usano i propri Google account, i workload usano i service account. Ogni service account è identificato da un indirizzo email (nome@progetto.iam.gserviceaccount.com) e lo crei con gcloud iam service-accounts create.

Quando avvii una Compute Engine VM puoi attaccare un service account con il flag --service-account di gcloud compute instances create. Il codice che gira sulla VM ottiene automaticamente le credenziali dal metadata server, senza gestire file di chiavi. La regola d’oro dell’esame: non usare il Compute Engine default service account, che nasce con il basic role Editor (troppo ampio); crea invece un service account dedicato per ogni workload e assegnagli solo i ruoli che servono.

Chiavi vs impersonation

Ci sono due modi per far agire un’applicazione come service account. Le service account key sono file JSON con credenziali long-lived: comode ma pericolose, perché se il file finisce in un repository o in un log resta valido finché non lo revochi. Vanno evitate ogni volta che esiste un’alternativa.

L’alternativa è l’impersonation con short-lived credentials: chi ha il ruolo roles/iam.serviceAccountTokenCreator sul service account può generare access token che scadono nel giro di circa un’ora. Con gcloud basta il flag --impersonate-service-account; per i carichi dentro Google Cloud usi le credenziali attaccate alla VM o Workload Identity su GKE. Per i workload esterni (on-prem, altri cloud, CI/CD) la scelta corretta è Workload Identity Federation, che elimina del tutto le chiavi. In pratica: se una domanda chiede come ridurre il rischio di credenziali che trapelano, la risposta è quasi sempre “elimina le key e usa short-lived credentials / impersonation”.

Least privilege e assegnazione dei ruoli

Assegni i ruoli al service account con gcloud projects add-iam-policy-binding, indicando --member=serviceAccount:EMAIL e --role=. Il principio di least privilege impone di preferire i predefined role (es. roles/storage.objectViewer, roles/pubsub.subscriber) ai basic role owner/editor/viewer, troppo grossolani. Ricorda anche la differenza tra chi può usare un service account (roles/iam.serviceAccountUser, necessario per attaccarlo a una VM) e chi può impersonarlo (roles/iam.serviceAccountTokenCreator).

KMS, Secret Manager e audit log

Cloud KMS gestisce le chiavi crittografiche, organizzate nella gerarchia key ring > key > key version, con rotazione automatica configurabile per le chiavi simmetriche. Il caso tipico è CMEK (Customer-Managed Encryption Keys): usi una tua key di KMS per cifrare i dati in servizi come Cloud Storage o BigQuery al posto delle chiavi gestite da Google. Il ruolo operativo è roles/cloudkms.cryptoKeyEncrypterDecrypter.

Secret Manager invece conserva il valore dei segreti (password, API key, certificati) con versioning: l’applicazione legge il payload se ha roles/secretmanager.secretAccessor. Distinzione da ricordare: KMS gestisce le chiavi di cifratura, Secret Manager conserva e restituisce il segreto stesso.

Per la tracciabilità ci sono i Cloud Audit Logs. Gli Admin Activity log registrano le modifiche di configurazione, sono sempre attivi e senza costo. I Data Access log registrano letture e accessi ai dati, sono disabilitati di default (tranne BigQuery) e vanno abilitati esplicitamente: sono la risposta quando serve sapere “chi ha letto o acceduto a quel dato”.

Trappole tipiche d’esame

  • App su una VM deve accedere a Cloud Storage senza gestire chiavi → soluzione: attacca un service account dedicato alla VM; il codice usa le credenziali dal metadata server, niente key file da distribuire.
  • Workload esterno o CI/CD deve autenticarsi e vuoi ridurre il rischio di chiavi trapelate → soluzione: Workload Identity Federation o impersonation con short-lived credentials; non scaricare service account key JSON long-lived.
  • La tentazione di dare “accesso completo” con un basic role → soluzione: usa i predefined role (least privilege); owner/editor/viewer sono troppo ampi e non superano una domanda ben posta.
  • Serve sapere chi ha letto i dati in un bucket → soluzione: abilita i Data Access audit log; gli Admin Activity log da soli non bastano perché registrano solo le modifiche di configurazione.
  • Confusione KMS vs Secret Manager → soluzione: KMS per gestire chiavi di cifratura e CMEK, Secret Manager per conservare password e API key.
  • Distinguere usare da impersonare un service account → soluzione: roles/iam.serviceAccountUser per attaccarlo/usarlo su una VM, roles/iam.serviceAccountTokenCreator per generare token e fare impersonation.