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 tue applicazioni devono autenticarsi per utilizzare le API Google Cloud come le API Compute Engine o AI Platform. Questa pagina spiega come utilizzare Workload Identity del parco risorse, il modo più semplice e consigliato per i carichi di lavoro delle applicazioni ospitati in un parco risorse di eseguire l'autenticazione alle API e ai servizi Google Cloud.

Che cos'è Workload Identity del parco risorse?

Fleet Workload Identity estende la funzionalità fornita in GKE Workload Identity, che consente ai carichi di lavoro nel tuo cluster di eseguire l'autenticazione su Google senza che tu debba scaricare, ruotare manualmente e gestire in generale le chiavi degli account di servizio Google Cloud. Al contrario, i carichi di lavoro si autenticano utilizzando token di breve durata generati dal cluster. Tutti i cluster in cui è abilitata GKE Workload Identity utilizzano il pool di identità del carico di lavoro del progetto quando emettono gli ID, che consente a Identity and Access Management di considerare attendibili e comprendere le credenziali dell'account di servizio Kubernetes. Puoi scoprire di più su GKE Workload Identity in Utilizzare Workload Identity.

Con i parchi risorse, i cluster registrati possono ottenere il vantaggio aggiuntivo dell'utilizzo di Workload Identity del parco risorse. I cluster registrati con Workload Identity abilitato nell'appartenenza al parco risorse possono utilizzare il pool di identità dei carichi di lavoro del parco risorse a livello di parco risorse, semplificando la configurazione dell'autenticazione per le API di Google e altri servizi nel parco risorse e su più progetti. Fleet Workload Identity può essere utilizzato anche dall'agente Connect su alcuni tipi di cluster per eseguire l'autenticazione su Google nell'ambito dell'abbonamento al parco risorse ed è necessario per utilizzare alcune funzionalità di GKE Enterprise valide su più progetti, ad esempio Anthos 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 possa essere utilizzata per l'autenticazione su Google Cloud e su altri servizi sviluppati da te. 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 breve del pool di identità del carico di lavoro per il tuo parco risorse. È presente un solo pool di identità per i carichi di lavoro fisso per parco risorse, 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 ogni applicazione. Ciò consente di concedere a un'applicazione all'interno di un parco risorse l'accesso a una risorsa (ad esempio un'API Google Cloud) una sola volta, anziché cluster per cluster, anche se il deployment dell'applicazione è stato eseguito su progetti Google Cloud o su cloud diversi. Come per altre funzionalità abilitate per il parco risorse, questo si basa sul principio dell'identicità del parco risorse, secondo il quale gli oggetti Kubernetes con lo stesso nome in cluster diversi vengono trattati come la stessa cosa. 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 con un'API di Google, puoi configurare facilmente la tua applicazione in modo che tutti i servizi nello spazio dei nomi "backend" possano accedere all'API. Per saperne di più su come i parchi risorse utilizzano l'identicità, inclusa l'identicità dell'identità, vai a Come funzionano i parchi risorse.

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

Prima di iniziare

  • Assicurati di aver 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 sono installati automaticamente.

  • Assicurati di aver inizializzato gcloud CLI per utilizzarlo con il tuo progetto.

Configurazione del cluster

Prima che le applicazioni del tuo parco risorse possano ricevere un'identità del carico di lavoro, i cluster su cui vengono eseguite devono essere registrati nel tuo parco risorse e configurati correttamente per l'utilizzo di Workload Identity del parco risorse. 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 risorse di progetti quando li crei. I cluster GKE su Google Cloud e i cluster collegati devono essere registrati manualmente.

Per saperne di più sulla configurazione del cluster, consulta la documentazione relativa a ciascun tipo di cluster.

GKE

  1. Abilita GKE Workload Identity sul tuo 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

GKE su VMware, GKE su Bare Metal e i cluster GKE multi-cloud (su AWS e Azure) vengono registrati automaticamente nel parco risorse di progetti al momento della creazione del cluster. A partire da GKE Enterprise 1.8, tutti questi tipi di cluster abilitano automaticamente Workload Identity del parco risorse quando sono registrati. I cluster registrati esistenti vengono aggiornati in modo da utilizzare Workload Identity quando viene eseguito l'upgrade a GKE Enterprise 1.8 o versioni successive.

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 relative al tipo di cluster 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 provenienti dal pool di identità dei carichi di lavoro del parco risorse. Questa sezione mostra come utilizzare Workload Identity 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 in qualsiasi API Google Cloud a cui ha accesso l'account di servizio, eliminando il carico di manutenzione e sicurezza di dover gestire le 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 in modo da impersonare un account di servizio fornendo un file delle credenziali predefinite dell'applicazione in un ConfigMap, incluse 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à del carico 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 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 verrà eseguita la tua applicazione.
  • GSA_PROJECT_ID è l'ID progetto in cui è definito l'account di servizio Google.

Per configurare un'identità del carico di lavoro del parco risorse in modo da impersonare un account di servizio:

  1. Assicurati che il cluster sia registrato nel parco risorse seguendo i passaggi descritti nella sezione Configurazione del cluster qui sopra.

  2. Per ottenere i valori di WORKLOAD_IDENTITY_POOL e IDENTITY_PROVIDER per il cluster registrato, recupera i dettagli dell'appartenenza al parco risorse del cluster utilizzando il comando seguente. Sostituisci MEMBERSHIP con il nome univoco del tuo cluster nel parco risorse:

    gcloud container fleet memberships describe MEMBERSHIP

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

    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

    L'account di servizio non deve necessariamente essere nel progetto host del parco risorse. Puoi utilizzare qualsiasi account di servizio Google Cloud nella tua organizzazione. Puoi trovare ulteriori informazioni 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 in 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 indicato di seguito. Questa associazione consente all'identità dei carichi di lavoro federata della tua 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 IAM dell'identità dei carichi di lavoro federati della tua applicazione.

  6. Crea un ConfigMap contenente il file delle credenziali predefinite dell'applicazione per il tuo carico di lavoro. Questo file indica alla libreria client compilata nel 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 da sola 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 seguente 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 ottenere token che possano autenticarsi 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 tuo codice

Le librerie client 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 di Workload Identity. Di seguito sono riportate le versioni minime delle librerie client di Cloud, nonché le istruzioni su come verificare la versione attuale:

C++

La maggior parte delle librerie client di Google Cloud per C++ supporta la federazione delle identità mediante l'utilizzo di un oggetto ChannelCredentials, creato chiamando grpc::GoogleDefaultCredentials(). Per inizializzare questa credenziali, devi creare le librerie client con la versione 1.36.0 o successiva 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 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 utilizza la tua 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 successiva del pacchetto google-auth-library.

Per verificare quale versione di questo pacchetto viene utilizzata dalla tua 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 progetto. Per maggiori dettagli, consulta il documento 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 successiva del pacchetto google-auth.

Per verificare quale versione di questo pacchetto viene utilizzata dalla tua 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 o consentire al client 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 progetto. Per i dettagli, consulta la guida dell'utente per il pacchetto google-auth.