Utilizza Workload Identity del parco risorse

Spesso le applicazioni devono eseguire l'autenticazione (fornire un'identità autenticabile) quando si connettono ad altri servizi. Ad esempio, le applicazioni devono eseguire l'autenticazione per utilizzare le API Google Cloud come le API Compute Engine o AI Platform. In questa pagina viene spiegato come utilizzare Workload Identity del parco risorse, il modo più semplice e consigliato per eseguire l'autenticazione nelle API e nei servizi Google Cloud per i carichi di lavoro delle applicazioni ospitati in un parco risorse.

Cos'è Workload Identity del parco risorse?

Workload Identity del parco risorse estende la funzionalità fornita in Workload Identity di GKE, che consente ai carichi di lavoro nel tuo cluster di autenticarsi su Google senza che sia necessario scaricare, ruotare manualmente e in generale gestire le chiavi degli account di servizio Google Cloud. I carichi di lavoro vengono invece autenticati utilizzando token di breve durata generati dal cluster. Tutti i cluster in cui è abilitata l'identità dei carichi di lavoro GKE utilizzano il pool di identità per i carichi di lavoro del loro progetto durante l'emissione degli ID, il che consente a Identity and Access Management di considerare attendibili e comprendere le credenziali degli account di servizio Kubernetes. Puoi scoprire di più su Workload Identity di GKE in Utilizzo di Workload Identity.

Con i parchi risorse, i cluster registrati possono ottenere il vantaggio aggiuntivo dell'utilizzo di Floet Workload Identity. I cluster registrati con Workload Identity abilitato nell'appartenenza al parco risorse possono utilizzare il pool di identità dei carichi di lavoro a livello di parco risorse, semplificando la configurazione dell'autenticazione alle API di Google e ad altri servizi nel parco risorse e in più progetti. Workload Identity del parco risorse può essere utilizzato anche dall'agente Connect su alcuni tipi di cluster per eseguire l'autenticazione a Google come parte dell'appartenenza al parco risorse ed è necessario utilizzare alcune funzionalità di GKE Enterprise che funzionano su più progetti, come Cloud Service Mesh.

Come funziona

I parchi risorse utilizzano la federazione delle identità per i carichi di lavoro per fornire a ogni applicazione un'identità federata distinta che può essere utilizzata per l'autenticazione in Google Cloud e in altri servizi che sviluppi. Le applicazioni in esecuzione in un parco risorse ricevono un'identità dei carichi di lavoro federata nel seguente formato:

serviceAccount:FLEET_PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME]

Dove:

• FLEET_PROJECT_ID.svc.id.goog è una rappresentazione in formato breve del pool di identità per i carichi di lavoro per il parco risorse. Per ogni parco risorse è presente un solo pool di identità per i carichi di lavoro fisso, che viene creato automaticamente.
• K8S_NAMESPACE è lo spazio dei nomi Kubernetes in cui è definito l'account di servizio Kubernetes.
• KSA_NAME è il nome dell'account di servizio Kubernetes collegato all'applicazione.

