Informazioni sulla federazione di Workload Identity per GKE


La federazione delle identità per i carichi di lavoro per GKE è il modo consigliato per consentire ai carichi di lavoro in esecuzione su Google Kubernetes Engine (GKE) di accedere ai servizi di Google Cloud in modo sicuro e gestibile.

La federazione delle identità per i carichi di lavoro per GKE è disponibile tramite la federazione delle identità per i carichi di lavoro IAM, che fornisce identità per i carichi di lavoro eseguiti in ambienti interni ed esterni a Google Cloud. Puoi utilizzare la federazione di IAM Workload Identity per eseguire l'autenticazione in modo sicuro nelle API Google Cloud supportate dai carichi di lavoro in esecuzione su, ad esempio AWS, Azure e Kubernetes autogestito. In GKE, Google Cloud gestisce per te il pool di identità per i carichi di lavoro e il provider e non richiede un provider di identità esterno.

Terminologia

Questo documento fa una distinzione tra account di servizio Kubernetes e account di servizio IAM (Identity and Access Management).

Account di servizio Kubernetes
Risorse Kubernetes che forniscono un'identità per i processi in esecuzione nei tuoi pod GKE.
Account di servizio IAM
Risorse Google Cloud che consentono alle applicazioni di effettuare chiamate autorizzate alle API Google Cloud.

Che cos'è la federazione di Workload Identity per GKE?

Le applicazioni in esecuzione su GKE potrebbero dover accedere alle API Google Cloud, ad esempio API Compute Engine, API BigQuery Storage o API Machine Learning.

La federazione di Workload Identity per GKE ti consente di utilizzare i criteri IAM per concedere ai carichi di lavoro Kubernetes nel tuo cluster GKE l'accesso a specifiche API Google Cloud senza bisogno di configurazione manuale o metodi meno sicuri come i file delle chiavi dell'account di servizio. L'utilizzo della federazione delle identità di Workload per GKE consente di assegnare identità e autorizzazioni distinte e granulari per ogni applicazione nel tuo cluster.

La federazione delle identità per i carichi di lavoro per GKE sostituisce la necessità di utilizzare l'occultamento dei metadati. I metadati sensibili protetti dall'occultamento dei metadati sono protetti anche dalla Federazione delle identità per i carichi di lavoro per GKE.

Come funziona la federazione di Workload Identity per GKE

Quando abiliti la federazione di Workload Identity per GKE su un cluster, GKE fa quanto segue:

  • Crea un pool di identità per il carico di lavoro fisso per il progetto Google Cloud del cluster nel formato seguente:

    PROJECT_ID.svc.id.goog
    

    Il pool di identità per i carichi di lavoro fornisce un formato di denominazione che consente a IAM di comprendere e considerare attendibili le credenziali di Kubernetes.

  • Registra il cluster GKE come provider di identità nel pool di identità del carico di lavoro.

  • Esegue il deployment del server metadati GKE, che intercetta le richieste di credenziali dei carichi di lavoro su ogni nodo.

Creazione di criteri di autorizzazione IAM sulle risorse Google Cloud

Per fornire l'accesso con la federazione delle identità per i carichi di lavoro per GKE, devi creare un criterio di autorizzazione IAM che conceda l'accesso su una specifica risorsa Google Cloud a un'entità corrispondente all'identità della tua applicazione. Ad esempio, puoi concedere autorizzazioni di lettura su un bucket Cloud Storage a tutti i pod che utilizzano l'account di servizio Kubernetes database-reader.

Per un elenco delle risorse che supportano i criteri di autorizzazione, vedi Tipi di risorse che accettano i criteri di autorizzazione.

Puoi anche limitare l'ambito dell'accesso impostando delle conditions nei criteri di autorizzazione. Ad esempio, se vuoi concedere l'accesso in lettura su un bucket solo ai pod che utilizzano l'account di servizio database-reader nel cluster mysql, puoi impostare questa condizione nel criterio di autorizzazione. Per scoprire di più sull'utilizzo delle condizioni nei criteri di autorizzazione, consulta Gestire le associazioni di ruoli condizionali.

Riferimento alle risorse Kubernetes nei criteri IAM

Nel criterio IAM, fai riferimento a una risorsa Kubernetes utilizzando un identificatore entità IAM per selezionare la risorsa. La sintassi di questo identificatore è la seguente:

PREFIX://iam.googleapis.com/projects/1234567890/locations/global/workloadIdentityPools/example-project.svc.id.goog/SELECTOR

In questo esempio, considera i seguenti campi:

  • PREFIX: deve essere principal o principalSet a seconda della risorsa selezionata. principal è per una risorsa specifica, ad esempio un singolo ServiceAccount. principalSet è per più risorse appartenenti alla risorsa specificata, come tutti i pod in un cluster specifico.
  • SELECTOR: una stringa che seleziona un tipo di entità. Ad esempio, kubernetes.serviceaccount.uid/SERVICEACCOUNT_UID seleziona un ServiceAccount in base al relativo UID.

