Utilizza Workload Identity del parco risorse

Spesso le applicazioni devono autenticarsi (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 l'autenticazione ai servizi e alle API di Google Cloud dei carichi di lavoro delle applicazioni ospitati in un parco risorse.

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, 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 è abilitato GKE Workload Identity utilizzano il pool di identità del carico di lavoro del progetto per emettere gli ID, il 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 usufruire dell'ulteriore vantaggio di utilizzare il parco risorse Workload Identity. 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 e altri servizi di Google nel parco risorse e in più progetti. Fleet Workload Identity può essere utilizzato anche dall'agente Connect su alcuni tipi di cluster per autenticarsi su Google come parte dell'appartenenza al parco risorse ed è necessario per utilizzare alcune funzionalità di GKE Enterprise che funzionano 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. Esiste un solo pool di identità per carichi di lavoro fisso per parco risorse ed è creato automaticamente per te.
  • K8S_NAMESPACE è lo spazio dei nomi Kubernetes in cui viene 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à del carico di lavoro, fornendo alle applicazioni un'identità federata che astrae la posizione in cui è ospitata ogni applicazione. In questo modo è possibile 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 in progetti Google Cloud o in cloud diversi. Come altre funzionalità abilitate per il parco risorse, si basa sul principio dell'uguaglianza, 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 implementato 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 lo stesso, incluso l'uguaglianza dell'identità, in 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 su Google. Per saperne di più sui tipi di cluster che utilizzano Workload Identity del parco risorse, consulta la sezione sulla configurazione dei cluster di seguito.

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 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à Workload Identity, i cluster su cui vengono eseguiti devono essere registrati nel parco risorse e configurati correttamente per l'utilizzo di Workload Identity del parco risorse. La modalità 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 quelli collegati devono essere registrati manualmente.

Consulta la documentazione relativa a ciascun tipo di cluster per ulteriori informazioni sulla configurazione del 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 cluster GKE multi-cloud (sia su AWS che su Azure) vengono registrati automaticamente nel tuo parco 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 vengono 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 a 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 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 del 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 su 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 per 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 viene 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à di un carico di lavoro del parco risorse in modo che rappresenti un account di servizio:

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

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

    gcloud container fleet memberships describe MEMBERSHIP
    

    L'output della descrizione dell'appartenenza ha il seguente aspetto (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
    

    L'account di servizio non deve necessariamente essere incluso nel progetto host del parco risorse. Puoi utilizzare qualsiasi account di servizio Google Cloud nella 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. A questo scopo, puoi utilizzare 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 della tua applicazione a impersonare l'account di servizio creando un'associazione di criteri IAM, come indicato di seguito. Questa associazione consente all'identità federata dei carichi di lavoro 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 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à dei 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 potrà 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 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 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 usare le librerie client di Cloud che supportano la federazione di Workload Identity. Di seguito sono riportate le versioni minime delle librerie client Cloud richieste, 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à tramite 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 viene utilizzata dalla 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 utilizza la 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 oppure consentire a GoogleAuth di trovare automaticamente l'ID progetto. Per trovare automaticamente l'ID progetto, l'account di servizio nel file di configurazione deve disporre del ruolo Browser (roles/browser) o con autorizzazioni equivalenti nel progetto. Per maggiori dettagli, vedi la pagina 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 utilizza la 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 oppure 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.