Configurare la federazione delle identità per i workload con Kubernetes

Questa guida descrive come utilizzare la federazione Workload Identity per consentire ai carichi di lavoro in esecuzione su Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service o su un cluster Kubernetes auto-inserito di autenticarsi su Google Cloud.

Kubernetes ti consente di configurare un cluster in modo che i carichi di lavoro possano ottenere token Kubernetes ServiceAccount da un volume proiettato. Con la configurazione della federazione Workload Identity, puoi consentire ai workload di utilizzare questi token account di servizio Kubernetes per autenticarsi su Google Cloud.

Se utilizzi GKE, utilizza Workload Identity Federation for GKE instead of configuring Workload Identity Federation.

Prima di iniziare

Prima di configurare la federazione delle identità per i carichi di lavoro, assicurati che il tuo cluster Kubernetes soddisfi i seguenti criteri:

Configurare la federazione delle identità per i carichi di lavoro

Questa procedura deve essere eseguita una sola volta per ogni cluster Kubernetes. Puoi quindi utilizzare lo stesso provider e lo stesso pool di identità di workload per più pod Kubernetes e in più progetti Google Cloud.

Per iniziare a configurare la federazione delle identità per i carichi di lavoro, segui questi passaggi:

1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Go to project selector

Ti consigliamo di utilizzare un progetto dedicato per gestire i provider e i pool di identità per i carichi di lavoro.

2. Make sure that billing is enabled for your Google Cloud project.

Enable the IAM, Resource Manager, Service Account Credentials, and Security Token Service APIs.

Enable the APIs

Definire una mappatura degli attributi e una condizione

I token ServiceAccount di Kubernetes contengono più rivendicazioni, tra cui:

• sub: contiene lo spazio dei nomi e il nome dell'account ServiceAccount, ad esempio system:serviceaccount:NAMESPACE:KSA_NAME, dove NAMESPACE è lo spazio dei nomi dell'account ServiceAccount e KSA_NAME è il nome dell'account ServiceAccount.
• "kubernetes.io".namespace: contiene lo spazio dei nomi dell'account di servizio.
• "kubernetes.io".serviceaccount.name: contiene il nome dell'account di servizio.
• "kubernetes.io".pod.name: contiene il nome del pod.

Per utilizzare sub come identificatore dell'oggetto (google.subject) in Google Cloud, utilizza la seguente mappatura:

google.subject=assertion.sub

Se vuoi, puoi mappare altri attributi. Puoi quindi fare riferimento a questi attributi quando concedi l'accesso alle risorse. Ad esempio:

google.subject=assertion.sub,
attribute.namespace=assertion['kubernetes.io']['namespace'],
attribute.service_account_name=assertion['kubernetes.io']['serviceaccount']['name'],
attribute.pod=assertion['kubernetes.io']['pod']['name']

Se vuoi, definisci una condizione dell'attributo. Le condizioni degli attributi sono espressioni CEL che possono controllare gli attributi di asserzione e gli attributi di destinazione. Se la condizione dell'attributo ha valore true per una determinata credenziale, la credenziale viene accettata. In caso contrario, le credenziali vengono rifiutate.

Puoi utilizzare una condizione dell'attributo per limitare gli account di servizio Kubernetes che possono utilizzare la federazione delle identità per i carichi di lavoro per ottenere token Google Cloud di breve durata. Ad esempio, la seguente condizione limita l'accesso ai service account Kubernetes dagli spazi dei nomi backend e monitoring:

assertion['kubernetes.io']['namespace'] in ['backend', 'monitoring']

Crea il provider e il pool di identità del workload

Per creare un fornitore e un pool di identità del workload:

Concedere l'accesso a un carico di lavoro Kubernetes

Questa sezione descrive come configurare un carico di lavoro Kubernetes per accedere alle API Google Cloud utilizzando l'accesso diretto alle risorse della federazione Workload Identity o la simulazione dell'identità dell'account di servizio.

Devi eseguire questi passaggi una volta per ogni carico di lavoro Kubernetes che deve accedere a Google Cloud.

Ti consigliamo di utilizzare la federazione di Workload Identity. Tuttavia, quando utilizzi la federazione delle identità, alcuni metodi API potrebbero avere limitazioni. Per un elenco delle limitazioni, consulta Federazione delle identità: prodotti e limitazioni.

Se i metodi utilizzati dal tuo carico di lavoro presentano queste limitazioni, puoi utilizzare la sostituzione dell'identità IAM.

Utilizzare la federazione delle identità per i carichi di lavoro per concedere l'accesso diretto alle risorse

