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.
- Per ulteriori informazioni sulla federazione delle identità per i carichi di lavoro in altri ambienti, consulta Federazione delle identità per i carichi di lavoro.
- Per abilitare e utilizzare la federazione di Workload Identity per GKE, consulta Accedere alle API Google Cloud dai carichi di lavoro GKE.
- Per fornire supporto per la federazione di Workload Identity per i cluster nei parchi risorse, utilizza identità dei carichi di lavoro del parco risorse.
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.googIl 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 essereprincipaloprincipalSeta 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_UIDseleziona 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 l'account di servizio per nome:
principal://iam.googleapis.com/projects/
Sostituisci quanto segue:
Seleziona l'account di servizio per UID: principal://iam.googleapis.com/projects/
Sostituisci quanto segue:
|
| 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:
|
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:
- Credenziali predefinite dell'applicazione (ADC) richiede un token di accesso a Google Cloud al server di metadati di Compute Engine in esecuzione sulla VM.
- 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.
- 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.
- 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.
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:
|
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.
Utilizza l'account di servizio predefinito di Compute Engine dei nodi. Puoi eseguire i pool di nodi come qualsiasi account di servizio IAM nel progetto. Se non specifichi un account di servizio durante la creazione del pool di nodi, GKE utilizza l'account di servizio predefinito di Compute Engine per il progetto. L'account di servizio Compute Engine è condiviso da tutti i carichi di lavoro di cui è stato eseguito il deployment su quel nodo. Ciò può comportare un provisioning eccessivo delle autorizzazioni, il che viola il principio del privilegio minimo ed è inappropriato per i cluster multi-tenant.
Esporta le chiavi degli account di servizio e archiviale come segreti Kubernetes montati nei pod come volumi.
Passaggi successivi
- Scopri come abilitare e configurare la federazione di Workload Identity per GKE.
- Scopri di più sul server metadati di Compute Engine.