Questa pagina è stata tradotta dall'API Cloud Translation.

Configurare la federazione delle identità per i workload con Kubernetes

Questa guida descrive come utilizzare la federazione delle identità per i carichi di lavoro per consentire ai carichi di lavoro eseguiti su Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service o su un cluster Kubernetes autogestito di autenticarsi su Google Cloud.

Kubernetes ti consente di configurare un cluster in modo che i carichi di lavoro possano ottenere token ServiceAccount Kubernetes da un volume proiettato. Se configuri la federazione delle identità per i carichi di lavoro, puoi consentire ai workload di utilizzare questi token ServiceAccount Kubernetes per l'autenticazione su Google Cloud.

Se utilizzi GKE, utilizza Workload Identity Federation for GKE anziché configurare la federazione delle identità per i carichi di lavoro.

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:

GKE

Per gli utenti di Google Kubernetes Engine (GKE), consulta Autenticarsi alle Google Cloud API dai carichi di lavoro GKE.

AKS

Assicurati che il cluster soddisfi i seguenti criteri:

Hai attivato la funzionalità Emittente OIDC.

Devi abilitare questa funzionalità in modo che la federazione delle identità dei carichi di lavoro possa accedere ai metadati OpenID Connect e al set di chiavi web JSON (JWKS) per il cluster.

EKS

Non è necessario apportare modifiche alla configurazione di EKS.

Kubernetes

Assicurati che il cluster soddisfi i seguenti criteri:

Stai eseguendo Kubernetes 1.20 o versioni successive.

Le versioni precedenti di Kubernetes utilizzavano un formato di token ServiceAccount diverso che non è compatibile con le istruzioni riportate in questo documento.
Hai configurato kube-apiserver in modo che supporti le proiezioni sul volume dei token ServiceAccount.

Il cluster non deve essere accessibile tramite internet.

Configura la federazione delle identità per i workload

Devi eseguire questi passaggi una sola volta per ogni cluster Kubernetes. Puoi quindi utilizzare lo stesso pool e lo stesso provider di identità del workload per più pod Kubernetes e in più progetti Google Cloud .

Per iniziare a configurare la federazione delle identità per i workload:

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

Go to project selector

utilizzare un progetto dedicato per gestire i pool e i fornitori di identità del workload

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

Definisci un mapping degli attributi e una condizione

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

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

Per utilizzare sub come identificatore del soggetto (google.subject) in Google Cloud, utilizza il seguente mapping:

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']

(Facoltativo) Definisci una condizione dell'attributo. Le condizioni degli attributi sono espressioni CEL che possono controllare gli attributi dell'asserzione e gli attributi di destinazione. Se la condizione dell'attributo restituisce true per una determinata credenziale, la credenziale viene accettata. In caso contrario, la credenziale viene rifiutata.

Puoi utilizzare una condizione dell'attributo per limitare quali service account Kubernetes possono utilizzare la federazione delle identità per i carichi di lavoro per ottenere token Google Clouddi 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 fornitore e il pool di identità del workload

Ruoli obbligatori

Per ottenere le autorizzazioni necessarie per configurare la federazione delle identità per i carichi di lavoro, chiedi all'amministratore di concederti i seguenti ruoli IAM nel progetto:

Amministratore del pool di identità dei carichi di lavoro (roles/iam.workloadIdentityPoolAdmin)
Amministratore account di servizio (roles/iam.serviceAccountAdmin)

Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.

Potresti anche riuscire a ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.

In alternativa, il ruolo di base Proprietario IAM (roles/owner) include anche le autorizzazioni per configurare la federazione delle identità. Non devi concedere ruoli di base in un ambiente di produzione, ma puoi concederli in un ambiente di sviluppo o di test.

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

AKS

Determina l'URL dell'emittente del tuo cluster AKS:
```
az aks show -n NAME -g RESOURCE_GROUP --query "oidcIssuerProfile.issuerUrl" -otsv
```
Sostituisci quanto segue:
- NAME: il nome del cluster
- RESOURCE_GROUP: Il gruppo di risorse del cluster
Il comando restituisce l'URL dell'emittente. L'URL dell'emittente ti servirà in uno dei passaggi successivi.