In questa sezione utilizzi la federazione delle identità di lavoro per concedere un ruolo IAM a un servizio account Kubernetes in modo che possa accedere direttamente alle risorse Google Cloud.

Per creare un account di servizio Kubernetes e concedergli un ruolo, segui questi passaggi:

1. Crea un account di servizio Kubernetes:

   kubectl create serviceaccount KSA_NAME --namespace NAMESPACE
   

   Sostituisci quanto segue:

   • KSA_NAME: un nome del servizio account.
   • NAMESPACE: lo spazio dei nomi in cui creare l'account di servizio.

2. Concedi l'accesso IAM all'account di servizio Kubernetes per una risorsa Google Cloud.

   In base al principio del privilegio minimo, consigliamo di concedere solo i ruoli specifici per le risorse a cui deve accedere la tua applicazione.

   Nell'esempio seguente, il comando concede il ruolo Visualizzatore cluster Kubernetes Engine (roles/container.clusterViewer) all'account di servizio che hai creato. Il comando utilizza l'oggetto mappato in precedenza in questo documento.

   gcloud projects add-iam-policy-binding projects/PROJECT_ID \
       --role=roles/container.clusterViewer \
       --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/MAPPED_SUBJECT \
       --condition=None
   

   Sostituisci quanto segue:

   • PROJECT_NUMBER: il numero numerico del progetto Google Cloud associato al tuo ID progetto.

   • POOL_ID: l'ID del pool di identità del workload.

   • MAPPED_SUBJECT: l'account di servizio Kubernetes dall'affermazione nel token di identità che hai mappato a google.subject. Ad esempio, se hai mappato google.subject=assertions.sub e il tuo token ID contiene "sub": "system:serviceaccount:default:my-kubernetes-serviceaccount", MAPPED_SUBJECT è system:serviceaccount:default:my-kubernetes-serviceaccount.

   Puoi concedere ruoli a qualsiasi risorsa Google Cloud che supporta i criteri di autorizzazione IAM. La sintassi dell'identificatore principale dipende dalla risorsa Kubernetes. Per un elenco degli identificatori supportati, consulta Identificatori principali per Workload Identity Federation per GKE.

Ora puoi eseguire il deployment di un carico di lavoro che utilizza il servizio account Kubernetes per accedere alle risorse Google Cloud a cui hai concesso l'accesso.

Alternativa: utilizza la simulazione dell'identità dell'account di servizio IAM per concedere l'accesso

Per configurare l'account di servizio Kubernetes in modo da utilizzare l'usurpazione di identità dell'account di servizio IAM, segui questi passaggi:

1. Se non l'hai ancora fatto, crea un account di servizio Kubernetes:

   kubectl create serviceaccount KSA_NAME --namespace NAMESPACE
   

   Sostituisci quanto segue:

   • KSA_NAME: un nome per l'account di servizio
   • NAMESPACE: il nome dello spazio dei nomi in cui creare l'account di servizio

2. Crea un account di servizio IAM che rappresenti il carico di lavoro.

   L'account di servizio non deve trovarsi nello stesso progetto del pool di identità del carico di lavoro, ma devi specificare il progetto che contiene l'account di servizio quando fai riferimento a quest'ultimo.

   gcloud iam service-accounts create IAM_SA_NAME \
       --project=IAM_SA_PROJECT_ID
   

   Sostituisci quanto segue:

   • IAM_SA_NAME: il nome dell'account di servizio
   • IAM_SA_PROJECT_ID: l'ID progetto dell'account di servizio

3. Concedi all'account di servizio IAM l'accesso alle risorse Google Cloud specifiche a cui vuoi che acceda il workload Kubernetes.

   gcloud projects add-iam-policy-binding IAM_SA_PROJECT_ID \
       --member="serviceAccount:IAM_SA_NAME@IAM_SA_PROJECT_ID.iam.gserviceaccount.com" \
       --role="ROLE"
   

   Sostituisci quanto segue:

   • IAM_SA_PROJECT_ID: l'ID del progetto in cui hai creato l'account di servizio
   • IAM_SA_NAME: il nome dell'account di servizio
   • ROLE: con il nome del ruolo, ad esempio roles/container.clusterViewer

