Esegui l'autenticazione in API e servizi dai carichi di lavoro del parco risorse

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 o principalSet 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:

  1. 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.

  2. 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.

  3. 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.

Quando il workload effettua una chiamata all'API Google Cloud , vengono eseguiti i seguenti passaggi:

  1. 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.
  2. 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.
  3. L'ADC include il token di accesso federato con la richiesta dell'API.
  4. 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/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/SERVICEACCOUNT

Sostituisci quanto segue:

  • PROJECT_NUMBER: il numero numerico del progetto. Per ottenere il numero del progetto, consulta Identificazione dei progetti.
  • PROJECT_ID: l'ID del tuo progetto Google Cloud .
  • NAMESPACE: lo spazio dei nomi Kubernetes.
  • SERVICEACCOUNT: il nome del service account Kubernetes.

Seleziona l'account di servizio per UID:
principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/kubernetes.serviceaccount.uid/SERVICEACCOUNT_UID

Sostituisci quanto segue:

  • PROJECT_NUMBER: il numero numerico del progetto. Per ottenere il numero di progetto, consulta Identificazione dei progetti.
  • PROJECT_ID: l'ID del tuo progetto Fleet.
  • SERVICEACCOUNT_UID: l'UID dell'oggetto ServiceAccount nel server API.

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.

  • 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:

  1. Abilita la federazione Workload Identity per GKE sul tuo cluster Google Kubernetes Engine, se non è già abilitata.
  2. 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:

  1. 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 sintassi FLEET_PROJECT_ID.svc.id.goog.
  2. 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.

  3. 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.

  4. 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"
          }
        }
    
  5. Esegui il deployment del ConfigMap:

    kubectl create -f adc-config-map.yaml
    
  6. 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:

    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.

  7. 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.

  1. 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 sintassi FLEET_PROJECT_ID.svc.id.goog.
  2. 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.
  3. 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.

  4. 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 nomi default.

    kubectl create serviceaccount KSA_NAME \
        --namespace=NAMESPACE
    

    Sostituisci quanto segue:

    • KSA_NAME: il nome del ServiceAccount.
    • NAMESPACE: il nome dello spazio dei nomi.
  5. 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.

  6. 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.
  7. 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:

    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.

  8. 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.

  1. Trova il numero del progetto numerico:

    gcloud projects describe FLEET_PROJECT_ID \
        --format="value(projectNumber)"
    

    L'output è simile al seguente:

    1234567890
    
  2. Crea un bucket Cloud Storage:

    gcloud storage buckets create gs://FLEET_PROJECT_ID-test-bucket \
        --location=LOCATION
    

    Sostituisci LOCATION con una località Google Cloud.

  3. 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.
  4. Crea una sessione di shell nel pod:

    kubectl exec -it pods/my-pod --namespace=NAMESPACE -- /bin/bash
    
  5. 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.