Informazioni su Workload Identity Federation for GKE

Questo documento descrive Workload Identity Federation for GKE, incluso il suo funzionamento, l'impatto dell'attivazione sui cluster GKE e come concedere ruoli alle entità Kubernetes nelle policy di Identity and Access Management. Nella maggior parte dei casi, Workload Identity Federation for GKE è il modo consigliato per proteggere e gestire la modalità di accesso dei carichi di lavoro eseguiti su GKE ai servizi Cloud de Confiance by S3NS .

Questo documento è destinato a specialisti e operatori della sicurezza che gestiscono carichi di lavoro su GKE che richiedono l'accesso ad altri Cloud de Confiance by S3NS servizi. Per scoprire di più sui ruoli comuni e sugli esempi di attività a cui facciamo riferimento nei contenuti di Cloud de Confiance by S3NS , consulta Ruoli e attività comuni degli utenti GKE.

Terminologia

Questa pagina distingue tra service account Kubernetes e service account di Identity and Access Management (IAM).

Service account Kubernetes

Risorse Kubernetes che forniscono un'identità per i processi in esecuzione nei pod GKE.

Service account IAM

Risorse

Cloud de Confiance by S3NS che consentono alle applicazioni di effettuare chiamate autorizzate alle APICloud de Confiance by S3NS .

Che cos'è Workload Identity Federation for GKE?

Le applicazioni in esecuzione su GKE potrebbero richiedere l'accesso alle APICloud de Confiance by S3NS , ad esempio l'API Compute Engine, l'API BigQuery Storage o le API di machine learning.

La federazione delle identità dei workload per GKE ti consente di utilizzare le policy IAM per concedere ai workload Kubernetes nel tuo cluster GKE l'accesso ad APICloud de Confiance specifiche senza dover eseguire la configurazione manuale o utilizzare metodi meno sicuri come i file delle chiavi dei account di servizio. L'utilizzo di Workload Identity Federation for GKE ti consente di assegnare l'autorizzazione e identità distinte e granulari per ogni applicazione nel tuo cluster.

Workload Identity Federation for 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.

La federazione delle identità per i workload per GKE è disponibile tramite la federazione delle identità per i workload IAM, che fornisce identità per i workload eseguiti in ambienti all'interno e all'esterno di Cloud de Confiance. Puoi utilizzare la federazione delle identità per i workload IAM per autenticarti in modo sicuro alle API Cloud de Confiance supportate dai workload in esecuzione, ad esempio, su AWS, Azure e Kubernetes autogestito. In GKE, Cloud de Confiance gestisce il fornitore e il pool di identità del workload per te e non richiede un provider di identità esterno.

Come funziona Workload Identity Federation for GKE

Quando abiliti Workload Identity Federation for GKE su un cluster, GKE esegue le seguenti operazioni:

• Crea un pool di identità del workload fisso per il progetto Cloud de Confiance by S3NS del cluster con il seguente formato:

  PROJECT_ID.s3ns.svc.id.goog
  

  Il pool di identità del workload fornisce un formato di denominazione che consente a IAM di comprendere e considerare attendibili le credenziali di Kubernetes. GKE non elimina questo pool di identità del workload anche se elimini tutti i cluster del progetto.

• Registra il cluster GKE come provider di identità nel pool di identità del workload.

• Esegue il deployment del server metadati GKE, che intercetta le richieste di credenziali dai workload, su ogni nodo.

Crea policy di autorizzazione IAM sulle risorse Cloud de Confiance

Per fornire l'accesso con Workload Identity Federation for GKE, devi creare una policy di autorizzazione IAM che conceda l'accesso a una risorsa Cloud de Confiance specifica a un'entità corrispondente all'identità della tua applicazione. Ad esempio, puoi concedere le autorizzazioni in lettura su un bucket Cloud Storage a tutti i pod che utilizzano il service account Kubernetes database-reader.

Per un elenco delle risorse che supportano le policy di autorizzazione, consulta Tipi di risorse che accettano le policy di autorizzazione.

