Questa pagina mostra come configurare le applicazioni per autenticarsi alle APIGoogle Cloud , come l'API Compute Engine o l'API AI Platform, utilizzando la federazione Workload Identity del parco risorse.
Che cos'è la federazione di Workload Identity del parco risorse?
La federazione Workload Identity consente ai workload nei tuoi cluster di autenticarsi in Google Cloud senza che tu debba scaricare, ruotare manualmente e in genere gestire le credenziali. I carichi di lavoro si autenticano invece utilizzando token di breve durata generati da Google Cloud.
Workload Identity Federation for GKE fornisce un pool di identità per i carichi di lavoro a livello di progetto da cui le applicazioni in esecuzione nei cluster GKE ricevono 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 cluster dei membri del parco risorse, indipendentemente dal fatto che si trovino in progetti diversi o al di fuori di Google Cloud. I cluster registrati con la federazione Workload Identity attivata per l'appartenenza al parco risorse ricevono le identità utilizzando un pool di identità dei carichi di lavoro a livello di parco risorse, che ti consente di configurare l'autenticazione alle API diGoogle Cloud e ad altri servizi nell'intero parco risorse, anche su più progetti.
La federazione delle identità dei carichi di lavoro del parco può essere utilizzata anche dall'agente di connessione su alcuni tipi di cluster per autenticarsi in Google Cloud come parte dell'appartenenza al parco ed è obbligatoria per utilizzare alcune funzionalità di GKE Enterprise che funzionano in più progetti, come 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 dell'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
:principal
oprincipalSet
di IAM a seconda della risorsa selezionata.FLEET_PROJECT_ID.svc.id.goog
: il pool di identità del workload 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'attività ospitante del parco risorse.SELECTOR
: il selettore delle risorse. Per un elenco dei selezionatori supportati, consulta gli identificatori principali supportati.
L'intero parco condivide un pool di identità per i carichi di lavoro del parco, in modo da poter fornire alle applicazioni ovunque nel parco, inclusi altri progetti o cloud, accesso alle stesse risorse senza dover gestire questo accesso per ogni cluster. Come altre funzionalità abilitate per il parco risorse, la federazione Workload Identity del parco risorse si basa sul principio di identicità, in cui gli oggetti Kubernetes che hanno lo stesso nome e spazio dei nomi in cluster diversi sono trattati come se fossero la stessa cosa.
Ad esempio, se hai un'applicazione con un backend di cui è stato eseguito il deployment su più cluster nello stesso parco risorse e che deve autenticarsi in un'API Google Cloud, puoi configurare l'applicazione in modo che tutti i carichi di lavoro nello spazio dei nomi backend
possano accedere a quell'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, nel criterio di autorizzazione puoi fare riferimento a un account di servizio specifico in uno spazio dei nomi Kubernetes specifico. Tutte le applicazioni che utilizzano questo account ServiceAccount potrebbero quindi 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 autenticarsi utilizzando la federazione delle identità per i carichi di lavoro del parco risorse:
Esegui il deployment di un ConfigMap nello spazio dei nomi contenente le seguenti informazioni:
- Il pool di identità del workload e il provider di identità per il tuo cluster.
- Il percorso in ogni pod su cui Kubernetes monta un token ServiceAccount. Questo token è un token JWT (JSON Web Token) firmato.
Questo ConfigMap funge da file di credenziali predefinite dell'applicazione (ADC) per i workload.
Crea un criterio di autorizzazione IAM che conceda l'accesso a risorse specifiche diGoogle Cloud all'identificatore principale del principale nei tuoi cluster, ad esempio un account di servizio 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 sul percorso 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 punto di montaggio del volume nel contenitore che fa riferimento al volume proiettato.
- La variabile di ambiente
Quando il workload effettua una chiamata all'API Google Cloud , vengono eseguiti i seguenti passaggi:
- Le librerie di autenticazione di Google Cloud utilizzano le Credenziali predefinite dell'applicazione (ADC) per trovare le credenziali. L'ADC controlla il percorso specificato nella variabile di ambiente
GOOGLE_APPLICATION_CREDENTIALS
per cercare un token di autenticazione. - La libreria di autenticazione ADC utilizza i dati nel ConfigMap per scambiare il JWT dell'account di servizio montato sul pod con un token di accesso federato di breve durata proveniente da Security Token Service che fa riferimento all'identificatore dell'entità del carico di lavoro.
- L'ADC include il token di accesso federato con la richiesta dell'API.
- Il criterio di autorizzazione IAM autorizza l'identificatore principale a eseguire l'operazione richiesta sulla risorsa Google Cloud .
Identificatori principali supportati per la federazione di Workload Identity del parco risorse
La seguente tabella descrive i selettori che puoi utilizzare nei criteri IAM per consentire il riferimento a entità nei fleet:
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:
|
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 per te.
- 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 workload 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:
- Abilita la federazione Workload Identity per GKE sul tuo cluster Google Kubernetes Engine, se non è già abilitata.
- Registra il cluster nel parco risorse.
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.
Cluster esterni a Google Cloud
I seguenti tipi di cluster attivano automaticamente la federazione delle identità di carico di lavoro del parco risorse e vengono registrati nel parco risorse durante la creazione del cluster:
- Google Distributed Cloud (solo software) su VMware
- Google Distributed Cloud (solo software) su 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 abilitata 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.
Utilizzare la federazione di Workload Identity del parco risorse nelle applicazioni
I passaggi che seguono 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à del carico di lavoro e del provider di identità del cluster:
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 del progetto ospitante del parco risorse.
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 località dell'abbonamento al parco. Di solito corrisponde alla posizione del cluster.WORKLOAD_IDENTITY_POOL
: il nome del pool di identità del workload 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 servizio account.Salva il seguente manifest come
adc-config-map.yaml
. Questo ConfigMap contiene la configurazione dell'ADC per i workload.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 workload, il volume
gcp-ksa
nel pod contiene i seguenti dati:- I dati nel ConfigMap di cui hai eseguito il deployment come file denominato
google-application-credentials.json
. Si tratta di un file di configurazione delle credenziali ADC. - Il token dell'account di servizio Kubernetes come
token
. Kubernetes monta un JWT firmato per l'account di servizio come file del token dell'account di servizio proiettato.
Il contenitore nel pod monta il volume
gcp-ksa
nel percorso/var/run/secrets/tokens/gcp-ksa
e configura l'ADC in modo da cercare il 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
Alternativa: simula l'identità di un account di servizio IAM
In alternativa, puoi configurare gli account di servizio Kubernetes nei tuoi cluster in modo che impersonino gli account di servizio IAM ed eseguano qualsiasi azione autorizzata che gli account di servizio IAM possono eseguire. Questo approccio potrebbe aumentare il sovraccarico di manutenzione, perché devi gestire gli accoppiamenti degli account di servizio sia in IAM che in Kubernetes.
Nella maggior parte degli scenari, ti consigliamo di fare riferimento direttamente ai principali di Kubernetes nei criteri di autorizzazione IAM per concedere l'accesso alle risorse diGoogle Cloud seguendo le istruzioni riportate in Utilizzare la federazione di Workload Identity del parco risorse nelle applicazioni.
Individua il nome del pool di identità del carico di lavoro e del provider di identità del cluster:
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 del progetto ospitante del parco risorse.
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 località dell'appartenenza. Di solito corrisponde alla posizione del cluster.WORKLOAD_IDENTITY_POOL
: il nome del pool di identità del workload associato al tuo parco risorse. Questo valore ha la sintassiFLEET_PROJECT_ID.svc.id.goog
.
Crea un account di servizio IAM che la tua applicazione può usurpare. 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 account di servizio IAM.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 scoprire quali autorizzazioni sono necessarie per utilizzare le API Google Cloud nella documentazione di ciascun servizio e visualizzare un elenco completo dei ruoli predefiniti con le autorizzazioni necessarie in Informazioni sui ruoli.Crea un account di servizio 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.
Crea un criterio di autorizzazione IAM che consenta a un account di servizio Kubernetes in uno spazio dei nomi specifico del cluster di 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 \ --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 workload.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 del account di servizio IAM da simulare.IAM_SA_PROJECT_ID
: l'ID progetto del 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 workload, il volume
gcp-ksa
nel pod contiene i seguenti dati:- I dati nel ConfigMap di cui hai eseguito il deployment come file denominato
google-application-credentials.json
. Si tratta di 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 contenitore nel pod monta il volume
gcp-ksa
nel percorso/var/run/secrets/tokens/gcp-ksa
e configura l'ADC in modo da cercare il 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 riportate nella sezione Utilizzare 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 il metodo di rappresentazione dell'account di servizio IAM.
Trova il numero del progetto numerico:
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 una località Google Cloud.Crea un criterio di autorizzazione IAM che conceda 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 application-default print-access-token)" \ "https://storage.googleapis.com/storage/v1/b/FLEET_PROJECT_ID-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 utilizzano automaticamente le Credenziali predefinite dell'applicazione per cercare le credenziali per autenticarsi ai servizi Google Cloud . Devi utilizzare le librerie client di Cloud che supportano la federazione di Workload Identity. Di seguito sono riportate le versioni minime richieste delle librerie client di Cloud, nonché le istruzioni per controllare la versione corrente:
C++
La maggior parte delle
Google Cloud librerie client per C++ supporta la federazione delle identità utilizzando un oggetto ChannelCredentials
, che viene creato chiamando grpc::GoogleDefaultCredentials()
. Per inizializzare questa credenza, devi compilare le librerie client con la versione 1.36.0 o successive 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 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à 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à 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 delle identità se utilizzano la versione 1.27.0 o 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 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
.
Passaggi successivi
Scopri le best practice per organizzare i parchi risorse quando utilizzi la federazione delle identità per i workload del parco risorse.