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, Workload Identity Federation for GKE è il metodo consigliato per consentire ai workload in esecuzione su GKE di accedere ai Google Cloud servizi in modo sicuro e gestibile.
Questa pagina è rivolta a operatori e addetti alla sicurezza che gestiscono i workload su GKE che richiedono l'accesso ad altri servizi. Google Cloud Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei Google Cloud contenuti, consulta Ruoli e attività utente comuni 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 Workload Identity Federation for 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 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
- Google Cloud risorse che consentono alle applicazioni di effettuare chiamate autorizzate alleGoogle Cloud API.
Che cos'è Workload Identity Federation for GKE?
Le applicazioni in esecuzione su GKE potrebbero richiedere l'accesso alle Google Cloud API, come l'API Compute Engine, l'API BigQuery Storage o le API di machine learning.
La federazione delle identità per i 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 APIGoogle Cloud specifiche senza bisogno di configurazione manuale o 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 for GKE è disponibile tramite la federazione delle identità per i carichi di lavoro di IAM, che fornisce identità per i carichi di lavoro eseguiti in ambienti interni ed esterni 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, ad esempio, su 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.
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à del workload 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 sulle Google Cloud risorse
Per fornire l'accesso con la federazione delle identità per i carichi di lavoro per GKE, devi creare una policy di autorizzazione IAM che conceda l'accesso a una Google Cloud risorsa specifica
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'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 Google Cloud specifica, 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 carico di lavoro invia una richiesta di accesso a un' Google Cloud API, ad esempio quando si utilizza una Google Cloud libreria client, vengono eseguiti i seguenti passaggi di autenticazione:
- Le credenziali predefinite dell'applicazione (ADC)chiedono un Google Cloud token di accesso al 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 carico di lavoro Kubernetes.
Il token di accesso federato restituito da Security Token Service potrebbe avere limitazioni quando si tenta di accedere ad alcuni Google Cloud servizi, come descritto in Prodotti supportati e limitazioni. Se il servizio Google Cloud selezionato presenta limitazioni, puoi eventualmente configurare la simulazione dell'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 Google Cloud API 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 carichi di lavoro in più cluster che condividono un pool di identità del workload perché appartengono allo stesso Google Cloud progetto, 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 in questo 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 il servizio account 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 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
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 workload diversi o assicurati che i nomi degli spazi dei nomi siano distinti tra loro per evitare un identificatore principale comune.
Server 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 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. |
Gli attributi elencati nella tabella sono gli unici supportati. Se provi ad accedere ad attributi non supportati, il pod gke-metadata-server nel nome spazio kube-system genera e registra un errore 404.
L'errore è simile al seguente:
HTTP/404: generic::not_found: no child "", Reason: "NOT_FOUND", UserMessage: "Not Found"
Se utilizzi istio-proxy, visualizzerai un messaggio di errore simile al seguente:
Error fetching GCP Metadata property gcp_gce_instance_template: metadata: GCE metadata "instance/attributes/UNSUPPORTED_ATTRIBUTE" not defined
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 |
Il tuo Google Cloud ID progetto. |
numeric-project-id |
Il tuo Google Cloud numero di progetto. |
Limitazioni di Workload Identity Federation per GKE
Non puoi modificare il nome del pool di identità per i carichi di lavoro creato da GKE per il tuo Google Cloud progetto.
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 a Workload Identity Federation for GKE per accedere alle APIGoogle 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.