Questa pagina spiega Workload Identity Federation per GKE, incluso il funzionamento, l'impatto dell'attivazione sui cluster GKE e come concedere i ruoli alle entità Kubernetes nei criteri di Identity and Access Management. Nella maggior parte dei casi, la federazione delle identità per i carichi di lavoro per GKE è il metodo consigliato per consentire ai carichi di lavoro in esecuzione su GKE di accedere ai servizi Google Cloud in modo sicuro e gestibile.
Questa pagina è rivolta a operatori e a esperti di sicurezza che gestiscono i carichi di lavoro su GKE che richiedono l'accesso ad altri servizi Google Cloud . Per scoprire di più su i ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud , consulta Ruoli e attività comuni per gli utenti di GKE Enterprise.
Prima di leggere questa pagina, assicurati di conoscere le seguenti risorse:
- Per scoprire di più sulla federazione di Workload Identity in altri ambienti, consulta Federazione di Workload Identity.
- Per attivare 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 di Workload Identity per i cluster nei parchi risorse, utilizza l'identità del workload del parco risorse.
Terminologia
Questa pagina distingue 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'è Workload Identity Federation for GKE?
Le applicazioni in esecuzione su GKE potrebbero dover accedere alle API di Google Cloud , come l'API Compute Engine, l'API BigQuery Storage o le API di machine learning.
La federazione delle identità dei carichi di lavoro per GKE ti consente di utilizzare i criteri IAM per concedere ai carichi di lavoro Kubernetes nel tuo cluster GKE l'accesso a API specifiche diGoogle Cloud senza dover eseguire la configurazione manuale o utilizzare metodi meno sicuri come i file di chiavi dell'account di servizio. L'utilizzo di Workload Identity Federation per GKE ti consente di assegnare identità e autorizzazioni distinte e granulari per ogni applicazione nel tuo cluster.
Workload Identity Federation for GKE elimina la necessità di utilizzare l'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.
Workload Identity Federation per GKE è disponibile tramite la federazione delle identità dei carichi di lavoro di 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 workload IAM per autenticarti in modo sicuro alle API Google Cloud supportate da 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à del carico di lavoro per te e non richiede un provider di identità esterno.
Come funziona Workload Identity Federation per GKE
Quando attivi la federazione delle identità per i carichi di lavoro per GKE su un cluster, GKE esegue quanto segue:
Crea un pool di identità di carico di lavoro fisso per il progetto Google Clouddel cluster con il seguente formato:
PROJECT_ID.svc.id.googIl pool di identità di carico di lavoro fornisce un formato di denominazione che consente a IAM di 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 pool di identità del carico di lavoro.
Esegue il deployment del server di metadati GKE, che intercetta le richieste di credenziali dai carichi di lavoro, su ogni nodo.
Crea criteri di autorizzazione IAM nelle risorse Google Cloud
Per fornire l'accesso con la federazione delle identità per i carichi di lavoro per GKE, crei un criterio di autorizzazione IAM che concede l'accesso a una risorsa Google Cloud specifica a un principale 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'database-readeraccount di servizio Kubernetes.
Per un elenco delle risorse che supportano i criteri di autorizzazione, consulta Tipi di risorse che accettano i criteri di autorizzazione.
Utilizzare le condizioni nei criteri IAM
Puoi anche limitare l'ambito dell'accesso impostando le condizioni nei criteri di autorizzazione. Le condizioni sono un metodo estendibile per specificare quando deve essere applicata una norma di autorizzazione. Ad esempio, puoi utilizzare le condizioni per concedere l'accesso temporaneo a un carico di lavoro su una risorsa specifica di Google Cloud , eliminando la necessità di gestire l'accesso manualmente.
Le condizioni possono essere utili anche se imposti i criteri di autorizzazione a livello di progetto, cartella o organizzazione anziché su risorse specifiche come i secret di Secret Manager o i 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 per applicare i criteri di autorizzazione solo quando le risorse hanno tag specifici.
Le seguenti espressioni di esempio sono per scenari comuni in cui potresti utilizzare le condizioni. Per un elenco degli attributi disponibili nelle espressioni, consulta Riferimento agli 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 la risorsa nella richiesta ha il tag specificato | resource.matchTag('Sostituisci quanto segue:
|
|
Fare riferimento alle risorse Kubernetes nelle policy IAM
Nel criterio IAM, fai riferimento a una risorsa Kubernetes utilizzando un identificatore dell'entità 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 della risorsa selezionata.principalè per una risorsa specifica, come un singolo account di servizio.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 principale. Ad esempio,kubernetes.serviceaccount.uid/SERVICEACCOUNT_UIDseleziona un ServiceAccount in base al relativo UID.
La tabella seguente mostra i tipi di principali supportati in GKE:
| Tipo di identificatore principale | Sintassi |
|---|---|
| Tutti i pod che utilizzano un account di servizio Kubernetes specifico | 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 workload 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 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 workload che effettua la richiesta. Questa credenziale è un token web JSON (JWT) firmato dal server API.
- Il server dei metadati GKE utilizza Security Token Service per scambiare il JWT con un token di accesso federato di breve durata che fa riferimento all'identità del workload Kubernetes.
Il token di accesso federato restituito da Security Token Service potrebbe avere limitazioni quando si tenta di accedere ad alcuni servizi Google Cloud , come descritto in Prodotti supportati e limitazioni. Se il servizio Google Cloud selezionato presenta limitazioni, puoi eventualmente configurare l'usurpazione di identità dell'account di servizio. Questo metodo genera un token di accesso per un account di servizio IAM che il tuo carico di lavoro può utilizzare per accedere al servizio di destinazione. Per maggiori dettagli, consulta Collegare gli account servizio Kubernetes a IAM.
Il carico di lavoro può quindi accedere a qualsiasi API Google Cloud a cui può accedere l'identificatore principale IAM del carico di lavoro.
Identità uguale
Se i metadati nell'identificatore principale sono gli stessi per i workload in più cluster che condividono un pool di identità di workload perché appartengono allo stesso progetto Google Cloud , IAM identifica questi workload 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à di workload. Google Cloud identifica le applicazioni che utilizzano l'account back-ksa Service nel nome backend dello spazio dei nomi sia del cluster A sia del cluster B come se avessero la stessa identità. IAM non fa distinzione tra i 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
backend spazio dei nomi e accedere alle API Google Cloud utilizzando il back-ksa
Account servizio, 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 workload 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 di un GKE con la federazione delle identità per i carichi di lavoro per GKE abilitata archivia i propri metadati sul server metadati GKE. Il server metadati GKE è un sottoinsieme degli endpoint del server metadati Compute Engine obbligatori per i carichi di lavoro Kubernetes.
Il server metadati GKE viene eseguito come DaemonSet, con un pod su ogni nodo Linux o un servizio Windows nativo su ogni nodo Windows del cluster. 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 esce mai dall'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 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 tuo 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 attiva il server metadati GKE su un pool di nodi, i pod non possono più accedere al server metadati Compute Engine. Il server metadati GKE intercetta invece le richieste effettuate da questi pod agli endpoint dei metadati, ad eccezione dei pod in esecuzione sulla rete dell'host.
Il server metadati GKE impiega alcuni secondi per iniziare ad accettare richieste su un pod appena creato. Pertanto, i tentativi di autenticazione tramite Workload Identity Federation for GKE nei primi secondi di vita di un pod potrebbero non riuscire. Riprovare a effettuare la chiamata risolverà il problema. Per ulteriori dettagli, consulta la sezione Risoluzione dei problemi.
Gli agenti di monitoraggio e logging integrati di GKE continuano a utilizzare l'account di servizio del nodo.
Workload Identity Federation for GKE richiede la configurazione manuale di Knative serving per continuare a rilasciare le metriche delle richieste.
Workload Identity Federation for GKE imposta un limite di 200 connessioni al server metadati GKE per ogni nodo per 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 il tuo cluster ha più di 3000 account di servizio Kubernetes, kubelet potrebbe terminare i pod del server di metadati. Per le misure di mitigazione, consulta la sezione Risoluzione dei problemi.
Alternative a Workload Identity Federation for GKE
Puoi utilizzare una delle seguenti alternative alla federazione delle identità per i carichi di lavoro per GKE per accedere alle API diGoogle Cloud da GKE. Ti consigliamo di utilizzare la federazione delle identità per i carichi di lavoro per GKE perché queste alternative richiedono determinati 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 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 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 metadati di Compute Engine.