Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Esegui l'autenticazione alle API Google Cloud dai workload del parco risorse con attendibilità condivisa

Questa pagina mostra come configurare le applicazioni per l'autenticazione alle Google Cloud API, come l'API Compute Engine o l'API AI Platform, dai parchi risorse che hanno un modello di trust condiviso in tutto il parco risorse. Se il tuo parco risorse ha un modello di trust misto, consulta Autenticazione alle Google Cloud API dai workload del parco risorse con trust misto.

Questa pagina è rivolta agli amministratori e agli operatori della piattaforma e agli ingegneri della sicurezza che vogliono eseguire l'autenticazione in modo programmatico dai workload del parco risorse alle Google Cloud API. Per saperne di più sui ruoli utente e sulle attività di esempio a cui facciamo riferimento nella Google Cloud documentazione, consulta Ruoli e attività utente GKE comuni.

Prima di leggere questa pagina, assicurati di conoscere i seguenti concetti:

Informazioni sulla federazione delle identità per i workload del parco risorse per gli ambienti con trust condiviso

La federazione delle identità per i workload del parco risorse consente di eseguire l'autenticazione dai workload del parco risorse alle Google Cloud API utilizzando meccanismi di autenticazione Kubernetes Google Cloud integrati. La federazione delle identità per i workload del parco risorse elimina la necessità di utilizzare metodi meno sicuri, come il montaggio di token di accesso nei pod o l'archiviazione di credenziali a lunga durata.

Per impostazione predefinita, il progetto host del parco risorse utilizza un pool di identità del workload gestito da Google per eseguire il provisioning delle identità per le entità del parco risorse. Qualsiasi entità nel parco risorse o nel progetto host del parco risorse che ha lo stesso identificatore IAM è considerata la stessa cosa da IAM. Questa uguaglianza implicita delle identità è utile quando si concede l'accesso su larga fare lo scale in ambienti con trust condiviso, come i parchi risorse a tenant singolo, in cui non è importante se altre entità ottengono involontariamente autorizzazioni simili per le risorse.

Prima di iniziare

Assicurati di aver installato i seguenti strumenti a riga di comando:
- L'ultima versione 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 sono installati per te.
Assicurati di aver inizializzato gcloud CLI per l'utilizzo con il tuo progetto.

Prepara i cluster

Prima che le applicazioni nel parco risorse possano ricevere un'identità federata, i cluster su cui vengono eseguite devono essere registrati nel parco risorse e configurati correttamente per utilizzare la federazione delle identità per i workload del parco risorse. Le seguenti sezioni descrivono come configurare la federazione delle identità per i workload del parco risorse per diversi tipi di cluster.

GKE

Per i cluster GKE, procedi nel seguente modo:

Abilita Workload Identity Federation per GKE sul cluster Google Kubernetes Engine, se non è già abilitata.
Registra il cluster nel parco risorse.

Puoi anche abilitare Workload Identity Federation for GKE durante la creazione del cluster e la registrazione del parco risorse.

Cluster esterni Google Cloud

I seguenti tipi di cluster abilitano automaticamente la federazione delle identità per i workload 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 vengono registrati con la federazione delle identità per i workload del parco risorse abilitata per impostazione predefinita. Altri cluster collegati possono essere registrati con la federazione delle identità per i workload del parco risorse abilitata se soddisfano i requisiti necessari. Segui le istruzioni per il tipo di cluster in Registrazione di un cluster.

Utilizzare la federazione delle identità per i workload del parco risorse nelle applicazioni

I seguenti passaggi mostrano come configurare un workload in un cluster registrato per utilizzare la federazione delle identità per i workload del parco risorse:

Trova il nome del pool di identità del workload 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 . Spesso è il nome del cluster.
- FLEET_PROJECT_ID: l'ID progetto del progetto host 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 al parco risorse. Di solito è la stessa della località del cluster.
- WORKLOAD_IDENTITY_POOL: il nome del pool di identità del workload associato al parco risorse. Questo valore ha la sintassi FLEET_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 oggetto ServiceAccount Kubernetes nello spazio dei nomi. Puoi anche utilizzare qualsiasi oggetto ServiceAccount esistente, incluso l'oggetto ServiceAccount default nello spazio dei nomi.
```
kubectl create serviceaccount KSA_NAME \
    --namespace=NAMESPACE
```
Sostituisci KSA_NAME con il nome dell'oggetto ServiceAccount.

Salva il seguente manifest come adc-config-map.yaml. Questo oggetto ConfigMap contiene la configurazione 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 dell'oggetto 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 nell'oggetto 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'oggetto ServiceAccount Kubernetes come token. Kubernetes monta un JWT firmato per l'oggetto ServiceAccount come un file di token dell'oggetto ServiceAccount proiettato.

Il container nel pod monta il volume gcp-ksa nel percorso /var/run/secrets/tokens/gcp-ksa e configura ADC in modo che cerchi il file JSON di configurazione delle credenziali in questo percorso.

Esegui il deployment del workload:
```
kubectl apply -f workload-config.yaml
```

Alternativa: rappresentare un account di servizio IAM

In alternativa, puoi configurare gli oggetti ServiceAccount Kubernetes nei cluster per rappresentare i service account IAM ed eseguire qualsiasi azione autorizzata che i service account IAM possono eseguire. Questo approccio potrebbe aumentare il sovraccarico di manutenzione, perché devi gestire le coppie di service account sia in IAM sia in Kubernetes.

Nella maggior parte degli scenari, ti consigliamo di fare riferimento direttamente alle entità Kubernetes nelle policy di autorizzazione IAM per concedere l'accesso alle Google Cloud risorse seguendo le istruzioni riportate in Utilizzare la federazione delle identità per i workload del parco risorse nelle applicazioni.

