La federazione delle identità per i carichi di lavoro per GKE è il metodo consigliato per i carichi di lavoro in esecuzione Google Kubernetes Engine (GKE) per accedere ai servizi Google Cloud in modo sicuro più facilmente gestibile.
La federazione delle identità per i carichi di lavoro per GKE è disponibile tramite IAM Federazione delle identità per i carichi di lavoro, che fornisce identità per i carichi di lavoro in esecuzione in ambienti interni ed esterni a Google Cloud. Puoi utilizzare la federazione delle identità per i carichi di lavoro IAM per autenticarti in modo sicuro alle API Google Cloud supportate dai carichi di lavoro in esecuzione su, ad esempio, AWS, Azure e Kubernetes autogestiti. In GKE, Google Cloud gestisce il pool e il provider di identità per i carichi di lavoro per te 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 attivare e utilizzare Workload Identity Federation per GKE, consulta Accedere alle API Google Cloud dai carichi di lavoro GKE.
- Per fornire il supporto della federazione di Workload Identity per i cluster nei parchi risorse, utilizza l'identità del carico di lavoro del parco risorse.
Terminologia
Questa pagina distingue tra Account di servizio Kubernetes e gli account di servizio Identity and Access Management (IAM).
- 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 delle identità per i carichi di lavoro per GKE?
Le applicazioni in esecuzione su GKE potrebbero richiedere l'accesso API Google Cloud, ad esempio API Compute Engine, API BigQuery Storage o API per il machine learning.
La federazione delle identità per i carichi di lavoro per GKE consente di utilizzare i criteri IAM per concedere I carichi di lavoro Kubernetes nel tuo cluster GKE accedono a specifiche API Google Cloud senza necessità di configurazione manuale o meno sicure come i file delle chiavi degli account di servizio. Utilizzo La federazione delle identità per i carichi di lavoro per GKE consente di assegnare identità e per ogni applicazione nel tuo cluster.
La federazione delle identità per i carichi di lavoro per GKE sostituisce la necessità di utilizzare Occultamento dei metadati. I metadati sensibili protetti dal mascheramento 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 le seguenti:
Crea un pool di identità per i carichi di lavoro fisso per il progetto Google Cloud del cluster con il seguente formato:
PROJECT_ID.svc.id.googIl pool di identità per i carichi di lavoro fornisce un formato di denominazione che consente IAM per comprendere e considerare attendibili le credenziali Kubernetes. GKE non elimina questo pool di identità di carico di lavoro anche se elimini tutti i cluster del progetto.
Registra il cluster GKE come provider di identità nel nel pool di identità per i carichi di lavoro.
Esegue il deployment del server di metadati GKE, che intercetta le richieste di credenziali dai carichi di lavoro, su ogni nodo.
Creare criteri di autorizzazione IAM nelle risorse Google Cloud
Per fornire l'accesso con la federazione delle identità per i carichi di lavoro per GKE, devi creare una configurazione IAM
criterio di autorizzazione che concede l'accesso a una risorsa Google Cloud specifica
a un'entità che corrisponde all'identità della tua applicazione. Ad esempio,
puoi concedere autorizzazioni di lettura su un bucket Cloud Storage a tutti i pod che
utilizzano l'database-reader account di servizio Kubernetes.
Per un elenco delle risorse che supportano i criteri di autorizzazione, consulta Tipi di risorse che accettano i criteri di autorizzazione.
Utilizza le condizioni nei criteri IAM
Puoi anche limitare l'ambito dell'accesso impostando le condizioni nel tuo di autorizzazione. Le condizioni sono un metodo estensibile per specificare quando un'istanza norme. Ad esempio, puoi utilizzare le condizioni per concedere l'accesso temporaneo a un carico di lavoro su una risorsa Google Cloud specifica, eliminando la necessità di gestire l'accesso manualmente.
Le condizioni potrebbero essere utili anche se imposti i criteri di autorizzazione a livello di progetto, a livello di cartella o organizzazione anziché su risorse specifiche come Secret di Secret Manager o bucket Cloud Storage.
Per aggiungere una condizione al criterio di autorizzazione, utilizza le seguenti risorse:
- Gestisci le associazioni di ruoli condizionali: aggiungi, modifica o rimuovi le associazioni di ruoli condizionali.
- Configura l'accesso temporaneo: utilizza le condizioni per impostare l'accesso con scadenza alle risorse Google Cloud nei criteri di autorizzazione.
- Tag e accesso condizionale: utilizza le condizioni solo quando le risorse hanno tag specifici.
Le seguenti espressioni di esempio sono per scenari comuni in cui potresti utilizzare le condizioni di traffico. Per un elenco degli attributi disponibili nelle espressioni, vedi Riferimento degli attributi per le condizioni IAM.
| Espressioni di condizione di esempio | ||
|---|---|---|
| Consentire l'accesso prima dell'ora specificata | request.time < timestamp('Sostituisci |
|
| Consenti l'accesso se per la risorsa nella richiesta è specificato il tag | resource.matchTag('Sostituisci quanto segue:
|
|
Riferimento alle risorse Kubernetes nei criteri IAM
Nel criterio IAM, fai riferimento a una risorsa Kubernetes utilizzando un identificatore principale IAM per selezionarla. Questo identificatore ha la seguente sintassi:
PREFIX://iam.googleapis.com/projects/1234567890/locations/global/workloadIdentityPools/example-project.svc.id.goog/SELECTOR
In questo esempio, prendi in considerazione i seguenti campi:
PREFIX: deve essereprincipaloprincipalSeta seconda sulla risorsa selezionata.principalè relativo a una risorsa specifica, ad esempio un singolo ServiceAccount.principalSetè per più risorse che appartengono alla risorsa specificata, ad esempio tutti i pod in un cluster specifico.SELECTOR: una stringa che seleziona un tipo di entità. Per esempio:kubernetes.serviceaccount.uid/SERVICEACCOUNT_UIDseleziona un ServiceAccount tramite il 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 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 uno spazio dei nomi, indipendentemente 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 Google Cloud, vengono eseguiti i seguenti passaggi di autenticazione:
- Le credenziali predefinite dell'applicazione (ADC)chiedono un token di accesso a Google Cloud dal server di metadati Compute Engine in esecuzione sulla VM.
- Il server metadati GKE intercetta la richiesta di token e chiede al server API Kubernetes un token ServiceAccount Kubernetes che identifichi il carico di lavoro che effettua la richiesta. Questa credenziale è un token web JSON (JWT) firmato dal server API.
- Il server di metadati GKE utilizza Security Token Service per scambiare il JWT con un token di accesso federato a Google Cloud di breve durata che fa riferimento e l'identità del carico di lavoro Kubernetes.
- Il server di metadati GKE fornisce il token di accesso federato al carico di lavoro.
Il carico di lavoro può quindi accedere a qualsiasi API Google Cloud a cui può accedere l'identificatore principale IAM del carico di lavoro.
Identicità dell'identità
Se i metadati nell'identificatore principale sono gli stessi per i carichi di lavoro in più cluster che condividono un pool di identità dei 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 questo accesso a cluster specifici utilizzando criteri IAM condizionali.
Ad esempio, considera il seguente diagramma. I cluster A e B 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 sia del cluster A sia del
cluster B come se fossero la stessa identità. IAM non fa distinzione tra
dei cluster che effettuano le chiamate.
Questa identità uguale significa anche che devi essere in grado di considerare attendibile ogni cluster
in un pool di identità di carico di lavoro specifico. Ad esempio, se un nuovo cluster, il cluster C
nell'esempio precedente, era di proprietà di un team non attendibile, questo poteva creare un
spazio dei nomi backend e accedere alle API Google Cloud utilizzando l'account di servizioback-ksa, proprio come i cluster A e B.
Per evitare l'accesso non attendibile, posiziona i cluster in progetti distinti per assicurarti che ricevano pool di identità di carico di lavoro diversi o assicurati che i nomi degli spazi dei nomi siano distinti tra loro per evitare un identificatore principale 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 metadati GKE è un sottoinsieme degli endpoint del server metadati Compute Engine obbligatori per i carichi di lavoro Kubernetes.
Il server di metadati GKE viene eseguito come DaemonSet, con un pod attivato
ogni nodo Linux o un servizio Windows nativo su ogni nodo Windows della
in un cluster Kubernetes. Il server dei 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 metadati Compute Engine disponibili con il server metadati GKE. Per un elenco completo degli endpoint disponibili nel server di 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 tuo nodo. |
id |
L'ID univoco del tuo nodo. |
service-accounts/ |
Una directory dei service account associati al nodo. Per ogni di account di servizio, sono disponibili le seguenti informazioni:
|
zone |
La zona Compute Engine del tuo nodo GKE. |
Attributi istanza
Gli attributi delle istanze vengono memorizzati nella seguente directory.
http://metadata.google.internal/computeMetadata/v1/instance/attributes/
| Voce | Descrizione |
|---|---|
cluster-location |
La zona o la regione Compute Engine del cluster. |
cluster-name |
Il nome del cluster GKE. |
cluster-uid |
L'UID del cluster GKE. |
Metadati di progetto
I metadati del 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. |
Limitazioni di Workload Identity Federation per GKE
Non puoi modificare il nome del pool di identità 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 a endpoint di metadati, ad eccezione dei pod in esecuzione alla tua rete host.
Il server di metadati GKE impiega alcuni secondi per iniziare ad accettare su un pod appena creato. Di conseguenza, il tentativo di Autenticare tramite la federazione delle identità per i carichi di lavoro per GKE entro i primi secondi di vita di un pod non riuscito. Riprovare a effettuare la chiamata risolverà il problema. Per ulteriori dettagli, consulta la sezione Risoluzione dei problemi.
Gli agenti di logging e monitoraggio integrati di GKE continuano a utilizzare account di servizio di Node.
La federazione delle identità per i carichi di lavoro per GKE richiede la configurazione manuale per Knative serving continua a rilasciare le metriche delle richieste.
La federazione delle identità per i carichi di lavoro per GKE imposta un limite di 200 connessioni di metadati per ciascun nodo, in modo da evitare problemi di memoria. Potresti riscontrare timeout se i tuoi nodi superano questo limite.
Workload Identity Federation for GKE per i 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 dei metadati GKE utilizza risorse di memoria proporzionali al numero totale di account di servizio Kubernetes nel cluster. Se le tue un cluster ha più di 3000 account di servizio Kubernetes, e terminare i pod del server di metadati. Per le misure di mitigazione, consulta la sezione Risoluzione dei problemi.
Alternative a Workload Identity Federation per GKE
Per accedere alle API Google Cloud da GKE, puoi utilizzare una delle seguenti alternative a Workload Identity Federation for GKE. Ti consigliamo di utilizzare Federazione delle identità per i carichi di lavoro per GKE perché queste alternative richiedono di verificare compromessi in termini di sicurezza.
Utilizza l'account di servizio predefinito di Compute Engine dei tuoi nodi. Puoi eseguire i pool di nodi come qualsiasi account di servizio IAM nel tuo progetto. Se non specifichi un account di servizio durante il pool di nodi creazione, 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 implementati su quel nodo. Ciò può comportare un over-provisioning delle autorizzazioni, che viola il principio del privilegio minimo ed è inappropriato per i cluster multi-tenant.
Esporta le chiavi dell'account di servizio e archiviale come secret Kubernetes da montare nei pod come volumi.
Passaggi successivi
- Scopri come attivare e configurare Workload Identity Federation per GKE.
- Scopri di più sul server di metadati di Compute Engine.