Se il comando non restituisce un URL dell'emittente, verifica di aver attivato la funzionalità Emittente OIDC.
Crea un nuovo pool di identità del workload:
```
gcloud iam workload-identity-pools create POOL_ID \
    --location="global" \
    --description="DESCRIPTION" \
    --display-name="DISPLAY_NAME"
```
Sostituisci quanto segue:
- POOL_ID: l'ID univoco del pool.
- DISPLAY_NAME: il nome del pool.
- DESCRIPTION: una descrizione del pool che scegli. Questa descrizione viene visualizzata quando concedi l'accesso alle identità del pool.
Aggiungi il cluster AKS come fornitore del pool di identità del workload:
```
gcloud iam workload-identity-pools providers create-oidc WORKLOAD_PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="POOL_ID" \
    --issuer-uri="ISSUER" \
    --attribute-mapping="MAPPINGS" \
    --attribute-condition="CONDITIONS"
```
Sostituisci quanto segue:
- WORKLOAD_PROVIDER_ID: un ID fornitore del pool di identità del workload univoco a tua scelta.
- POOL_ID: l'ID del pool di identità del workload che hai creato in precedenza.
- ISSUER: l'URI dell'emittente che hai determinato in precedenza.
- MAPPINGS: un elenco separato da virgole di mappature degli attributi che hai creato in precedenza in questa guida.
- CONDITIONS: una condizione dell'attributo facoltativa che hai creato in precedenza in questa guida. Rimuovi il parametro se non hai una condizione dell'attributo.

EKS

Determina l'URL dell'emittente del tuo cluster EKS:
```
aws eks describe-cluster --name NAME --query "cluster.identity.oidc.issuer" --output text
```
Sostituisci NAME con il nome del cluster.

Il comando restituisce l'URL dell'emittente. L'URL dell'emittente ti servirà in uno dei passaggi successivi.
Crea un nuovo pool di identità del workload:
```
gcloud iam workload-identity-pools create POOL_ID \
    --location="global" \
    --description="DESCRIPTION" \
    --display-name="DISPLAY_NAME"
```
Sostituisci quanto segue:
- POOL_ID: l'ID univoco del pool.
- DISPLAY_NAME: il nome del pool.
- DESCRIPTION: una descrizione del pool che scegli. Questa descrizione viene visualizzata quando concedi l'accesso alle identità del pool.
Aggiungi il cluster EKS come fornitore del pool di identità del workload:
```
gcloud iam workload-identity-pools providers create-oidc WORKLOAD_PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="POOL_ID" \
    --issuer-uri="ISSUER" \
    --attribute-mapping="MAPPINGS" \
    --attribute-condition="CONDITIONS"
```
Sostituisci quanto segue:
- WORKLOAD_PROVIDER_ID: un ID fornitore del pool di identità del workload univoco a tua scelta.
- POOL_ID: l'ID del pool di identità del workload che hai creato in precedenza.
- ISSUER: l'URI dell'emittente che hai determinato in precedenza.
- MAPPINGS: un elenco separato da virgole di mappature degli attributi che hai creato in precedenza in questa guida.
- CONDITIONS: una condizione dell'attributo facoltativa che hai creato in precedenza in questa guida. Rimuovi il parametro se non hai una condizione dell'attributo.

Kubernetes

Connettiti al cluster Kubernetes e utilizza kubectl per determinare l'URL dell'emittente del cluster:
```
kubectl get --raw /.well-known/openid-configuration | jq -r .issuer
```
L'URL dell'emittente ti servirà in uno dei passaggi successivi.
Scarica il set di chiavi web JSON (JWKS) del cluster:
```
kubectl get --raw /openid/v1/jwks > cluster-jwks.json
```
In uno dei passaggi successivi, caricherai il JWKS in modo che la federazione delle identità per i carichi di lavoro possa verificare l'autenticità dei token ServiceAccount Kubernetes emessi dal tuo cluster.
Crea un nuovo pool di identità del workload:
```
gcloud iam workload-identity-pools create POOL_ID \
    --location="global" \
    --description="DESCRIPTION" \
    --display-name="DISPLAY_NAME"
```
Sostituisci quanto segue:
- POOL_ID: l'ID univoco del pool.
- DISPLAY_NAME: il nome del pool.
- DESCRIPTION: una descrizione del pool che scegli. Questa descrizione viene visualizzata quando concedi l'accesso alle identità del pool.
Aggiungi il cluster Kubernetes come provider di pool di identità del workload e carica il JWKS del cluster:
```
gcloud iam workload-identity-pools providers create-oidc WORKLOAD_PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="POOL_ID" \
    --issuer-uri="ISSUER" \
    --attribute-mapping="MAPPINGS" \
    --attribute-condition="CONDITIONS" \
    --jwk-json-path="cluster-jwks.json"
```
Sostituisci quanto segue:
- WORKLOAD_PROVIDER_ID: un ID fornitore del pool di identità del workload univoco a tua scelta.
- POOL_ID: l'ID del pool di identità del workload che hai creato in precedenza.
- ISSUER: l'URI dell'emittente che hai determinato in precedenza.
- MAPPINGS: un elenco separato da virgole di mappature degli attributi che hai creato in precedenza in questa guida.
- CONDITIONS: una condizione dell'attributo facoltativa che hai creato in precedenza in questa guida. Rimuovi il parametro se non hai una condizione dell'attributo.
Nota: il comando non convalida JWKS del cluster. Se JWKS è danneggiato o scaduto, i tentativi di autenticazione successivi potrebbero non riuscire con il messaggio di errore Error connecting to the given credential's issuer.