Tutte le applicazioni ospitate in un parco risorse condividono lo stesso pool di identità per i carichi di lavoro, fornendo alle applicazioni un'identità federata che astrae la posizione in cui è ospitata ciascuna applicazione. In questo modo è possibile concedere a un'applicazione all'interno di un parco l'accesso a una risorsa (ad esempio un'API Google Cloud) una sola volta anziché cluster per cluster, anche se il deployment dell'applicazione viene eseguito in diversi progetti Google Cloud o in cloud diversi. Come per altre funzionalità abilitate per il parco risorse, si basa sul principio dell'identicità del parco risorse, in cui gli oggetti Kubernetes con lo stesso nome in cluster diversi vengono trattati come la stessa cosa. Quindi, ad esempio, se hai un'applicazione con un backend di cui è stato eseguito il deployment in più cluster nello stesso parco risorse e che deve eseguire l'autenticazione in un'API di Google, puoi configurare facilmente l'applicazione in modo che tutti i servizi nello spazio dei nomi "backend" possano accedere all'API. Per maggiori informazioni su come i parchi risorse utilizzano l'uguaglianza, inclusa l'identicità delle identità, consulta Come funzionano i parchi risorse.

I cluster esterni a Google Cloud possono anche utilizzare Workload Identity del parco risorse per fornire un'identità all'agente Connect per eseguire l'autenticazione su Google. Per saperne di più su quali tipi di cluster utilizzano Workload Identity del parco risorse, consulta la sezione Configurazione del cluster di seguito.

Prima di iniziare

• Assicurati di avere 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 automaticamente.

• Assicurati di aver inizializzato l'interfaccia alla gcloud CLI per utilizzarla con il tuo progetto.

Configurazione del cluster

Prima che le applicazioni nel parco risorse possano ricevere un'identità del carico di lavoro, i cluster su cui vengono eseguite devono essere registrati nel parco risorse e configurati correttamente per utilizzare Workload Identity. Il modo in cui esegui questa operazione dipende dal tipo di cluster. La maggior parte dei cluster GKE esterni a Google Cloud viene registrata automaticamente nel parco progetti quando li crei. I cluster GKE su Google Cloud e i cluster collegati devono essere registrati manualmente.

Per ulteriori informazioni sulla configurazione del cluster, consulta la documentazione relativa a ciascun tipo di cluster.

GKE

1. Abilita GKE Workload Identity sul cluster Google Kubernetes Engine, se non è già abilitato.
2. Segui le istruzioni per registrare il cluster utilizzando Workload Identity.

Cluster GKE esterni a Google Cloud

I cluster on-premise su VMware e on bare metal e cluster GKE multi-cloud (sia su AWS che su Azure) vengono registrati automaticamente nel parco risorse al momento della creazione del cluster. Tutti questi tipi di cluster abilitano automaticamente Workload Identity del parco risorse quando viene registrato.

Cluster collegati

I cluster collegati EKS e AKS registrati utilizzando l'API GKE Multi-Cloud sono registrati con Workload Identity del parco risorse abilitato per impostazione predefinita. Altri cluster collegati possono essere registrati con Workload Identity del parco risorse abilitato se soddisfano i requisiti necessari. Segui le istruzioni per il tipo di cluster descritte in Registrazione di un cluster.

Utilizza Workload Identity del parco risorse

Dopo aver registrato il cluster, i carichi di lavoro di cui è stato eseguito il deployment nel cluster possono utilizzare le identità dei carichi di lavoro dal pool di identità dei carichi di lavoro del parco risorse. Questa sezione mostra come utilizzare l'identità del carico di lavoro per impersonare un account di servizio Google Cloud in modo che i carichi di lavoro possano accedere alle API Google Cloud. Agire come account di servizio è un caso d'uso comune per le identità federate, in quanto consente ai carichi di lavoro di autenticarsi a qualsiasi API Google Cloud a cui l'account di servizio ha accesso, eliminando il carico di manutenzione e sicurezza della gestione delle chiavi degli account di servizio per ogni carico di lavoro.

Rappresentare un account di servizio

Questa sezione mostra come configurare l'identità del carico di lavoro federato di un'applicazione per impersonare un account di servizio fornendo un file delle credenziali predefinite dell'applicazione in un ConfigMap, compresa la creazione e la configurazione dell'account di servizio con le autorizzazioni pertinenti.

L'esempio utilizza i seguenti valori segnaposto:

• WORKLOAD_IDENTITY_POOL è il pool di identità per i carichi di lavoro associato al tuo parco risorse. Come mostrato sopra, il valore di WORKLOAD_IDENTITY_POOL è FLEET_PROJECT_ID.svc.id.goog.
• IDENTITY_PROVIDER è il nome del provider di identità associato al tuo cluster Kubernetes.
• K8S_NAMESPACE è lo spazio dei nomi Kubernetes in cui è definito l'account di servizio Kubernetes.
• KSA_NAME è il nome dell'account di servizio Kubernetes collegato all'applicazione.
• GSA_NAME è il nome dell'account di servizio Google con cui agirà la tua applicazione.
• GSA_PROJECT_ID è l'ID progetto in cui è definito l'account di servizio Google.

Per configurare l'identità del carico di lavoro del parco risorse per impersonare un account di servizio:

1. Assicurati che il cluster sia registrato nel parco risorse seguendo i passaggi nella sezione Configurazione del cluster in alto.

2. Recupera i valori WORKLOAD_IDENTITY_POOL e IDENTITY_PROVIDER per il cluster registrato recuperando i dettagli dell'abbonamento al parco risorse del cluster con il comando seguente. Sostituisci MEMBERSHIP con il nome univoco dell'appartenenza del cluster nel parco risorse:

   gcloud container fleet memberships describe MEMBERSHIP
   

   L'output della descrizione dell'abbonamento sarà simile al seguente (alcuni campi sono stati omessi per maggiore chiarezza):

   authority:
    identityProvider: IDENTITY_PROVIDER
    workloadIdentityPool: WORKLOAD_IDENTITY_POOL
   name: projects/FLEET_PROJECT_ID/locations/global/memberships/MEMBERSHIP
   

3. Crea un account di servizio Google Cloud che la tua applicazione può impersonare durante l'autenticazione su Google, se non ne hai già uno:

   gcloud iam service-accounts create GSA_NAME --project=GSA_PROJECT_ID
   

   Non è necessario che l'account di servizio si trovi nel progetto host del parco risorse. Puoi utilizzare qualsiasi account di servizio Google Cloud della tua organizzazione. Puoi scoprire di più sugli account di servizio e sul loro funzionamento in Account di servizio.

4. Assicurati di aver concesso all'account di servizio le autorizzazioni necessarie per accedere alle API Google Cloud aggiungendo le associazioni di criteri IAM necessarie. Puoi farlo utilizzando gcloud iam service-accounts add-iam-policy-binding o un altro metodo, se preferisci. Puoi trovare le autorizzazioni necessarie per utilizzare le API Google Cloud nella documentazione di ciascun servizio e visualizzare un elenco completo dei ruoli predefiniti con le autorizzazioni necessarie nella sezione Informazioni sui ruoli.

5. Autorizza l'identità del carico di lavoro dell'applicazione a impersonare l'account di servizio creando un'associazione di criteri IAM, come descritto di seguito. Questa associazione consente all'identità dei carichi di lavoro federata dell'applicazione di agire come account di servizio Google Cloud.

   gcloud iam service-accounts add-iam-policy-binding \
     GSA_NAME@GSA_PROJECT_ID.iam.gserviceaccount.com \
     --role=roles/iam.workloadIdentityUser \
     --member="serviceAccount:WORKLOAD_IDENTITY_POOL[K8S_NAMESPACE/KSA_NAME]"
   

   Il campo --member è la rappresentazione di IAM dell'identità del carico di lavoro federato dell'applicazione.

6. Crea un ConfigMap contenente il file delle credenziali predefinite dell'applicazione per il carico di lavoro. Questo file indica alla libreria client compilata nel tuo carico di lavoro come eseguire l'autenticazione su Google. Il file delle credenziali predefinite dell'applicazione contiene le informazioni pertinenti sul pool di identità per i carichi di lavoro e sull'account di servizio, nonché il percorso del token previsto che verrà montato nel file system del container nel passaggio successivo. GSA_NAME@GSA_PROJECT_ID.iam.gserviceaccount.com è l'indirizzo email dell'account di servizio da impersonare.

   Questa configurazione in sé non concede l'accesso per impersonare l'account di servizio. Se non esiste anche l'associazione IAM, il pod non sarà in grado di utilizzare l'account di servizio.

   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/GSA_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"
         }
       }
   