La tabella seguente mostra i tipi di entità supportati in GKE:

Tipo di identificatore entità Sintassi
Tutti i pod che utilizzano uno specifico ServiceAccount Kubernetes Seleziona ServiceAccount per nome:

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

Sostituisci quanto segue:

  • PROJECT_NUMBER: il numero numerico del tuo progetto. Per ottenere il numero del progetto, consulta Identificazione dei progetti.
  • PROJECT_ID: il tuo ID progetto Google Cloud.
  • NAMESPACE: lo spazio dei nomi di Kubernetes.
  • SERVICEACCOUNT: il nome Kubernetes ServiceAccount.

Seleziona l'account di servizio per UID:

principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/kubernetes.serviceaccount.uid/SERVICEACCOUNT_UID

Sostituisci quanto segue:

  • PROJECT_NUMBER: il numero numerico del tuo progetto. Per ottenere il numero del progetto, consulta Identificazione dei progetti.
  • PROJECT_ID: il tuo ID progetto Google Cloud.
  • SERVICEACCOUNT_UID: l'UID dell'oggetto ServiceAccount nel server API.
Tutti i pod in un cluster specifico

principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/kubernetes.cluster/https://container.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME

Sostituisci quanto segue:

  • PROJECT_NUMBER: il numero numerico del tuo progetto. Per ottenere il numero del progetto, consulta Identificazione dei progetti.
  • PROJECT_ID: il tuo ID progetto Google Cloud.
  • CLUSTER_NAME: il nome del tuo cluster GKE.
  • LOCATION: la località del cluster.

Flusso delle credenziali

Quando un carico di lavoro invia una richiesta di accesso a un'API Google Cloud, ad esempio quando si utilizza una libreria client di Google Cloud, si verificano i seguenti passaggi di autenticazione:

  1. Credenziali predefinite dell'applicazione (ADC) richiede un token di accesso a Google Cloud al server di metadati di Compute Engine in esecuzione sulla VM.
  2. Il server di metadati GKE intercetta la richiesta di token e chiede al server API Kubernetes un token Kubernetes ServiceAccount che identifica il carico di lavoro richiedente. Questa credenziale è un token web JSON (JWT) firmato dall'autorità di certificazione (CA) del cluster.
  3. Il server metadati GKE utilizza il servizio token di sicurezza per scambiare il JWT con un token di accesso federato di Google Cloud di breve durata che fa riferimento all'identità del carico di lavoro Kubernetes.
  4. Il server metadati GKE fornisce il token di accesso federato al carico di lavoro.

Il carico di lavoro può quindi accedere a qualsiasi API Google Cloud accessibile dall'identificatore dell'entità IAM del carico di lavoro.

Identità dell'identità

Se i metadati nell'identificatore entità sono gli stessi per i carichi di lavoro in più cluster che condividono un pool di identità per i carichi di lavoro, IAM identifica questi carichi di lavoro come se fossero uguali. Ad esempio, se disponi dello stesso spazio dei nomi in due cluster e concedi l'accesso a questo spazio dei nomi in IAM, i carichi di lavoro in quello spazio dei nomi in entrambi i cluster riceveranno questo accesso. Puoi limitare questo accesso a cluster specifici utilizzando i criteri IAM condizionali.

Ad esempio, considera il diagramma seguente. I cluster A, B e C appartengono allo stesso progetto Google Cloud e, quindi, allo stesso pool di identità per i carichi di lavoro. Google Cloud identifica le applicazioni che utilizzano il ServiceAccount back-ksa nello spazio dei nomi backend del Cluster A e del Cluster B con la stessa identità. IAM non fa distinzione tra i cluster che effettuano le chiamate.

Diagramma che illustra l'identicità delle identità all'interno di un pool di identità per i carichi di lavoro
Identicità delle identità che accede alle API Google Cloud con la federazione di Workload Identity per GKE

Questa uguaglianza delle identità significa anche che devi poter considerare attendibile ogni cluster in uno specifico pool di identità per i carichi di lavoro. Ad esempio, se il cluster C nell'esempio precedente era di proprietà di un team non attendibile, potrebbe creare uno spazio dei nomi backend e accedere alle API Google Cloud utilizzando l'account di servizio back-ksa, proprio come il cluster A e il cluster B.

Per evitare un accesso non attendibile, posiziona i cluster in progetti separati per assicurarti che ricevano pool di identità per i carichi di lavoro diversi oppure assicurati che i nomi degli spazi dei nomi siano distinti tra loro per evitare un identificatore entità comune.

Informazioni sul server di metadati GKE