Utilizza le condizioni nelle policy IAM

Puoi anche limitare l'ambito dell'accesso impostando condizioni nelle policy di autorizzazione. Le condizioni sono un metodo estensibile per specificare quando deve essere applicata una policy di autorizzazione. Ad esempio, puoi utilizzare le condizioni per concedere l'accesso temporaneo a un workload su una risorsa Cloud de Confiance specifica, eliminando la necessità di gestire l'accesso manualmente.

Le condizioni potrebbero essere utili anche se imposti le policy 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 alla policy 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 Cloud de Confiance nelle policy di autorizzazione.
• Tag e accesso condizionale: utilizza le condizioni per applicare le policy di autorizzazione solo quando le risorse hanno tag specifici.

Le seguenti espressioni di esempio riguardano scenari comuni in cui potresti utilizzare le condizioni. Per un elenco degli attributi disponibili nelle espressioni, consulta Riferimento agli attributi per le condizioni IAM.

request.time < timestamp('TIMESTAMP')

resource.matchTag('TAG_KEY', 'TAG_VALUE')

Fai riferimento alle risorse Kubernetes nelle policy IAM

Nella policy IAM, fai riferimento a una risorsa Kubernetes utilizzando un identificatore dell'entità IAM per selezionare la risorsa. Questo identificatore ha la seguente sintassi:

PREFIX://iam.googleapis.com/projects/1234567890/locations/global/workloadIdentityPools/example-project.s3ns.svc.id.goog/SELECTOR

In questo esempio, considera i seguenti campi:

• PREFIX: deve essere principal o principalSet a seconda della risorsa selezionata. principal è per una risorsa specifica, come un singolo ServiceAccount. principalSet è per più risorse appartenenti alla risorsa specificata, ad esempio tutti i pod in un cluster specifico.
• SELECTOR: una stringa che seleziona un tipo di entità. Ad esempio, kubernetes.serviceaccount.uid/SERVICEACCOUNT_UID seleziona un service account in base al suo UID.

La tabella seguente mostra i tipi di entità supportati in GKE:

principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.s3ns.svc.id.goog/subject/ns/NAMESPACE/sa/SERVICEACCOUNT

principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.s3ns.svc.id.goog/kubernetes.serviceaccount.uid/SERVICEACCOUNT_UID

principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.s3ns.svc.id.goog/namespace/NAMESPACE

principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.s3ns.svc.id.goog/kubernetes.cluster/https://container.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME

Flusso delle credenziali

Quando un workload invia una richiesta di accesso a un'API Cloud de Confiance , ad esempio quando utilizza una libreria client Cloud de Confiance , vengono eseguiti i seguenti passaggi di autenticazione:

1. Application Default Credentials (ADC) richiede un token di accesso Cloud de Confiance al server di metadati di Compute Engine in esecuzione sulla VM.
2. Il server di metadati GKE intercetta la richiesta di token e chiede al server API Kubernetes un token ServiceAccount Kubernetes che identifica il workload richiedente. Questa credenziale è un token web JSON (JWT) firmato dal server API.
3. 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 Cloud de Confiance , come descritto in Prodotti e limitazioni supportati. Se il servizio Cloud de Confiance selezionato presenta limitazioni, puoi facoltativamente configurare la simulazione dell'identità delaccount di serviziot. 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 Collega i ServiceAccount Kubernetes a IAM.

Il workload può quindi accedere a tutte le API Cloud de Confiance a cui può accedere l'identificatore dell'entità IAM del workload.

Quota per l'API Exchange Token in Security Token Service

L'API Exchange Token in Security Token Service ha un limite di quota di 6000 richieste al minuto. Se visualizzi errori QUOTA_EXCEEDED, puoi richiedere un aumento della quota Token exchange requests per minute tramite la pagina Quote e limiti di sistema.

Identità uguali

