Utilizza il parco risorse Workload Identity

Spesso le applicazioni devono eseguire l'autenticazione (forniscono un'identità autenticabile) quando si connettono ad altri servizi. Ad esempio, le tue applicazioni devono eseguire l'autenticazione per utilizzare le API di Google Cloud come le API di Compute Engine o AI Platform. Questa pagina spiega come utilizzare il servizio Workload Identity, il modo più semplice e consigliato per consentire ai carichi di lavoro delle applicazioni ospitati in un parco risorse di eseguire l'autenticazione nelle API e nei servizi Google Cloud.

Cos'è il parco risorse Workload Identity?

Fleet Workload Identity estende la funzionalità fornita in GKE Workload Identity, che consente ai carichi di lavoro nel cluster di autenticarsi a Google senza richiedere il download, la rotazione manuale e la gestione generale delle 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 per cui è abilitata l'identità del carico di lavoro GKE utilizzano il pool di identità del carico di lavoro del progetto quando emettono ID, il che consente a Identity and Access Management di affidarsi e comprendere le credenziali dell'account di servizio Kubernetes. Per saperne di più su GKE Workload Identity, vedi Utilizzo di Workload Identity.

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

Come funziona

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

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

Dove:

  • FLEET_PROJECT_ID.svc.id.goog è una rappresentazione in forma breve del pool di identità del carico di lavoro per il tuo parco risorse. È disponibile un solo pool di identità del carico di lavoro fisso per parco risorse e 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 associato all'applicazione.

Tutte le applicazioni in hosting su un parco risorse condividono lo stesso pool di identità dei carichi di lavoro, fornendo applicazioni con un'identità federata che astrae la posizione in cui ogni applicazione è ospitata. 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 avviene su più progetti Google Cloud o su cloud diversi. Come altre funzionalità abilitate per il parco risorse, questo si basa sul principio del parco risorse sameness, 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 backend sottoposto a deployment in più cluster nello stesso parco risorse e che deve eseguire l'autenticazione in un'API Google, puoi configurare facilmente la tua applicazione in modo che tutti i servizi nello spazio dei nomi "backend" possano accedere a questa API. Puoi trovare molte altre informazioni su come i parchi risorse utilizzano la stessa identità, inclusa la stessa identità, in Come funzionano i parchi risorse.

I cluster esterni a Google Cloud possono anche utilizzare il parco risorse Workload Identity per fornire un'identità per l'agente Connect per l'autenticazione su Google. Puoi trovare ulteriori informazioni in merito nella pagina relativa alla registrazione di un cluster.

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 vengono installati automaticamente.

  • Assicurati di aver inizializzato l'interfaccia a riga di comando gcloud da utilizzare con il tuo progetto.

Configurazione del cluster

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

Consulta la documentazione di 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 lo è già.
  2. Segui le istruzioni per registrare il cluster utilizzando Workload Identity.

Cluster Anthos esterni a Google Cloud

I cluster Anthos su VMware, i cluster Anthos su Bare Metal e i cluster Anthos multi-cloud (sia su AWS che su Azure) vengono registrati automaticamente nel tuo parco risorse di progetto al momento della creazione del cluster. A partire da Anthos 1.8, tutti questi tipi di cluster abilitano automaticamente Workload Identity quando è registrato. I cluster registrati esistenti vengono aggiornati in modo da utilizzare Workload Identity quando vengono aggiornati ad Anthos 1.8 o versioni successive.

Cluster collegati

I cluster collegati possono essere registrati con Workload Identity attivo abilitato se soddisfano i requisiti necessari. Segui le istruzioni per il tuo tipo di cluster in Registrazione di un cluster.

Utilizza il parco risorse Workload Identity

Dopo aver registrato il cluster, i carichi di lavoro di cui si esegue 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 rubare l'identità di un account di servizio Google Cloud in modo che i tuoi carichi di lavoro possano accedere alle API Google Cloud. Agire come account di servizio è un caso d'uso comune per le identità federate, poiché consente ai carichi di lavoro di eseguire l'autenticazione in qualsiasi API Google Cloud a cui ha accesso l'account di servizio, eliminando così la necessità di gestire e gestire le chiavi degli account di servizio per ogni carico di lavoro.

Utilizza identità account di servizio

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

Nell'esempio vengono utilizzati i seguenti valori segnaposto:

  • WORKLOAD_IDENTITY_POOL è il pool di identità del carico di lavoro associato al 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 associato 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 per impersonare un account di servizio:

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

  2. Recupera i valori WORKLOAD_IDENTITY_POOL e IDENTITY_PROVIDER per il cluster registrato recuperando i dettagli dell'iscrizione al parco risorse del cluster, utilizzando il comando seguente. Sostituisci MEMBERSHIP con il nome dell'abbonamento 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ò rappresentare quando esegue 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 far parte del tuo progetto host del parco risorse. Puoi utilizzare qualsiasi account di servizio Google Cloud nella tua organizzazione. Per saperne di più sugli account di servizio e su come funzionano, consulta Account di servizio.

  4. Assicurati di aver concesso all'account di servizio tutte le autorizzazioni necessarie per accedere alle API Google Cloud aggiungendo le associazioni di criteri IAM necessarie. Per farlo 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 ogni 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 rappresentare l'account di servizio creando un'associazione dei criteri IAM, come segue. Questa associazione consente all'identità del carico di lavoro federato 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 di IAM dell'identità del carico di lavoro federato della tua applicazione.

  6. Crea un ConfigMap che contenga il file delle credenziali predefinite dell'applicazione per il carico di lavoro. Questo file indica alla libreria client compilata nel carico di lavoro come eseguire l'autenticazione su Google. Il file delle credenziali predefinito 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 su cui impersonare.

    Questa configurazione da sola non concede l'accesso per impersonare l'account di servizio. Se l'associazione IAM non esiste anche, il pod non può 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 tuo carico di lavoro. Nota che l'oggetto ConfigMap del passaggio precedente viene 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 ottenerli che possono essere autenticati con le API di Google. Il campo audience del token previsto deve essere impostato sul valore di 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"

Esegui l'autenticazione dal tuo codice

Le librerie client di Cloud gestiscono automaticamente l'autenticazione in Google Cloud quando le utilizzi per accedere ai servizi Google dal 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 richieste delle librerie client di Cloud, oltre alle istruzioni su come verificare la versione corrente:

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 credenziale 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 versioni successive 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 una versione successiva dell'artefatto com.google.auth:google-auth-library-oauth2-http.

Per controllare quale versione di questo artefatto utilizza la tua libreria client, esegui il seguente comando Maven nella directory della tua 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 controllare quale versione di questo pacchetto è 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 sul progetto. Per i dettagli, consulta la pagina README relativa al 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 controllare quale versione di questo pacchetto è utilizzata dalla libreria client, esegui il comando seguente 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 sul progetto. Per i dettagli, consulta la guida dell'utente per il pacchetto google-auth.