Concedere l'accesso a un carico di lavoro Kubernetes

Questa sezione descrive come configurare un workload Kubernetes per accedere alle APIGoogle Cloud utilizzando l'accesso diretto alle risorse della federazione delle identità per i workload o la simulazione dell'identità del 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 presentare 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 invece la rappresentazione IAM.

Utilizzare la federazione delle identità per i workload per concedere l'accesso diretto alle risorse

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

Per creare un service account Kubernetes e concedergli un ruolo:

Crea un ServiceAccount Kubernetes:
```
kubectl create serviceaccount KSA_NAME --namespace NAMESPACE
```
Sostituisci quanto segue:
- KSA_NAME: un nome del service account.
- NAMESPACE: lo spazio dei nomi in cui creare ServiceAccount.
Concedi l'accesso IAM al service account Kubernetes per una risorsaGoogle Cloud .

Seguendo il principio del privilegio minimo, ti 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) al service account che hai creato. Il comando utilizza l'oggetto che hai 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 di progettoGoogle Cloud numerico associato all'ID progetto.
- POOL_ID: l'ID del pool di identità del workload.
- MAPPED_SUBJECT: il service account Kubernetes dalla rivendicazione nel token ID 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", allora MAPPED_SUBJECT è system:serviceaccount:default:my-kubernetes-serviceaccount.
Puoi concedere ruoli su qualsiasi risorsa Google Cloud che supporta i criteri di autorizzazione IAM. La sintassi dell'identificatore dell'entità dipende dalla risorsa Kubernetes. Per un elenco degli identificatori supportati, vedi Identificatori principal per la federazione delle identità per i carichi di lavoro per GKE.

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

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

Per configurare il tuo ServiceAccount Kubernetes in modo da utilizzare la rappresentazione dell'account di servizio IAM:

Crea un ServiceAccount Kubernetes, se non l'hai ancora fatto:
```
kubectl create serviceaccount KSA_NAME --namespace NAMESPACE
```
Sostituisci quanto segue:
- KSA_NAME: un nome per ServiceAccount
- NAMESPACE: lo spazio dei nomi in cui creare il ServiceAccount
Crea un service account IAM che rappresenta il workload.

