Panoramica di Workload Identity

L'identità del carico di lavoro consente di assegnare identità e autorizzazioni distinte e granulari per ogni applicazione nel tuo cluster. Workload Identity è il modo consigliato per le applicazioni eseguite in GKE su Azure di accedere ai servizi Azure e Google Cloud.

In tutti i cluster GKE è abilitata Workload Identity.

Account di servizio Kubernetes

Workload Identity implementa la federazione delle identità, oppure delega trust o ruoli a un provider esterno. Ogni cluster ha un provider OpenID Connect (OIDC) integrato. Quando un pod viene eseguito nel cluster, viene eseguito utilizzando un account di servizio Kubernetes. Il pod può essere configurato per ottenere un token con credenziali di breve durata per il suo account di servizio Kubernetes utilizzando un volume di token dell'account di servizio associato.

Provider OpenID Connect

Ogni cluster può fungere da provider OpenID Connect (OIDC). Con questo provider, puoi fornire le credenziali dell'account di servizio Kubernetes ai servizi che supportano la federazione delle identità utilizzando OIDC.

L'URI dell'emittente di questo provider funge anche da endpoint di rilevamento OIDC. I servizi possono utilizzare questo endpoint di rilevamento per ottenere il set di chiavi web JSON (JWKS), che fornisce informazioni sulla chiave pubblica che consentono di verificare le credenziali dell'account di servizio Kubernetes.

Provider di identità e pool di identità Google Cloud IAM

Google Cloud IAM supporta la federazione delle identità tramite OIDC. Tutti i cluster GKE sono configurati come provider di identità nel pool di identità del carico di lavoro PROJECT_ID.svc.id.goog.

Per ottenere il nome del pool di identità per i carichi di lavoro e dei provider, vedi Utilizzare Workload Identity con Google Cloud.

Alternative a Workload Identity

Esistono metodi alternativi per accedere ai servizi di GKE su Azure. Non consigliamo i seguenti metodi a causa di complicazioni.

  1. Esporta le credenziali e archiviale come secret di Kubernetes. In questo caso, devi ruotare manualmente le credenziali archiviate sia in Azure IAM che nel tuo cluster. Inoltre, se un utente malintenzionato ruba le credenziali, può sfruttarle.

  2. Collega le credenziali alle istanze sottostanti dei pool di nodi. In questo caso, tutti i carichi di lavoro in esecuzione sullo stesso nodo condividono le credenziali, il che può comportare un insieme di autorizzazioni più elevato di quello necessario per i carichi di lavoro. Per bloccare l'accesso alle autorizzazioni di un'istanza, i cluster GKE bloccano l'accesso da un pod al servizio di metadati dell'istanza.

Passaggi successivi