La gestione dell'identità applicativa su Kubernetes rappresenta uno dei pilastri critici della postura di sicurezza enterprise. Negli ambienti cloud ibridi e regolamentati, come il settore bancario e dei pagamenti digitali, garantire che un microservizio in esecuzione su un cluster Google Kubernetes Engine (GKE) possa invocare API Google Cloud (Cloud Storage, Secret Manager, Cloud KMS, BigQuery) senza ricorrere a segreti statici è un requisito di conformità non negoziabile.

Per anni, lo standard di riferimento su Google Cloud è stato GKE Workload Identity, implementato mediante un modello di impersonation: il Kubernetes Service Account (KSA) riceveva il ruolo IAM roles/iam.workloadIdentityUser su una Google Service Account (GSA) dedicata, permettendo al GKE Metadata Server di emettere un token OAuth2 a valle di una catena di scambi crittografici. Questo approccio ha rappresentato una pietra miliare nella sicurezza cloud-native, eliminando l'uso delle chiavi di servizio JSON statiche nei Secret del cluster. Tuttavia, su scala enterprise con decine di cluster e centinaia di microservizi, richiede la gestione e il censimento di una Service Account GCP per ogni workload applicativo.

L'evoluzione nativa di IAM su Google Cloud consente oggi di affiancare e semplificare questo pattern attraverso i Direct Principal Grants di Workload Identity Federation: assegnare i permessi IAM direttamente all'identificatore canonico del KSA, eliminando la Google Service Account intermedia e il doppio passaggio di impersonation.

L'Anatomia del Doppio Hop: Il Flusso dell'Impersonation Classica

Nel pattern convenzionale di Workload Identity, l'identità del pod e l'identità IAM cloud vivono in due perimetri distinti che richiedono una mappatura esplicita tra Kubernetes e Google Cloud:

• KSA locale: Creato nel namespace Kubernetes dell'applicazione (es. payment-processor nel namespace payments).
• GSA remota: Creata nel progetto Google Cloud (es. gsa-payment-processor@prj-core-banking-prod.iam.gserviceaccount.com).

Il collegamento operativo richiede due passaggi di configurazione distinti. In primo luogo, l'assegnazione del ruolo roles/iam.workloadIdentityUser sulla GSA all'entità federata del KSA:

resource "google_service_account_iam_member" "workload_identity_user" {
  service_account_id = google_service_account.app_gsa.name
  role               = "roles/iam.workloadIdentityUser"
  member             = "serviceAccount:prj-core-banking-prod.svc.id.goog[payments/payment-processor]"
}

In secondo luogo, il KSA deve essere decorato con l'annotazione specifica per istruire il webhook di mutazione di GKE su quale GSA impersonare a runtime:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: payment-processor
  namespace: payments
  annotations:
    iam.gke.io/gcp-service-account: gsa-payment-processor@prj-core-banking-prod.iam.gserviceaccount.com

A runtime, l'emissione del token attraversa una catena a doppio hop: uno scambio iniziale con Google Security Token Service (STS) per validare l'identità OIDC del KSA, seguito dalla chiamata di impersonation alla IAM Credentials API:

Ingrandisci

Caratteristiche e Considerazioni sul Modello a Impersonation

Il pattern basato su GSA impersonation rappresenta una soluzione solida, pienamente supportata e ancora oggi ampiamente adottata in produzione su Google Cloud, in particolare quando la medesima Service Account deve essere condivisa trasversalmente con altri servizi (come Cloud Run o istanze Compute Engine). Tuttavia, all'interno di architetture Kubernetes enterprise con centinaia di microservizi, emergono alcune considerazioni operative e architetturali:

• Gestione del Ciclo di Vita delle GSA: Richiede il censimento e la profilazione di una GSA per ciascun KSA applicativo (rapporto 1:1), aumentando il volume di entità IAM da manutenere nei progetti.
• Tracciamento nei Cloud Audit Logs: L'attributo principale (principalEmail) registra l'indirizzo della GSA intermedia. Per identificare con precisione quale specifico KSA o pod abbia generato la richiesta, le analisi di incident response o audit devono estrarre i metadati di delega annidati (serviceAccountDelegationInfo).
• Passaggi di Minting del Token: A runtime, il Metadata Server deve prima eseguire lo scambio con Google STS e successivamente invocare l'API iam.serviceAccounts.getAccessToken per emettere il token della GSA.
• Presidio del Perimetro dei Privilegi: L'associazione tra KSA e GSA richiede una governance attenta per evitare che più KSA condividano la medesima GSA allargando inavvertitamente il raggio d'azione dei privilegi.

L'Architettura Direct Principal Grant

Con i Direct Principal Grants, Google Cloud estende il motore di Workload Identity Federation nativo direttamente ai cluster GKE. Non viene creata alcuna Service Account intermedia a livello di progetto Google Cloud: il Kubernetes Service Account diventa un principal IAM di primo livello riconosciuto nativamente da Cloud IAM.

In questo modello a singolo hop, il token federato emesso da STS concede direttamente l'accesso alle risorse target:

Ingrandisci

Quando si abilita Workload Identity su un cluster GKE, Google Cloud crea automaticamente un Workload Identity Pool dedicato associato al progetto ospitante, con la sintassi convenzionale:

{PROJECT_ID}.svc.id.goog

All'interno di questo pool, ogni KSA instanziato in un cluster possiede un identificatore uniforme della risorsa (URI) immutabile e deterministico:

principal://iam.googleapis.com/projects/{PROJECT_NUMBER}/locations/global/workloadIdentityPools/{PROJECT_ID}.svc.id.goog/subject/ns/{NAMESPACE}/sa/{KSA_NAME}

In alternativa, Cloud IAM supporta la sintassi legacy contratta per retrocompatibilità:

serviceAccount:{PROJECT_ID}.svc.id.goog[{NAMESPACE}/{KSA_NAME}]

Implementazione Infrastructure as Code con Terraform

L'implementazione dei Direct Principal Grants elimina il blocco di risorse google_service_account per i carichi applicativi, riducendo il codice IaC a un'assegnazione diretta dei ruoli sulle risorse di destinazione.

Nel seguente scenario enterprise, un'applicazione bancaria settlement-engine nel namespace settlement deve leggere segreti da Secret Manager e decifrare transazioni tramite Cloud KMS, senza alcuna GSA intermedia.

1. Dichiarazione delle Risorse IAM Dirette

data "google_project" "current" {
  project_id = var.project_id
}

locals {
  # Calcolo del principal identifier canonico per il KSA
  ksa_principal = "principal://iam.googleapis.com/projects/${data.google_project.current.number}/locations/global/workloadIdentityPools/${var.project_id}.svc.id.goog/subject/ns/${var.namespace}/sa/${var.ksa_name}"
}

# Assegnazione accesso in lettura a Secret Manager direttamente al KSA
resource "google_secret_manager_secret_iam_member" "settlement_secrets" {
  project   = var.project_id
  secret_id = "settlement-database-credentials"
  role      = "roles/secretmanager.secretAccessor"
  member    = locals.ksa_principal
}

# Assegnazione ruolo di decifratura Cloud KMS direttamente al KSA
resource "google_kms_crypto_key_iam_member" "settlement_crypto" {
  crypto_key_id = var.kms_crypto_key_id
  role          = "roles/cloudkms.cryptoKeyDecrypter"
  member        = locals.ksa_principal
}

2. Configurazione del Manifest Kubernetes (KSA Pulito)

Sul versante Kubernetes, scompare qualsiasi riferimento a email di Service Account Google. Il KSA rimane una risorsa pura e disaccoppiata dall'infrastruttura esterna:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: settlement-engine
  namespace: settlement
  labels:
    app.kubernetes.io/name: settlement-engine
    app.kubernetes.io/part-of: core-banking
automountServiceAccountToken: true

Matrice Comparativa: GSA Impersonation vs Direct Principal Grant

Verifiche di Sicurezza e Cloud Audit Logs

Uno dei vantaggi più evidenti per i Cloud Security Architect e per le funzioni di controllo (Audit interno, Risk Management, Compliance orientate a DORA e PCI-DSS v4) risiede nella purezza del dato di audit.

Quando il microservizio accede a un segreto o a un bucket storage, la voce di registro registrata in Cloud Logging isola istantaneamente il soggetto Kubernetes chiamante:

{
  "protoPayload": {
    "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
    "authenticationInfo": {
      "principalSubject": "principal://iam.googleapis.com/projects/108429519284/locations/global/workloadIdentityPools/prj-core-banking-prod.svc.id.goog/subject/ns/settlement/sa/settlement-engine"
    },
    "serviceName": "secretmanager.googleapis.com",
    "methodName": "google.cloud.secretmanager.v1.SecretManagerService.AccessSecretVersion",
    "resourceName": "projects/prj-core-banking-prod/secrets/settlement-database-credentials/versions/1"
  }
}

Non vi è alcuna necessità di correlare sessioni di delega o analizzare catene di chiamate AssumeRole/Impersonate: l'evidenza forense è inequivocabile e collegata all'esatto namespace e KSA del cluster.

Raccomandazioni Architetturali per l'Adozione Enterprise

1. Standardizzare il Modulo Terraform Riutilizzabile: Incapsulare la costruzione della stringa principal://... all'interno di un modulo Terraform condiviso o di una funzione locale, per garantire che nessun team commetta errori di battitura nei segmenti del path /subject/ns/{ns}/sa/{sa}.
2. Definire Namespace e KSA Immutabili: Poiché la policy IAM fa riferimento diretto alla tupla ns/{NAMESPACE}/sa/{KSA_NAME}, qualsiasi ridenominazione di un namespace o di un service account Kubernetes deve essere coordinata con un aggiornamento preventivo delle policy IAM in Terraform, per evitare interruzioni di servizio.
3. Migrazione Incrementale a Impatto Zero: I due pattern possono coesistere all'interno dello stesso cluster GKE. È possibile migrare un singolo microservizio per volta: assegnare il Direct Principal Grant, verificare il corretto accesso tramite Cloud Logging e successivamente rimuovere l'annotazione sul KSA e la GSA dismessa.
4. Hardening del Metadata Server: Assicurarsi sempre che l'opzione workload_metadata_config = GKE_METADATA sia abilitata su tutti i node pool GKE del cluster, inibendo qualsiasi accesso ai metadati legacy delle Compute Engine VM.