L'account di servizio non deve trovarsi nello stesso progetto del pool di identità del workload, 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 del account di servizio
- IAM_SA_PROJECT_ID: l'ID progetto del service account
Concedi al account di servizio IAM l'accesso alle risorse Google Cloud specifiche a cui vuoi che il carico di lavoro Kubernetes acceda.
```
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 del account di servizio
- ROLE: con il nome del ruolo, ad esempio roles/container.clusterViewer
Concedi all'account di servizio Kubernetes l'accesso per rappresentare il service account 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 del account di servizio
- PROJECT_ID: l'ID del progetto in cui esegui Kubernetes
- IAM_SA_PROJECT_NUMBER: il numero di progetto del progetto in cui hai creato il account di servizio
- POOL_ID: l'ID del pool di identità del workload.
- MAPPED_SUBJECT: il service account Kubernetes dalla rivendicazione nel token ID 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", allora MAPPED_SUBJECT è system:serviceaccount:default:my-kubernetes-serviceaccount.
Nota: devi utilizzare il numero di progetto nell'identificatore del membro. L'utilizzo dell'ID progetto non è supportato.

Per informazioni sull'autorizzazione degli account di servizio IAM ad accedere alle APIGoogle Cloud , consulta Informazioni sui service account.

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

Esegui il deployment del workload Kubernetes

Per eseguire il deployment di un carico di lavoro Kubernetes che può accedere alle risorse Google Cloud , procedi nel seguente modo:

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 di progetto 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 del account di servizio, se hai configurato il service account Kubernetes per utilizzare la rappresentazione del account di servizio IAM. Ometti questo flag se hai configurato il tuo ServiceAccount 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:
- Dove ottenere le credenziali esterne
- Quale fornitore e pool di identità del workload utilizzare
- Quale account di servizio rappresentare
Nota: a differenza di una chiave dell'account di servizio, un file di configurazione delle credenziali non contiene una chiave privata e non deve essere mantenuto riservato. I dettagli sul file di configurazione delle credenziali sono disponibili all'indirizzo https://google.aip.dev/auth/4117.
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 di ConfigMap.
- NAMESPACE: lo spazio dei nomi in cui creare ConfigMap.
Esegui il deployment di un carico di lavoro e consentigli di utilizzare ServiceAccount e ConfigMap di 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 ServiceAccount Kubernetes da un file locale. Configura il volume in modo che il token ServiceAccount di Kubernetes utilizzi il pubblico previsto dal provider del pool di identità del workload.
- Monta ConfigMap che contiene il file di configurazione delle credenziali in modo che il workload possa accedere alla configurazione necessaria per utilizzare la federazione delle identità per i workload.
- Aggiungi una variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS che contiene il percorso del file di configurazione delle credenziali in modo che i carichi di lavoro possano trovare il file.
Di seguito è riportato un manifest di esempio che utilizza ServiceAccount e ConfigMap di Kubernetes per consentire a Google Cloud CLI di autenticarsi a 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 a strumenti e carichi di lavoro che utilizzano una delle seguenti librerie client di trovare automaticamente le credenziali:
C++
Le librerie client per C++ supportano la federazione delle identità per i workload a partire dalla versione v2.6.0.Google Cloud Per utilizzare la federazione delle identità per i carichi di lavoro, devi creare le librerie client con gRPC versione 1.36.0 o successive.
Vai
Le librerie client per Go supportano la federazione delle identità per i carichi 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 delle identità per i carichi di lavoro se utilizzano la versione 0.24.0 o successive dell'artefatto com.google.auth:google-auth-library-oauth2-http.

Per controllare quale versione di questo artefatto utilizza la 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à per i carichi di lavoro se utilizzano la versione 7.0.2 o successive del pacchettogoogle-auth-library.

Per controllare quale versione di questo pacchetto utilizza la tua libreria client, esegui questo comando nella directory dell'applicazione:
```
npm list google-auth-library
```
Quando crei un oggetto GoogleAuth, puoi specificare un ID progetto oppure consentire a GoogleAuth di trovare automaticamente l'ID progetto. Per trovare automaticamente l'ID progetto, il account di servizio nel file di configurazione deve disporre del ruolo Browser (roles/browser) o di un ruolo con autorizzazioni equivalenti per il tuo progetto. Per maggiori dettagli, consulta i README per il pacchetto google-auth-library.
Python
Le librerie client per Python supportano la federazione delle identità per i carichi di lavoro 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 comando seguente 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 ambiente GOOGLE_CLOUD_PROJECT oppure puoi 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 per il tuo 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 per la federazione delle identità per i workload in gcloud CLI è disponibile nella versione 363.0.0 e successive di gcloud CLI.
Terraform
Il Google Cloud provider supporta la federazione delle identità per i carichi di lavoro se utilizzi la versione 3.61.0 o successive:
```
terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 3.61.0"
    }
  }
}
```
bq
Per l'autenticazione tramite la federazione delle identità per i carichi di lavoro, 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 gcloud CLI.
(Facoltativo) Verifica che l'autenticazione funzioni correttamente eseguendo questo comando:
```
kubectl exec example --namespace NAMESPACE -- gcloud auth print-access-token
```

Passaggi successivi

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

Configurare la federazione delle identità per i workload con Kubernetes Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Prima di iniziare

GKE

AKS

EKS

Kubernetes

Configura la federazione delle identità per i workload

Definisci un mapping degli attributi e una condizione

Crea il fornitore e il pool di identità del workload

Ruoli obbligatori

AKS

EKS

Kubernetes

Concedere l'accesso a un carico di lavoro Kubernetes

Utilizzare la federazione delle identità per i workload per concedere l'accesso diretto alle risorse

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

Esegui il deployment del workload Kubernetes

C++

Vai

Java

Node.js

Python

gcloud

Terraform

bq

Passaggi successivi

Configurare la federazione delle identità per i workload con Kubernetes