Ogni nodo in GKE in cui è abilitata la federazione di Workload Identity per GKE archivia i propri metadati nel server metadati GKE. Il server di metadati GKE è un sottoinsieme degli endpoint del server di metadati di Compute Engine necessari per i carichi di lavoro Kubernetes.

Il server di metadati GKE viene eseguito come DaemonSet, con un pod su ogni nodo Linux o un servizio Windows nativo su ogni nodo Windows nel cluster. Il server di metadati intercetta le richieste HTTP su http://metadata.google.internal (169.254.169.254:80). Ad esempio, la richiesta GET /computeMetadata/v1/instance/service-accounts/default/token recupera un token per l'account di servizio IAM che il pod è configurato per impersonare. Il traffico verso il server di metadati GKE non lascia mai l'istanza VM che ospita il pod.

Le seguenti tabelle descrivono il sottoinsieme di endpoint dei server di metadati di Compute Engine disponibili con il server di metadati GKE. Per un elenco completo degli endpoint disponibili nel server metadati di Compute Engine, consulta Valori predefiniti dei metadati della VM.

Metadati dell'istanza

I metadati dell'istanza vengono archiviati nella seguente directory.

http://metadata.google.internal/computeMetadata/v1/instance/

Voce Descrizione
hostname

Il nome host del nodo.

id

L'ID univoco del nodo.

service-accounts/

Una directory di account di servizio associati al nodo. Per ogni account di servizio sono disponibili le seguenti informazioni:

  • aliases
  • email: l'indirizzo email dell'account di servizio.
  • identity: un token JWT (JSON Web Token) univoco del nodo. Devi includere il parametro audience nella richiesta. Ad esempio: ?audience=http://www.example.com.
  • scopes: gli ambiti di accesso assegnati all'account di servizio.
  • token: il token di accesso OAuth 2.0 per autenticare i carichi di lavoro.
zone

La zona Compute Engine del tuo nodo GKE.

Attributi istanza

Gli attributi dell'istanza vengono archiviati nella seguente directory.

http://metadata.google.internal/computeMetadata/v1/instance/attributes/

Voce Descrizione
cluster-location

La zona o la regione di Compute Engine del cluster.

cluster-name

Il nome del tuo cluster GKE.

cluster-uid

L'UID del tuo cluster GKE.

Metadati di progetto

I metadati del progetto del cluster vengono archiviati nella seguente directory.

http://metadata.google.internal/computeMetadata/v1/project/

Voce Descrizione
project-id

L'ID del tuo progetto Google Cloud.

numeric-project-id

Il numero del tuo progetto Google Cloud.

Limitazioni della federazione delle identità per i carichi di lavoro per GKE

  • Non puoi modificare il nome del pool di identità per i carichi di lavoro creato da GKE per il tuo progetto Google Cloud.

  • Quando GKE abilita il server di metadati GKE su un pool di nodi, i pod non possono più accedere al server di metadati di Compute Engine. Il server di metadati GKE intercetta invece le richieste effettuate da questi pod agli endpoint di metadati, ad eccezione dei pod in esecuzione sulla rete host.

  • Il server metadati GKE inizia ad accettare richieste per un pod appena creato in pochi secondi. Di conseguenza, i tentativi di autenticazione mediante la federazione di Workload Identity per GKE entro i primi secondi di vita di un pod potrebbero non riuscire. Riprova a chiamare per risolvere il problema. Per maggiori dettagli, consulta la sezione Risoluzione dei problemi.

  • Gli agenti di logging e monitoraggio integrati di GKE continuano a utilizzare l'account di servizio del nodo.

  • La federazione delle identità per i carichi di lavoro per GKE richiede la configurazione manuale di Cloud Run for Anthos per continuare a rilasciare metriche delle richieste.

  • La federazione di Workload Identity per GKE imposta un limite di 200 connessioni al server di metadati di GKE per ogni nodo al fine di evitare problemi di memoria. Si possono verificare timeout se i nodi superano questo limite.

  • La federazione delle identità per i carichi di lavoro per GKE per nodi di Windows Server è disponibile nelle versioni di GKE 1.18.16-gke.1200, 1.19.8-gke.1300, 1.20.4-gke.1500 e successive.

  • Il server di metadati GKE utilizza risorse di memoria in proporzione al numero totale di account di servizio Kubernetes nel cluster. Se il tuo cluster ha più di 3000 account di servizio Kubernetes, il kubelet potrebbe terminare i pod del server di metadati. Per le mitigazioni, consulta Risoluzione dei problemi.

Alternative alla federazione di Workload Identity per GKE

Puoi utilizzare una delle seguenti alternative alla federazione delle identità per i carichi di lavoro per GKE per accedere alle API Google Cloud da GKE. Ti consigliamo di utilizzare Workload Identity Federation per GKE, perché queste alternative richiedono determinate compromissioni della sicurezza.

Passaggi successivi