7. Segui l'esempio riportato di seguito per configurare il carico di lavoro. Tieni presente che il ConfigMap del passaggio precedente è montato nel file system del container come google-application-credentials.json, insieme a un file token dell'account di servizio previsto, in /var/run/secrets/tokens/gcp-ksa. I token previsti vengono emessi da Kubernetes e rappresentano l'identità del carico di lavoro all'interno del cluster. Questi token vengono scambiati automaticamente con Google dalle librerie client di Cloud per ottenerne l'autenticazione con le API di Google. Il campo audience del token previsto deve essere impostato sul valore WORKLOAD_IDENTITY_POOL.

   kind: Namespace
   apiVersion: v1
   metadata:
     name:  K8S_NAMESPACE
   ---
   kind: ServiceAccount
   apiVersion: v1
   metadata:
     namespace:  K8S_NAMESPACE
     name: KSA_NAME
   automountServiceAccountToken: false
   ---
   apiVersion: v1
   kind: Pod
   metadata:
     name: my-pod
     namespace:  K8S_NAMESPACE
   spec:
     serviceAccountName: KSA_NAME
     containers:
     - name: my-container
       image: my-image
       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"
   
   

Autenticazione dal codice

Le librerie client di Cloud gestiscono automaticamente l'autenticazione in Google Cloud quando le utilizzi per accedere ai servizi Google dal tuo codice. Per utilizzare la configurazione descritta sopra nelle tue applicazioni, devi utilizzare le librerie client di Cloud che supportano la federazione delle identità per i carichi di lavoro. 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 librerie client di Google Cloud per C++ supporta la federazione delle identità utilizzando un oggetto ChannelCredentials creato chiamando grpc::GoogleDefaultCredentials(). Per inizializzare questa 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, 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 successiva del modulo golang.org/x/oauth2.

Per verificare quale versione di questo modulo utilizza la tua libreria client, esegui questi 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'artefatto com.google.auth:google-auth-library-oauth2-http.

Per verificare quale 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 pacchetto google-auth-library.

Per verificare quale versione di questo pacchetto viene utilizzata dalla libreria client, esegui questo comando nella directory dell'applicazione:

npm list google-auth-library

Quando crei un oggetto GoogleAuth, puoi specificare un ID progetto o consentire a GoogleAuth di trovare automaticamente l'ID progetto. Per trovare automaticamente l'ID progetto, l'account di servizio nel file di configurazione deve avere il ruolo Browser (roles/browser) o un ruolo con autorizzazioni equivalenti, nel tuo progetto. Per maggiori dettagli, consulta la sezione 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 verificare quale versione di questo pacchetto è utilizzata dalla libreria client, esegui questo 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 puoi consentire al client di trovare l'ID progetto automaticamente. Per trovare automaticamente l'ID progetto, l'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 la guida dell'utente per il pacchetto google-auth.