Trova il nome del pool di identità del workload 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 . Spesso è il nome del cluster.
- FLEET_PROJECT_ID: l'ID progetto del progetto host 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 è la stessa della località del cluster.
- WORKLOAD_IDENTITY_POOL: il nome del pool di identità del workload associato al parco risorse. Questo valore ha la sintassi FLEET_PROJECT_ID.svc.id.goog.
Crea un account di servizio IAM che la tua applicazione possa rappresentare. Puoi anche utilizzare qualsiasi service account IAM esistente.
```
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.
- IAM_SA_PROJECT_ID: l'ID progetto del progetto che contiene il account di servizio IAM. Può essere diverso dal progetto host del parco risorse.
Concedi al account di servizio IAM le autorizzazioni necessarie per accedere alle API aggiungendo le policy di autorizzazione IAM necessarie. Google Cloud Puoi farlo utilizzando gcloud iam service-accounts add-iam-policy-binding o un altro metodo. Puoi scoprire quali autorizzazioni sono necessarie per utilizzare le Google Cloud API nella documentazione di ogni servizio e visualizzare un elenco completo dei ruoli predefiniti con le autorizzazioni necessarie in Informazioni sui ruoli.
Crea un oggetto ServiceAccount Kubernetes in uno spazio dei nomi. Puoi anche utilizzare un oggetto ServiceAccount Kubernetes esistente e qualsiasi spazio dei nomi, inclusi l'oggetto ServiceAccount default e lo spazio dei nomi default.
```
kubectl create serviceaccount KSA_NAME \
    --namespace=NAMESPACE
```
Sostituisci quanto segue:
- KSA_NAME: il nome dell'oggetto ServiceAccount.
- NAMESPACE: il nome dello spazio dei nomi.

Crea una policy di autorizzazione IAM che consenta a un oggetto ServiceAccount Kubernetes in uno spazio dei nomi specifico del cluster di rappresentare 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à del workload.

Salva il seguente manifest come adc-config-map.yaml. Questo oggetto ConfigMap contiene la configurazione 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 rappresentare.
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 nell'oggetto 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'oggetto ServiceAccount Kubernetes come token. Kubernetes monta un JWT firmato per l'oggetto ServiceAccount come un file di token dell'oggetto ServiceAccount proiettato.

Il container nel pod monta il volume gcp-ksa nel percorso /var/run/secrets/tokens/gcp-ksa e configura ADC in modo che cerchi il file JSON di configurazione delle credenziali in questo percorso.

Esegui il deployment del workload:
```
kubectl apply -f workload-config.yaml
```

Verificare la configurazione della federazione delle identità per i workload del parco risorse

In questa sezione, creerai un bucket Cloud Storage e vi accederai da un pod che utilizza la federazione delle identità per i workload del parco risorse. Prima di eseguire questi passaggi, assicurati di aver configurato la federazione delle identità per i workload seguendo le istruzioni riportate nella sezione Utilizzare la federazione delle identità per i workload del parco risorse nelle applicazioni.

Questa sezione non mostra come verificare la federazione delle identità per i workload utilizzando il metodo di simulazione dell'identità dei account di servizio IAM.

Trova il numero 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 una Google Cloud località.

Crea una policy di autorizzazione IAM che conceda l'accesso al bucket al 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: l'ID progetto.
- NAMESPACE: il nome dello spazio dei nomi Kubernetes che esegue il pod della sezione precedente.
- KSA_NAME: il nome dell'oggetto ServiceAccount Kubernetes utilizzato dal pod della sezione precedente.
Best practice: crea policy di autorizzazione IAM che concedano la quantità minima di autorizzazioni per la risorsa specifica a cui il workload deve accedere.

Crea una sessione 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"
}

Eseguire l'autenticazione dal codice

Quando utilizzi le librerie client di Cloud, le librerie di autenticazione utilizzano automaticamente ADC per cercare le credenziali per l' autenticazione ai Google Cloud servizi. Devi utilizzare le librerie client di Cloud che supportano la federazione delle identità per i workload. Di seguito sono riportate le versioni minime richieste delle librerie client di Cloud, nonché le istruzioni per controllare la versione attuale:

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 queste credenziali, devi creare le librerie client con la versione 1.36.0 o successive di gRPC.

La libreria client di Cloud Storage per C++ utilizza l'API REST, non gRPC, quindi 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 la versione di questo modulo utilizzata dalla 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' com.google.auth:google-auth-library-oauth2-http artefatto.

Per controllare la versione di questo artefatto utilizzata 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 google-auth-library pacchetto.

Per controllare la versione di questo pacchetto utilizzata dalla 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 consentire a GoogleAuth di trovare automaticamente l'ID progetto. Per trovare automaticamente l'ID progetto, il account di servizio nel file di configurazione deve avere il ruolo Browser (roles/browser) o un ruolo con autorizzazioni equivalenti nel progetto. Per maggiori dettagli, consulta il README per il google-auth-library pacchetto.

Python

Le librerie client per Python supportano la federazione delle identità se utilizzano la versione 1.27.0 o successive del google-auth pacchetto.

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 ambiente GOOGLE_CLOUD_PROJECT oppure consentire al client di trovare automaticamente l'ID progetto. Per trovare automaticamente l'ID progetto, il service account nel file di configurazione deve avere il ruolo Browser (roles/browser) o un ruolo con autorizzazioni equivalenti nel progetto. Per maggiori dettagli, consulta la guida dell'utente per il google-auth pacchetto.

Passaggi successivi

Scopri le best practice per organizzare i parchi risorse quando utilizzi la federazione delle identità per i workload del parco risorse.