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 Federazione delle identità per carichi di lavoro IAM per eseguire l'autenticazione sicura in API Google Cloud supportate dai carichi di lavoro in esecuzione, ad esempio AWS, Azure e Kubernetes autogestito. In GKE, Google Cloud gestisce il pool di identità per i carichi di lavoro e il provider 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 abilitare e utilizzare la federazione delle identità per i carichi di lavoro per GKE, consulta Accedi 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 Fleet Workload Identity.
Terminologia
Questo documento 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 le 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 dall'occultamento dei metadati sono protetti anche da 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 Google Cloud del cluster progetto 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.
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.
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 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
usa 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 le condizioni nel tuo
di autorizzazione. Ad esempio, se vuoi concedere solo l'accesso in lettura su un bucket
ai pod che utilizzano l'account di servizio database-reader nel cluster mysql,
puoi impostarla nel criterio di autorizzazione. Per informazioni sull'utilizzo
le 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 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 essereprincipaloprincipalSeta seconda sulla risorsa selezionata.principalsi riferisce a una risorsa specifica, ad esempio un singolo ServiceAccount.principalSetè per più risorse che appartengono a della risorsa specificata, come 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 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 utilizzi una libreria client di Google Cloud, le seguenti modalità di vengono eseguiti i seguenti passaggi:
- Credenziali predefinite dell'applicazione (ADC) richiede un token di accesso Google Cloud a Compute Engine di metadati in esecuzione sulla VM.
- Il server di metadati GKE intercetta la richiesta di token e chiede il server API Kubernetes per un token ServiceAccount Kubernetes identifica il carico di lavoro richiedente. 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 L'identificatore dell'entità IAM del carico di lavoro può accedere.
Identicità dell'identità
Se i metadati nell'identificatore dell'entità sono gli stessi per i carichi di lavoro in più cluster che condividono un pool di identità per i carichi di lavoro perché appartengono stesso progetto Google Cloud, IAM identifica i carichi di lavoro sono gli stessi. Ad esempio, se hai lo stesso spazio dei nomi in due cluster e concedere l'accesso a quello spazio dei nomi in IAM, i carichi di lavoro in entrambi i cluster ricevono questo accesso. Puoi limitare questo accesso a specifici mediante criteri IAM condizionali.
Ad esempio, considera il seguente diagramma. I cluster A e B appartengono
lo stesso pool di identità per i carichi di lavoro. Google Cloud identifica le applicazioni che utilizzano
ServiceAccount back-ksa nello spazio dei nomi backend sia del Cluster A che
Cluster B della stessa identità. IAM non fa distinzione tra
dei cluster che effettuano le chiamate.
Questa uguaglianza delle identità significa anche che è necessario poter considerare attendibile ogni cluster
in uno specifico pool di identità per i carichi di lavoro. Ad esempio, se un nuovo cluster, Cluster C
dell'esempio precedente era di proprietà di un team non attendibile,
backend e accedi alle API Google Cloud utilizzando lo spazio dei nomi back-ksa
ServiceAccount, proprio come il Cluster A e il Cluster B.
Per evitare l'accesso non attendibile, posiziona i cluster in progetti separati per assicurarti in modo che ricevano pool di identità per i carichi di lavoro diversi o assicurano che lo spazio dei nomi sono 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. Lo strumento GKE per i metadati è un sottoinsieme Endpoint del server di metadati di Compute Engine richiesta 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 a 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 tabelle seguenti descrivono il sottoinsieme del server di metadati di Compute Engine disponibili con il server metadati GKE. Per un elenco completo di endpoint disponibili nel server di metadati di Compute Engine, consulta 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 di 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 Workload Identity che GKE crea 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 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. Per risolvere il problema, riprova a telefonare. Consulta la sezione Risoluzione dei problemi. per ulteriori dettagli.
Gli agenti di logging e monitoraggio integrati di GKE continuano a utilizzare l'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. Potrebbero verificarsi timeout se i nodi superano questo limite.
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 versioni successive.
Il server di metadati GKE utilizza le risorse di memoria proporzionalmente il 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 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 le API Google Cloud di 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 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 di cui è stato eseguito il deployment su quel nodo. Ciò può causare un provisioning eccessivo delle autorizzazioni, che viola il principio del privilegio minimo ed è inappropriato per le istanze multi-tenant cluster.
Esporta le chiavi degli account di servizio e archivia come Secret di Kubernetes che puoi montare 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.