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

Questa pagina mostra come configurare le applicazioni per autenticarsi inGoogle Cloud API come l'API Compute Engine o l'API AI Platform da parchi risorse che hanno un modello di attendibilità condiviso in tutto il parco risorse. Se il tuo parco ha un modello di attendibilità misto, consulta Eseguire l'autenticazione per le API Google Cloud dai carichi di lavoro del parco con attendibilità mista (anteprima).

Questa pagina è rivolta agli amministratori e agli operatori della piattaforma e agli addetti alla sicurezza che vogliono autenticarsi in modo programmatico dai carichi di lavoro del parco risorse alle API. Google CloudPer scoprire di più sui ruoli utente e sulle attività di esempio a cui facciamo riferimento nella documentazione Google Cloud, consulta Ruoli utente e attività comuni di GKE Enterprise.

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

• Informazioni sulla federazione di Workload Identity del parco risorse
• ConfigMap di Kubernetes
• Criteri di autorizzazione IAM (Gestione di identità e accessi)

Informazioni sulla federazione di Workload Identity del parco risorse per gli ambienti con attendibilità condivisa

La federazione delle identità per i carichi di lavoro del parco risorse ti consente di eseguire l'autenticazione dai carichi di lavoro del parco risorse alle APIGoogle Cloud utilizzando i meccanismi di autenticazione integrati Google Cloud e di Kubernetes. La federazione di Workload Identity di Fleet elimina la necessità di utilizzare metodi meno sicuri come il montaggio di token di accesso nei pod o la memorizzazione di credenziali a lungo termine.

Per impostazione predefinita, il progetto host del parco risorse utilizza un pool di identità di carico di lavoro 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 per concedere l'accesso su larga scala in ambienti con attendibilità condivisa, come i parchi risorse monotenant, in cui non importa se altre persone ottengono involontariamente autorizzazioni simili per le risorse.

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.

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

Cluster esterni 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 progetto 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 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:

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

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 questi ultimi 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 alle entità Kubernetes nei criteri di autorizzazione IAM per concedere l'accesso alle risorseGoogle Cloud seguendo le istruzioni riportate in Utilizzare la federazione 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 progetto 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 service account 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 nella documentazione di ciascun servizio e visualizzare un elenco completo dei ruoli predefiniti con le autorizzazioni necessarie in Informazioni sui ruoli. Google Cloud

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 service account IAM da simulare.
   • IAM_SA_PROJECT_ID: l'ID progetto del service account 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:

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

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 delle identità di 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 Google Cloud posizione.

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 numerico 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 l'autenticazione 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:

cd $GOPATH/src/cloud.google.com/go
go list -m golang.org/x/oauth2

mvn dependency:list -DincludeArtifactIds=google-auth-library-oauth2-http

npm list google-auth-library

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