Se i metadati nell'identificatore dell'entità sono gli stessi per i workload in più cluster che condividono un pool di identità del workload perché appartengono allo stesso Cloud de Confiance progetto, 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 workload in questo spazio dei nomi in entrambi i cluster ottengono l'accesso. Puoi limitare questo accesso a cluster specifici utilizzando policy IAM condizionali.

Ad esempio, considera il seguente diagramma. I cluster A e B appartengono allo stesso pool di identità del workload. Cloud de Confiance identifica le applicazioni che utilizzano ServiceAccount back-ksa nello spazio dei nomi backend sia del cluster A che del cluster B come la stessa identità. IAM non distingue tra i cluster che effettuano le chiamate.

Questa equivalenza delle identità significa anche che devi essere in grado di considerare attendibile ogni cluster in un pool di identità del workload specifico. Ad esempio, se un nuovo cluster, Cluster C nell'esempio precedente, era di proprietà di un team non attendibile, questo poteva creare uno spazio dei nomi backend e accedere alle API Cloud de Confiance by S3NS utilizzando l'account di servizio back-ksa, proprio come il cluster A e il cluster B.

Per evitare accessi non attendibili, inserisci i cluster in progetti separati per assicurarti che ricevano pool di identità del workload diversi o assicurati che i nomi degli spazi dei nomi siano distinti l'uno dall'altro per evitare un identificatore di entità comune.

Server metadati GKE

Quando abiliti Workload Identity Federation for GKE per un cluster, ogni nodo del cluster memorizza i metadati sul server metadati GKE. Il server metadati GKE è un sottoinsieme degli endpoint del server metadati di Compute Engine richiesti per i workload Kubernetes.

Il server dei metadati GKE viene eseguito come 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 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 il account di servizio IAM configurato per l'impersonificazione dal pod. Il traffico verso il server di metadati GKE non lascia mai l'istanza VM che ospita il pod.

Durata del token

Per impostazione predefinita, il token di accesso restituito ha una durata di 1 ora (3600 secondi). Per ridurre la latenza del client, il server dei metadati GKE memorizza nella cache i token di accesso. In alcune situazioni, il token memorizzato nella cache restituito dal server dei metadati potrebbe essere vicino alla data di scadenza.

Le librerie client di Cloud hanno una logica integrata che, per impostazione predefinita, controlla se il token di accesso scade nei successivi 3 minuti e 45 secondi. Se il token è entro il periodo di scadenza, GKE lo aggiorna. Le chiamate API consecutive possono utilizzare il token di aggiornamento.

Se utilizzi il tuo codice per accedere direttamente alle API Cloud de Confiance , implementa una logica simile per gestire la scadenza dei token. Il codice deve:

1. Controlla se il token di accesso scade dopo un periodo di 3 minuti e 45 secondi. Il parametro exp nel payload del token indica il timestamp di scadenza del token.
2. Se il token è impostato per scadere nei prossimi 3 minuti e 45 secondi, effettua una richiesta di token.

Le tabelle seguenti descrivono il sottoinsieme di endpoint del server dei metadati di Compute Engine disponibili con il server dei metadati GKE. Per un elenco completo degli endpoint disponibili nel server di metadati di Compute Engine, consulta Valori predefiniti dei metadati delle VM.

Metadati dell'istanza

I metadati dell'istanza sono archiviati nella seguente directory.

http://metadata.google.internal/computeMetadata/v1/instance/

Attributi dell'istanza

Gli attributi dell'istanza sono archiviati nella seguente directory.

http://metadata.google.internal/computeMetadata/v1/instance/attributes/

Gli attributi elencati nella tabella sono gli unici supportati. Se tenti di accedere ad attributi non supportati, il pod gke-metadata-server nello spazio dei nomi 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/

Limitazioni della federazione delle identità per i workload per GKE

• Non puoi modificare il nome del pool di identità del workload che GKE crea per il tuo Cloud de Confiance by S3NS progetto.