4. Concedi all'account di servizio Kubernetes l'accesso per rubare l'identità dell'account di servizio IAM:

   gcloud iam service-accounts add-iam-policy-binding \
     IAM_SA_NAME@IAM_SA_PROJECT_ID.iam.gserviceaccount.com \
       --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/MAPPED_SUBJECT" \
       --role=roles/iam.workloadIdentityUser
   
   

   Sostituisci quanto segue:

   • IAM_SA_NAME: il nome dell'account di servizio
   • PROJECT_ID: l'ID del progetto in cui esegui Kubernetes
   • IAM_SA_PROJECT_NUMBER: il numero del progetto del progetto in cui hai creato l'account di servizio
   • POOL_ID: l'ID del pool di identità del workload.
   • MAPPED_SUBJECT: l'account di servizio Kubernetes dall'affermazione nel token di identità che hai mappato a google.subject. Ad esempio, se hai mappato google.subject=assertions.sub e il tuo token ID contiene "sub": "system:serviceaccount:default:my-kubernetes-serviceaccount", MAPPED_SUBJECT è system:serviceaccount:default:my-kubernetes-serviceaccount.

   Per informazioni sull'autorizzazione degli account di servizio IAM ad accedere alle API Google Cloud, consulta Informazioni sugli account di servizio.

Ora puoi eseguire il deployment di un workload che utilizza l'account di servizio Kubernetes e l'account di servizio IAM per accedere alle risorse Google Cloud a cui hai concesso l'accesso.

Esegui il deployment del carico di lavoro Kubernetes

Per eseguire il deployment di un carico di lavoro Kubernetes che può accedere alle risorse Google Cloud, svolgi quanto segue:

1. Crea un file di configurazione delle credenziali:

   gcloud iam workload-identity-pools create-cred-config \
       projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/WORKLOAD_PROVIDER_ID \
       --service-account=SERVICE_ACCOUNT_EMAIL \
       --credential-source-file=/var/run/service-account/token \
       --credential-source-type=text \
       --output-file=credential-configuration.json

   Sostituisci quanto segue:

   • PROJECT_NUMBER: il numero del progetto che contiene il pool di identità del workload
   • POOL_ID: l'ID del pool di identità del workload
   • WORKLOAD_PROVIDER_ID: l'ID del fornitore del pool di identità del workload
   • SERVICE_ACCOUNT_EMAIL: indirizzo email dell'account di servizio, se hai configurato il tuo account di servizio Kubernetes per utilizzare l'usurpazione dell'identità dell'account di servizio IAM. Ometti questo flag se hai configurato l'account di servizio Kubernetes per utilizzare l'accesso diretto alle risorse.

   Il file di configurazione delle credenziali consente alle librerie client Cloud, all'gcloud CLI e a Terraform di determinare quanto segue:

   • Da dove ottenere le credenziali esterne
   • Quale provider e pool di identità per i carichi di lavoro utilizzare
   • Quale account di servizio rappresentare

2. Importa il file di configurazione delle credenziali come ConfigMap

   kubectl create configmap CONFIGMAP_NAME \
     --from-file credential-configuration.json \
     --namespace NAMESPACE
   

   Sostituisci quanto segue:

   • CONFIGMAP_NAME: il nome del ConfigMap.
   • NAMESPACE: lo spazio dei nomi in cui creare il ConfigMap.

