La federazione delle identità per i carichi di lavoro per GKE è il metodo consigliato per consentire ai carichi di lavoro in esecuzione su Google Kubernetes Engine (GKE) di accedere ai servizi 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 all'interno e all'esterno di Google Cloud. Puoi utilizzare la federazione delle identità per i carichi di lavoro IAM per eseguire l'autenticazione sicura nelle API Google Cloud supportate dai carichi di lavoro in esecuzione, ad esempio, su AWS, Azure e Kubernetes autogestito. In GKE, Google Cloud gestisce per te il pool di identità e il provider per i carichi di lavoro e non richiede un provider di identità esterno.
- Per saperne di più 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 delle identità per i carichi di lavoro per GKE, consulta Accedere alle API Google Cloud dai carichi di lavoro GKE.
- Per fornire il supporto della federazione delle identità per i carichi di lavoro per i cluster nei parchi risorse, utilizza l'identità dei carichi di lavoro del parco risorse.
Terminologia
Questo documento fa distinzione tra account di servizio Kubernetes e account di servizio Identity and Access Management (IAM).
- Account di servizio Kubernetes
- Risorse Kubernetes che forniscono un'identità per i processi in esecuzione nei 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 delle identità per i carichi di lavoro per GKE?
Le applicazioni in esecuzione su GKE potrebbero richiedere l'accesso alle API Google Cloud, come l'API Compute Engine, l'API BigQuery Storage o le API Machine Learning.
La federazione delle identità per i carichi di lavoro per GKE consente di utilizzare i criteri IAM per concedere ai carichi di lavoro Kubernetes nel cluster GKE l'accesso a specifiche API Google Cloud senza la necessità di configurazione manuale o di metodi meno sicuri come i file delle chiavi degli account di servizio. L'utilizzo della federazione delle identità per i carichi di lavoro per GKE ti 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 delle identità per i carichi di lavoro per GKE
Quando abiliti la federazione delle identità per i carichi di lavoro per GKE su un cluster, GKE esegue queste operazioni:
Crea un pool di identità per il carico di lavoro fisso per il progetto Google Cloud del cluster con il 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 Kubernetes.
Registra il cluster GKE come provider di identità nel pool di identità per i carichi di lavoro.
Esegue il deployment su ogni nodo del server di metadati GKE, che intercetta le richieste di credenziali dai carichi di lavoro.
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 concede l'accesso su una risorsa Google Cloud specifica a un'entità che corrisponde all'identità della tua applicazione. Ad esempio, potresti concedere autorizzazioni di lettura su un bucket Cloud Storage a tutti i pod che utilizzano l'account di servizio database-reader Kubernetes.
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 le 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, vedi
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. Questo identificatore ha la seguente sintassi:
PREFIX://iam.googleapis.com/projects/1234567890/locations/global/workloadIdentityPools/example-project.svc.id.goog/SELECTOR
In questo esempio, considera i seguenti campi:
PREFIX: deve essereprincipaloprincipalSet, a seconda della risorsa selezionata.principalè per una risorsa specifica, ad esempio un singolo ServiceAccount.principalSetè per più risorse che appartengono 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 un ServiceAccount specifico di Kubernetes | Seleziona l'account di servizio in base al nome:
principal://iam.googleapis.com/projects/
Sostituisci quanto segue:
Seleziona l'account di servizio in base all'UID: principal://iam.googleapis.com/projects/
Sostituisci quanto segue:
|
| Tutti i pod in uno spazio dei nomi, a prescindere dall'account di servizio o dal cluster | principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/namespace/NAMESPACE 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 di 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 Google Cloud dal server 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 ServiceAccount di Kubernetes che identifica il carico di lavoro richiedente. La credenziale è un token web JSON (JWT) firmato dal server API.
- Il server di metadati GKE utilizza il servizio token di sicurezza per scambiare il JWT con un token di accesso Google Cloud federato 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 tutte le API Google Cloud a cui può accedere l'identificatore entità IAM del carico di lavoro.
Identicità dell'identità
Se i metadati nell'identificatore dell'entità sono uguali per i carichi di lavoro in più cluster che condividono un pool di identità per i carichi di lavoro perché appartengono allo stesso progetto Google Cloud, IAM identifica questi carichi di lavoro come uguali. Ad esempio, se hai lo stesso spazio dei nomi in due cluster e concedi l'accesso a questo spazio dei nomi in IAM, i carichi di lavoro nello spazio dei nomi in entrambi i cluster ottengono questo accesso. Puoi limitare l'accesso a cluster specifici utilizzando i criteri IAM condizionali.
Ad esempio, considera il seguente diagramma. I cluster A, B e C appartengono
allo stesso pool di identità per i carichi di lavoro. Google Cloud identifica le applicazioni che utilizzano l'account di servizio back-ksa nello spazio dei nomi backend del cluster A e del cluster B come 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 l'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 con federazione delle identità per i carichi di lavoro per GKE abilitata archivia i propri metadati sul server di 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 un 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 verso 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 del 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, vedi Valori predefiniti dei metadati della VM.
Metadati dell'istanza
I metadati dell'istanza sono archiviati nella seguente directory.
http://metadata.google.internal/computeMetadata/v1/instance/
| Voce | Descrizione |
|---|---|
hostname |
Il nome host del tuo nodo. |
id |
L'ID univoco del tuo 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 sono archiviati nella seguente directory.
http://metadata.google.internal/computeMetadata/v1/instance/attributes/
| Voce | Descrizione |
|---|---|
cluster-location |
La zona o la regione Compute Engine del tuo cluster. |
cluster-name |
Il nome del tuo cluster GKE. |
cluster-uid |
L'UID del cluster GKE. |
Metadati di progetto
I metadati di progetto del cluster sono 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. |
Restrizioni 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 dei metadati, ad eccezione dei pod in esecuzione sulla rete host.
Il server di metadati GKE impiega alcuni secondi per iniziare ad accettare le richieste su un pod appena creato. Di conseguenza, i tentativi di autenticazione mediante la federazione delle identità per i carichi di lavoro per GKE potrebbero non riuscire entro i primi secondi della vita di un pod. Per risolvere il problema, riprova a telefonare. Per ulteriori dettagli, consulta 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 Knative serving per continuare a rilasciare metriche delle richieste.
La federazione delle identità per i carichi di lavoro per GKE imposta un limite di 200 connessioni al server metadati GKE per ciascun nodo, in modo da evitare problemi di memoria. Potresti riscontrare timeout se i nodi superano questo limite.
La federazione delle identità per i carichi di lavoro per GKE per nodi Windows Server è disponibile nelle versioni GKE 1.18.16-gke.1200, 1.19.8-gke.1300, 1.20.4-gke.1500 e successive.
Il server di metadati GKE utilizza le risorse di memoria in proporzione al numero totale di account di servizio Kubernetes nel cluster. Se il 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 delle identità per i carichi di lavoro 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 la federazione delle identità per i carichi di lavoro per GKE perché queste alternative richiedono determinate compromissioni per la sicurezza.
Utilizza l'account di servizio predefinito di Compute Engine dei tuoi nodi. Puoi eseguire pool di nodi come qualsiasi account di servizio IAM nel tuo 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ò causare un overprovisioning delle autorizzazioni, che viola il principio del privilegio minimo ed è inappropriato per i cluster multi-tenant.
Esporta le chiavi degli account di servizio e archiviale come secret di Kubernetes montati nei pod come volumi.
Passaggi successivi
- Scopri come abilitare e configurare la federazione delle identità per i carichi di lavoro per GKE.
- Scopri di più sul server di metadati di Compute Engine.