Questa pagina mostra come configurare le applicazioni per l'autenticazione le API Google Cloud come l'API Compute Engine o l'API AI Platform utilizzando Federazione delle identità per i carichi di lavoro del parco risorse.
Cos'è la federazione delle identità per i carichi di lavoro del parco risorse?
La federazione Workload Identity consente ai carichi di lavoro nei tuoi cluster di autenticarsi su Google Cloud senza che tu debba scaricare, ruotare manualmente e gestire in genere le credenziali. I carichi di lavoro si autenticano invece utilizzando token di breve durata generati da Google Cloud.
La Federazione delle identità dei carichi di lavoro per GKE fornisce un pool di identità dei carichi di lavoro a livello di progetto da cui le applicazioni in esecuzione nei cluster GKE ottengono le identità. La federazione delle identità per i carichi di lavoro del parco risorse estende la federazione delle identità per i carichi di lavoro per GKE a tutti i membri del parco risorse indipendentemente dal fatto che i cluster si trovino in progetti diversi o siano al di fuori di Google Cloud. Cluster registrati con federazione delle identità per i carichi di lavoro abilitati nell'appartenenza al parco risorse ottengono le identità utilizzando un modello a livello di flotta per i carichi di lavoro, che consente di configurare l'autenticazione alle API Google Cloud e ad altri servizi nell'intero parco risorse, in più progetti.
La federazione delle identità per i carichi di lavoro del parco risorse può essere utilizzata anche Connetti l'agente su alcuni tipi di cluster per eseguire l'autenticazione in Google Cloud come fa parte dell'appartenenza al parco risorse ed è necessario per utilizzare alcune funzionalità di GKE Enterprise che funzionano su più progetti, ad esempio Cloud Service Mesh.
Pool di Workload Identity Federation e identità uguali
Con la federazione di Workload Identity del parco risorse, ogni applicazione del parco risorse ottiene un'identità federata distinta che può essere utilizzata per autenticarsi in Google Cloud e in altri servizi che sviluppi. Le applicazioni ricevono un identificatore entità che IAM può riconoscere. Questo identificatore utilizza la seguente sintassi:
PREFIX://iam.googleapis.com/projects/FLEET_PROJECT_NUMBER/locations/global/workloadIdentityPools/FLEET_PROJECT_ID.svc.id.goog/SELECTOR
Questa sintassi ha i seguenti campi:
PREFIX
: l'attributo IAMprincipal
oprincipalSet
a seconda della risorsa selezionata.FLEET_PROJECT_ID.svc.id.goog
: il pool di identità per i carichi di lavoro per il tuo parco risorse. Ogni parco risorse ha un singolo pool di Workload Identity fissato che viene creato per te.FLEET_PROJECT_NUMBER
: il numero del progetto dell'host del parco risorse progetto.SELECTOR
: il selettore delle risorse. Per un elenco delle selettori, consulta gli identificatori entità supportati.
L'intero parco risorse condivide un pool di identità per i carichi di lavoro, in modo che tu possa fornire applicazioni ovunque nel parco risorse, anche in altri progetti o cloud, alle stesse risorse senza dover gestire l'accesso per ogni in un cluster Kubernetes. Come per altre funzionalità abilitate per il parco risorse, la federazione delle identità per i carichi di lavoro si basa sul principio dell'uguaglianza, in base al quale gli oggetti Kubernetes che hanno lo stesso nome e lo stesso spazio dei nomi in cluster diversi vengono considerati la stessa cosa.
Ad esempio, se un'applicazione ha un backend di cui è stato eseguito il deployment
nello stesso parco risorse e che deve essere autenticata in un
API, puoi configurare la tua applicazione in modo che tutti i carichi di lavoro in backend
dello spazio dei nomi può accedere all'API. Per ulteriori informazioni su come i parchi risorse utilizzano l'identità, consulta Come funzionano i parchi risorse.
Dopo aver attivato la federazione delle identità per i carichi di lavoro del parco risorse, puoi fare riferimento ai principali nel tuo parco risorse nei criteri di autorizzazione IAM specificando l'identificatore corrispondente del principale. Ad esempio, puoi fare riferimento a un account di servizio specifico in uno specifico spazio dei nomi Kubernetes nel tuo criterio di autorizzazione. Tutte le applicazioni per utilizzare questo account di servizio potresti poi accedere alla risorsa Google Cloud a cui si applica il criterio di autorizzazione IAM.
Flusso di credenziali
Per consentire alle applicazioni in uno spazio dei nomi specifico di eseguire l'autenticazione utilizzando il parco risorse Federazione delle identità per i carichi di lavoro:
Esegui il deployment di un ConfigMap nello spazio dei nomi contenente le seguenti informazioni:
- Il pool di identità per i carichi di lavoro e il provider di identità per in un cluster Kubernetes.
- Il percorso in ogni pod su cui Kubernetes monta un token ServiceAccount. Questo token è un token JWT (JSON Web Token) firmato.
Questo ConfigMap funziona come credenziali predefinite dell'applicazione (ADC) per i carichi di lavoro.
Crea un criterio di autorizzazione IAM che concede accesso a specifiche Risorse Google Cloud all'identificatore dell'entità nei cluster, ad esempio un ServiceAccount nello spazio dei nomi.
Assicurati che il carico di lavoro nello spazio dei nomi abbia le seguenti configurazioni nella specifica del pod:
- La variabile di ambiente
GOOGLE_APPLICATION_CREDENTIALS
impostata su di montaggio del ConfigMap nel pod. - Un volume proiettato contenente il token dell'account di servizio e il ConfigMap che hai creato, montato nello stesso percorso specificato nella variabile di ambiente
GOOGLE_APPLICATION_CREDENTIALS
. - Un montaggio del volume nel container che fa riferimento al volume previsto.
- La variabile di ambiente
Quando il carico di lavoro effettua una chiamata all'API Google Cloud, vengono eseguiti i seguenti passaggi:
- Le librerie di autenticazione di Google Cloud utilizzano le impostazioni predefinite dell'applicazione
(ADC) per trovare le credenziali. ADC controlla il percorso
specificato nella variabile di ambiente
GOOGLE_APPLICATION_CREDENTIALS
cerca un token di autenticazione. - La libreria di autenticazione ADC utilizza i dati di ConfigMap per lo scambio il JWT ServiceAccount che hai montato sul pod per un breve periodo federato di Servizio token di sicurezza che fa riferimento all'entità identificatore del carico di lavoro.
- ADC include il token federato con la richiesta API.
- Il criterio di autorizzazione IAM autorizza l'identificatore principale a eseguire l'operazione richiesta sulla risorsa Google Cloud.
Identificatori dell'entità supportati per la federazione delle identità per i carichi di lavoro del parco risorse
La tabella seguente descrive i selettori che puoi utilizzare nella Criteri di autorizzazione IAM per fare riferimento alle entità nei parchi risorse:
Tipo di identificatore principale | Sintassi |
---|---|
Tutti i pod che utilizzano un account di servizio Kubernetes specifico | Seleziona l'account di servizio in base al nome:
principal://iam.googleapis.com/projects/ Sostituisci quanto segue:
Seleziona l'account di servizio per UID: principal://iam.googleapis.com/projects/ Sostituisci quanto segue:
|
Prima di iniziare
Assicurati di avere installato i seguenti strumenti a riga di comando:
- La versione più recente di Google Cloud CLI, che include
gcloud
, lo strumento a riga di comando per interagire con Google Cloud. kubectl
Se utilizzi Cloud Shell come ambiente shell per interagire con Google Cloud, questi strumenti vengono installati automaticamente.
- La versione più recente di Google Cloud CLI, che include
Assicurati di aver inizializzato gcloud CLI per l'utilizzo con il tuo progetto.
Prepara i cluster
Prima che le applicazioni nel tuo parco risorse possano ricevere un'identità federata, i cluster su cui vengono eseguite devono essere registrati al parco risorse e configurati correttamente per utilizzare la federazione delle identità del carico di lavoro del parco risorse. Le seguenti sezioni descrivono come configurare la federazione delle identità per i carichi di lavoro del parco risorse per diversi tipi di cluster.
GKE
Per i cluster GKE, segui questi passaggi:
- Abilita la federazione Workload Identity per GKE sul tuo cluster Google Kubernetes Engine, se non è già abilitata.
- Registra il cluster alla flotta.
Puoi anche attivare la federazione delle identità per i carichi di lavoro per GKE durante la procedura di creazione del cluster e di registrazione del parco risorse.
Cluster esterni a Google Cloud
I seguenti tipi di cluster abilitano automaticamente il parco risorse Federazione delle identità per i carichi di lavoro e vengono registrati nel parco risorse durante il cluster creazione:
- Google Distributed Cloud (solo software) su VMware
- Google Distributed Cloud (solo software) on bare metal
- GKE su AWS
- GKE su Azure
Cluster collegati
I cluster collegati EKS e AKS registrati utilizzando l'API GKE Multi-Cloud sono registrati con la federazione Workload Identity del parco risorse attivata per impostazione predefinita. Altri cluster collegati possono essere registrati con la federazione delle identità per i carichi di lavoro del parco risorse abilitata se soddisfano i requisiti necessari. Segui le istruzioni per il tuo tipo di cluster in Registrazione di un cluster.
Utilizza la federazione delle identità per i carichi di lavoro del parco risorse nelle applicazioni
I passaggi seguenti mostrano come configurare un carico di lavoro in un cluster registrato per utilizzare la federazione delle identità per i carichi di lavoro del parco risorse:
Individua il nome del pool di identità per i carichi di lavoro del cluster e del provider di identità:
gcloud container fleet memberships describe MEMBERSHIP_ID \ --project=FLEET_PROJECT_ID \ --format="table(authority.identityProvider,authority.workloadIdentityPool,name)"
Sostituisci quanto segue:
MEMBERSHIP_ID
: il nome dell'appartenenza al cluster. e spesso corrisponde al nome del cluster.FLEET_PROJECT_ID
: l'ID progetto del parco risorse progetto host.
L'output è simile al seguente:
IDENTITY_PROVIDER: IDENTITY_PROVIDER WORKLOAD_IDENTITY_POOL: WORKLOAD_IDENTITY_POOL NAME: projects/FLEET_PROJECT_ID/locations/MEMBERSHIP_LOCATION/memberships/MEMBERSHIP_ID
Questo output contiene le seguenti informazioni:
IDENTITY_PROVIDER
: il provider di identità per il cluster.MEMBERSHIP_LOCATION
: la posizione del abbonamento a un parco risorse. Di solito corrisponde alla posizione del cluster.WORKLOAD_IDENTITY_POOL
: il nome del pool di identità per i carichi di lavoro associato al tuo parco risorse. Questo valore ha la sintassiFLEET_PROJECT_ID.svc.id.goog
.
Crea uno spazio dei nomi Kubernetes. Puoi anche utilizzare qualsiasi spazio dei nomi esistente, incluso lo spazio dei nomi
default
.kubectl create namespace NAMESPACE
Sostituisci
NAMESPACE
con il nome dello spazio dei nomi.Crea un nuovo account di servizio Kubernetes nello spazio dei nomi. Puoi anche utilizzare qualsiasi account di servizio esistente, incluso l'account di servizio
default
nello spazio dei nomi.kubectl create serviceaccount KSA_NAME \ --namespace=NAMESPACE
Sostituisci
KSA_NAME
con il nome del ServiceAccount.Salva il seguente manifest come
adc-config-map.yaml
. Questo ConfigMap contiene la configurazione dell'ADC per i carichi di lavoro.kind: ConfigMap apiVersion: v1 metadata: namespace: NAMESPACE name: my-cloudsdk-config data: config: | { "type": "external_account", "audience": "identitynamespace:WORKLOAD_IDENTITY_POOL:IDENTITY_PROVIDER", "subject_token_type": "urn:ietf:params:oauth:token-type:jwt", "token_url": "https://sts.googleapis.com/v1/token", "credential_source": { "file": "/var/run/secrets/tokens/gcp-ksa/token" } }
Esegui il deployment del ConfigMap:
kubectl create -f adc-config-map.yaml
Salva il seguente manifest come
workload-config.yaml
:apiVersion: v1 kind: Pod metadata: name: my-pod namespace: NAMESPACE spec: serviceAccountName: KSA_NAME containers: - name: sample-container image: google/cloud-sdk:slim command: ["sleep","infinity"] env: - name: GOOGLE_APPLICATION_CREDENTIALS value: /var/run/secrets/tokens/gcp-ksa/google-application-credentials.json volumeMounts: - name: gcp-ksa mountPath: /var/run/secrets/tokens/gcp-ksa readOnly: true volumes: - name: gcp-ksa projected: defaultMode: 420 sources: - serviceAccountToken: path: token audience: WORKLOAD_IDENTITY_POOL expirationSeconds: 172800 - configMap: name: my-cloudsdk-config optional: false items: - key: "config" path: "google-application-credentials.json"
Quando esegui il deployment di questo carico di lavoro, il volume
gcp-ksa
nel pod contiene seguenti dati:- I dati nel ConfigMap di cui hai eseguito il deployment sotto forma di file denominato
google-application-credentials.json
. Questo file è un File di configurazione delle credenziali ADC. - Il token ServiceAccount di Kubernetes come
token
. Kubernetes monta un JWT firmato per l'account di servizio come file del token dell'account di servizio proiettato.
Il container nel pod monta il volume
gcp-ksa
nella/var/run/secrets/tokens/gcp-ksa
e configura l'ADC in modo che cerchi il del file JSON di configurazione delle credenziali in quel percorso.- I dati nel ConfigMap di cui hai eseguito il deployment sotto forma di file denominato
Esegui il deployment del carico di lavoro:
kubectl apply -f workload-config.yaml
Alternativa: simula l'identità di un account di servizio IAM
In alternativa, puoi configurare gli account di servizio Kubernetes nei tuoi cluster impersonare account di servizio IAM ed eseguire qualsiasi azioni eseguibili dagli account di servizio IAM. Questo approccio potrebbe aumentare i costi di manutenzione, perché devi gestire gli accoppiamenti in IAM e Kubernetes.
Nella maggior parte degli scenari, consigliamo di fare riferimento direttamente a Kubernetes le entità di IAM consentono ai criteri di concedere l'accesso alle risorse Google Cloud seguendo le istruzioni in Utilizza la federazione delle identità per i carichi di lavoro del parco risorse nelle applicazioni.
Trova il nome dell'identità e del pool di identità per i carichi di lavoro del cluster fornitore:
gcloud container fleet memberships describe MEMBERSHIP_ID \ --project=FLEET_PROJECT_ID \ --format="table(authority.identityProvider,authority.workloadIdentityPool,name)"
Sostituisci quanto segue:
MEMBERSHIP_ID
: il nome dell'appartenenza al cluster. e spesso corrisponde al nome del cluster.FLEET_PROJECT_ID
: l'ID progetto del parco risorse progetto host.
L'output è simile al seguente:
IDENTITY_PROVIDER: IDENTITY_PROVIDER WORKLOAD_IDENTITY_POOL: WORKLOAD_IDENTITY_POOL NAME: projects/FLEET_PROJECT_ID/locations/MEMBERSHIP_LOCATION/memberships/MEMBERSHIP_ID
Questo output contiene le seguenti informazioni:
IDENTITY_PROVIDER
: il provider di identità per in un cluster Kubernetes.MEMBERSHIP_LOCATION
: la località dell'appartenenza. Di solito corrisponde alla posizione del cluster.WORKLOAD_IDENTITY_POOL
: il nome del pool di identità per i carichi di lavoro associati al tuo parco risorse. Questo valore ha la sintassiFLEET_PROJECT_ID.svc.id.goog
.
Crea un account di servizio IAM che l'applicazione può si spaccia per te. Puoi anche utilizzare qualsiasi account di servizio IAM esistente.
gcloud iam service-accounts create IAM_SA_NAME \ --project=IAM_SA_PROJECT_ID
Sostituisci quanto segue:
IAM_SA_NAME
: il nome del tuo IAM l'account di servizio.IAM_SA_PROJECT_ID
: l'ID del progetto che contiene il tuo account di servizio IAM. Può essere diverso dal progetto host del parco risorse.
Concedi all'account di servizio IAM tutte le autorizzazioni di cui ha bisogno per accedere alle API Google Cloud aggiungendo i criteri di autorizzazione IAM necessari. Puoi farlo utilizzando
gcloud iam service-accounts add-iam-policy-binding
o un altro metodo. Puoi e scoprire quali sono le autorizzazioni necessarie per utilizzare le API consulta la documentazione del servizio e visualizza un elenco completo dei ruoli predefiniti le autorizzazioni necessarie Informazioni sui ruoli.Creare un ServiceAccount Kubernetes in uno spazio dei nomi. Puoi anche utilizzare un account di servizio Kubernetes esistente e qualsiasi spazio dei nomi, inclusi l'account di servizio
default
e lo spazio dei nomidefault
.kubectl create serviceaccount KSA_NAME \ --namespace=NAMESPACE
Sostituisci quanto segue:
KSA_NAME
: il nome del ServiceAccount.NAMESPACE
: il nome dello spazio dei nomi.
Creare un criterio di autorizzazione IAM che consenta a un cluster Kubernetes ServiceAccount in uno spazio dei nomi specifico nel tuo cluster rappresenta il Account di servizio IAM:
gcloud iam service-accounts add-iam-policy-binding IAM_SA_NAME@IAM_SA_PROJECT_ID.iam.gserviceaccount.com \ --project=IAM_SA_PROJECT_ID \ --role=roles/iam.workloadIdentityUser \ --member="serviceAccount:WORKLOAD_IDENTITY_POOL[NAMESPACE/KSA_NAME]"
Sostituisci
WORKLOAD_IDENTITY_POOL
con il nome del pool di identità di carico di lavoro.Salva il seguente manifest come
adc-config-map.yaml
. Questo ConfigMap contiene la configurazione dell'ADC per i carichi di lavoro.kind: ConfigMap apiVersion: v1 metadata: namespace: K8S_NAMESPACE name: my-cloudsdk-config data: config: | { "type": "external_account", "audience": "identitynamespace:WORKLOAD_IDENTITY_POOL:IDENTITY_PROVIDER", "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/IAM_SA_NAME@GSA_PROJECT_ID.iam.gserviceaccount.com:generateAccessToken", "subject_token_type": "urn:ietf:params:oauth:token-type:jwt", "token_url": "https://sts.googleapis.com/v1/token", "credential_source": { "file": "/var/run/secrets/tokens/gcp-ksa/token" } }
Sostituisci quanto segue:
IAM_SA_NAME
: il nome dell'account di servizio IAM da simulare.IAM_SA_PROJECT_ID
: l'ID progetto dell'account di servizio IAM.
Salva il seguente manifest come
workload-config.yaml
:apiVersion: v1 kind: Pod metadata: name: my-pod namespace: K8S_NAMESPACE spec: serviceAccountName: KSA_NAME containers: - name: my-container image: my-image command: ["sleep","infinity"] env: - name: GOOGLE_APPLICATION_CREDENTIALS value: /var/run/secrets/tokens/gcp-ksa/google-application-credentials.json volumeMounts: - name: gcp-ksa mountPath: /var/run/secrets/tokens/gcp-ksa readOnly: true volumes: - name: gcp-ksa projected: defaultMode: 420 sources: - serviceAccountToken: path: token audience: WORKLOAD_IDENTITY_POOL expirationSeconds: 172800 - configMap: name: my-cloudsdk-config optional: false items: - key: "config" path: "google-application-credentials.json"
Quando esegui il deployment di questo carico di lavoro, il volume
gcp-ksa
nel pod contiene seguenti dati:- I dati nel ConfigMap di cui hai eseguito il deployment come file denominato
google-application-credentials.json
. Questo file è un File di configurazione delle credenziali ADC. - Il token dell'account di servizio Kubernetes come
token
. Kubernetes monta un JWT firmato per l'account ServiceAccount come file del token dell'account ServiceAccount proiettato.
Il container nel pod monta il volume
gcp-ksa
nella/var/run/secrets/tokens/gcp-ksa
e configura l'ADC in modo che cerchi il del file JSON di configurazione delle credenziali in quel percorso.- I dati nel ConfigMap di cui hai eseguito il deployment come file denominato
Esegui il deployment del carico di lavoro:
kubectl apply -f workload-config.yaml
Verifica la configurazione della federazione delle identità per i carichi di lavoro del parco risorse
In questa sezione crei un bucket Cloud Storage e accedi da un pod che utilizza la federazione Workload Identity del parco risorse. Prima di eseguire questi passaggi, assicurati di aver configurato la federazione delle identità per i carichi di lavoro seguendo le istruzioni nel Utilizza la federazione delle identità per i carichi di lavoro del parco risorse nelle applicazioni .
Questa sezione non mostra come verificare la federazione delle identità per i carichi di lavoro utilizzando Metodo di rappresentazione degli account di servizio IAM.
Trova il numero numerico del progetto:
gcloud projects describe FLEET_PROJECT_ID \ --format="value(projectNumber)"
L'output è simile al seguente:
1234567890
Crea un bucket Cloud Storage:
gcloud storage buckets create gs://FLEET_PROJECT_ID-test-bucket \ --location=LOCATION
Sostituisci
LOCATION
con un account Google Cloud in ogni località.Crea un criterio di autorizzazione IAM che concede l'accesso al bucket all'account di servizio che hai creato:
gcloud storage buckets add-iam-policy-binding gs://FLEET_PROJECT_ID-test-bucket \ --condition=None \ --role=roles/storage.objectViewer \ --member=principal://iam.googleapis.com/projects/FLEET_PROJECT_NUMBER/locations/global/workloadIdentityPools/FLEET_PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME
Sostituisci quanto segue:
FLEET_PROJECT_NUMBER
: il numero del progetto.FLEET_PROJECT_ID
: il tuo ID progetto.NAMESPACE
: il nome dello spazio dei nomi Kubernetes che esegue il pod della sezione precedente.KSA_NAME
: il nome dell'account servizio Kubernetes utilizzato dal pod della sezione precedente.
Crea una sessione di shell nel pod:
kubectl exec -it pods/my-pod --namespace=NAMESPACE -- /bin/bash
Prova a elencare gli oggetti nel bucket:
curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" \ "https://storage.googleapis.com/storage/v1/b/test-bucket/o"
L'output è il seguente:
{ "kind": "storage#objects" }
Effettuare l'autenticazione tramite il codice
Quando utilizzi le librerie client di Cloud, le librerie di autenticazione usano automaticamente ADC per cercare le credenziali eseguire l'autenticazione nei servizi Google Cloud. Devi utilizzare le librerie client di Cloud che supportano la federazione di Workload Identity. Di seguito sono riportate le versioni minime obbligatorie delle librerie client di Cloud, nonché le istruzioni per controllare la versione corrente:
C++
La maggior parte delle
librerie client di Google Cloud per C++ supporta la federazione delle identità utilizzando un oggetto ChannelCredentials
, che viene creato chiamando grpc::GoogleDefaultCredentials()
. Per inizializzare questo
credenziale, devi creare le librerie client con la versione 1.36.0 o successiva di
gRPC.
La libreria client Cloud Storage per C++ utilizza l'API REST, non gRPC, pertanto non supporta la federazione delle identità.
Go
Le librerie client per Go supportano la federazione delle identità se utilizzano la versione
v0.0.0-20210218202405-ba52d332ba99 o versioni successive del modulo golang.org/x/oauth2
.
Per verificare quale versione di questo modulo è utilizzata dalla libreria client, esegui il 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à se utilizzano la versione 0.24.0
o successivamente
com.google.auth:google-auth-library-oauth2-http
artefatto.
Per verificare quale versione di questo artefatto è utilizzata dalla libreria client, esegui il comando 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à se utilizzano la versione
7.0.2 o versioni 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
README
per il pacchetto google-auth-library
.
Python
Le librerie client per Python supportano la federazione delle identità se utilizzano la versione
1.27.0 o versioni successive del
Pacchetto google-auth
.
Per controllare la versione di questo pacchetto utilizzata dalla 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 il valore
GOOGLE_CLOUD_PROJECT
o 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 nel progetto. Per maggiori dettagli, consulta la
guida dell'utente per il pacchetto google-auth
.
Passaggi successivi
Scopri le best practice per l'organizzazione dei parchi risorse quando utilizzi la federazione delle identità per i carichi di lavoro.