• Se colleghi i ServiceAccount Kubernetes ai service account IAM per configurare Workload Identity Federation for GKE, il server dei metadati GKE restituisce un valore di SERVICEACCOUNT_NAME.s3ns.svc.id.goog come identificatore del account di servizio. Questo identificatore non utilizza la sintassi standard dell'identificatore dell'entità IAM, il che potrebbe causare errori in alcune operazioni programmatiche. Per ottenere l'identificatore del account di servizio come identificatore dell'entità IAM, aggiungi l'annotazione iam.gke.io/return-principal-id-as-email: "true" al tuo ServiceAccount Kubernetes.

• 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 metadati GKE intercetta invece le richieste effettuate da questi pod agli endpoint metadati, ad eccezione dei pod in esecuzione sulla rete host.

• Quando utilizzi il driver CSI di Cloud Storage FUSE con i cluster GKE Standard con versione 1.33.3-gke.1226000 o successive, i pod in esecuzione sulla rete host (hostNetwork: true) possono autenticarsi utilizzando il proprio service account Kubernetes. Per saperne di più, consulta Configura l'accesso per i pod con la rete host.

• Il server dei metadati GKE impiega alcuni secondi per iniziare ad accettare richieste su un pod appena creato. Pertanto, i tentativi di autenticazione utilizzando Workload Identity Federation for GKE entro i primi secondi di vita di un pod potrebbero non riuscire. Se riprovi a effettuare la chiamata, il problema verrà risolto. Per maggiori dettagli, consulta la sezione Risoluzione dei problemi.

• Gli agenti di logging e monitoraggio integrati di GKE continuano a utilizzare il service account 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 500 connessioni simultanee al server metadati GKE per ogni nodo. Le chiamate simultanee aggiuntive che superano questo limite vengono inserite in una coda di attesa per l'elaborazione successiva. Questo meccanismo di coda potrebbe causare errori HTTP/499 se il timeout del client viene raggiunto prima che il server dei metadati GKE possa elaborare la richiesta.

• Il server dei metadati GKE utilizza risorse di memoria proporzionali al numero totale di service account Kubernetes nel cluster. Se il tuo cluster ha più di 3000 service account Kubernetes, kubelet potrebbe terminare i pod del server metadati. Per le mitigazioni, consulta Risoluzione dei problemi.

• Workload Identity Federation for GKE opera all'interno di un perimetro dei Controlli di servizio VPC, consentendo l'accesso alle risorse al suo interno. Puoi anche configurare le entità di Workload Identity Federation for GKE nelle regole in entrata e in uscita dei Controlli di servizio VPC (anteprima) per consentire l'accesso tra perimetri senza richiedere la simulazione dell'identità dei account di servizio IAM intermedi.

Alternative alla federazione delle identità per i workload per GKE

Puoi utilizzare una delle seguenti alternative a Workload Identity Federation for GKE per accedere alle APICloud de Confiance by S3NS da GKE. Ti consigliamo di utilizzare Workload Identity Federation for GKE perché queste alternative richiedono di scendere a compromessi in termini di sicurezza.

• Utilizza il service account predefinito di Compute Engine dei tuoi nodi. Puoi eseguire i node pool come qualsiasi service account IAM nel tuo progetto. Se non specifichi un account di servizio durante la creazione del pool di nodi, GKE utilizza il service account predefinito di Compute Engine per il progetto. Il account di servizio Compute Engine è condiviso da tutti i workload di cui è stato eseguito il deployment sul nodo. Ciò può comportare un provisioning eccessivo delle autorizzazioni, che viola il principio del privilegio minimo ed è inappropriato per i cluster multi-tenant.

• Esporta le account di servizio account e archiviale come secret Kubernetes che monti nei pod come volumi.

Passaggi successivi

• Scopri come attivare e configurare Workload Identity Federation for GKE.
• Scopri di più sul server di metadati di Compute Engine.
• Scopri di più sulla federazione delle identità per i workload in altri ambienti.
• Fornisci il supporto della federazione delle identità per i workload per i cluster nei parchi risorse utilizzando l'identità del workload del parco risorse.