3. Esegui il deployment di un carico di lavoro e consenti di utilizzare il service account e il ConfigMap Kubernetes.

   Crea un manifest e configuralo nel seguente modo:

   • Monta un volume di token proiettato in modo che il carico di lavoro possa ottenere un token dell'account di servizio Kubernetes da un file locale. Configura il volume in modo che il token del servizio account Kubernetes utilizzi il segmento di pubblico previsto dal provider del pool di identità del tuo workload.
   • Monta il ConfigMap contenente il file di configurazione delle credenziali in modo che il carico di lavoro possa accedere alla configurazione necessaria per utilizzare la federazione delle identità per i carichi di lavoro.
   • Aggiungi una variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS che contenga il percorso del file di configurazione delle credenziali in modo che i carichi di lavoro possano trovarlo.

   Di seguito è riportato un esempio di manifest che utilizza ServiceAccount e ConfigMap di Kubernetes per consentire a Google Cloud CLI di autenticarsi in Google Cloud:

   apiVersion: v1
   kind: Pod
   metadata:
     name: example
     namespace: NAMESPACE
   spec:
     containers:
     - name: example
       image: google/cloud-sdk:alpine
       command: ["/bin/sh", "-c", "gcloud auth login --cred-file $GOOGLE_APPLICATION_CREDENTIALS && gcloud auth list && sleep 600"]
       volumeMounts:
       - name: token
         mountPath: "/var/run/service-account"
         readOnly: true
       - name: workload-identity-credential-configuration
         mountPath: "/etc/workload-identity"
         readOnly: true
       env:
       - name: GOOGLE_APPLICATION_CREDENTIALS
         value: "/etc/workload-identity/credential-configuration.json"
   
     serviceAccountName: KSA_NAME
     volumes:
     - name: token
       projected:
         sources:
         - serviceAccountToken:
             audience: https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/WORKLOAD_PROVIDER_ID
             expirationSeconds: 3600
             path: token
     - name: workload-identity-credential-configuration
       configMap:
         name: CONFIGMAP_NAME

   Puoi seguire lo stesso approccio per consentire agli strumenti e ai carichi di lavoro che utilizzano una delle seguenti librerie client di trovare automaticamente le credenziali:

   C++

   Le librerie client di Google Cloud per C++ supportano la federazione delle identità per i carichi di lavoro dalla versione v2.6.0. Per utilizzare la federazione delle identità per i carichi di lavoro, devi compilare le librerie client con la versione 1.36.0 o successive di gRPC.

   Vai

   Le librerie client per Go supportano la federazione delle identità del carico di lavoro se utilizzano la versione v0.0.0-20210218202405-ba52d332ba99 o successive del modulo golang.org/x/oauth2.

   Per controllare quale versione di questo modulo utilizza la tua libreria client, esegui i seguenti comandi:

   cd $GOPATH/src/cloud.google.com/go
   go list -m golang.org/x/oauth2
   

   Java

   Le librerie client per Java supportano la federazione di Workload Identity se utilizzano la versione 0.24.0 o successive dell'elemento com.google.auth:google-auth-library-oauth2-http.

   Per controllare la versione di questo elemento utilizzato dalla libreria client, esegui il seguente comando Maven nella directory dell'applicazione:

   mvn dependency:list -DincludeArtifactIds=google-auth-library-oauth2-http
   

   Node.js

   Le librerie client per Node.js supportano la federazione delle identità del carico di lavoro se utilizzano la versione 7.0.2 o successive del pacchetto google-auth-library.

   Per controllare quale versione di questo pacchetto utilizza la tua libreria client, esegui il seguente comando nella directory dell'applicazione:

   npm list google-auth-library
   

   Quando crei un oggetto GoogleAuth, puoi specificare un ID progetto oppure puoi consentire a GoogleAuth di trovarlo automaticamente. Per trovare automaticamente l'ID progetto, l'account di servizio nel file di configurazione deve disporre del ruolo Browser (roles/browser) o di un ruolo con autorizzazioni equivalenti nel progetto. Per maggiori dettagli, consulta il README per il pacchetto google-auth-library.

   Python

   Le librerie client per Python supportano la federazione di Workload Identity se utilizzano la versione 1.27.0 o successive del pacchetto google-auth.

   Per controllare quale versione di questo pacchetto utilizza la tua libreria client, esegui il seguente comando nell'ambiente in cui è installato il pacchetto:

   pip show google-auth
   

   Per specificare un ID progetto per il client di autenticazione, puoi impostare la variabile di ambienteGOOGLE_CLOUD_PROJECT o consentire al client di trovare automaticamente l'ID progetto. Per trovare automaticamente l'ID progetto, il service account nel file di configurazione deve disporre del ruolo Browser (roles/browser) o di un ruolo con autorizzazioni equivalenti nel progetto. Per maggiori dettagli, consulta la guida dell'utente per il pacchetto google-auth.

   gcloud

   Per eseguire l'autenticazione utilizzando la federazione delle identità per i carichi di lavoro, utilizza il comando gcloud auth login:

   gcloud auth login --cred-file=FILEPATH.json
   

   Sostituisci FILEPATH con il percorso del file di configurazione delle credenziali.

   Il supporto della federazione delle identità per i workload in gcloud CLI è disponibile nella versione 363.0.0 e successive di gcloud CLI.

   Terraform

   Il provider Google Cloud supporta la federazione delle identità di carico di lavoro se utilizzi la versione 3.61.0 o successive:

   terraform {
     required_providers {
       google = {
         source  = "hashicorp/google"
         version = "~> 3.61.0"
       }
     }
   }
   

   bq

   Per eseguire l'autenticazione utilizzando la federazione di Workload Identity, utilizza il comando gcloud auth login, come segue:

   gcloud auth login --cred-file=FILEPATH.json
   

   Sostituisci FILEPATH con il percorso del file di configurazione delle credenziali.

   Il supporto della federazione delle identità per i carichi di lavoro in bq è disponibile nella versione 390.0.0 e successive della CLI gcloud.

4. Se vuoi, verifica che l'autenticazione funzioni correttamente eseguendo il seguente comando:

   kubectl exec example --namespace NAMESPACE -- gcloud auth print-access-token

Passaggi successivi

• Scopri di più sulla federazione di Workload Identity.
• Scopri le best practice per l'utilizzo della federazione delle identità per i workload.
• Scopri come gestire i provider e i pool di identità del workload.