Esegui l'autenticazione nelle API Google Cloud dai workload del parco risorse con attendibilità mista

Questa pagina mostra come configurare le applicazioni per l'autenticazione alle APIGoogle Cloud come l'API Compute Engine o l'API AI Platform da flotte con un modello di trust misto. Se il tuo parco auto ha un modello di attendibilità condivisa, consulta Autenticarsi alle Google Cloud API dai carichi di lavoro del parco auto con attendibilità condivisa.

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

Prima di leggere questa pagina, assicurati di avere familiarità con i seguenti concetti:

Informazioni sulla federazione delle identità per i workload del parco risorse per ambienti con attendibilità mista

La federazione delle identità del workload del parco risorse ti consente di concedere ruoli IAM su API e risorseGoogle Cloud a entità nel tuo parco risorse, come i workload in uno spazio dei nomi specifico. Per impostazione predefinita, il progetto host del parco risorse utilizza un pool di identità dei carichi di lavoro gestito da Google per eseguire il provisioning delle identità per le entità nel parco risorse. Tuttavia, in ambienti con attendibilità mista, come parchi risorse multi-tenant o in progetti host di parchi risorse che eseguono cluster autonomi, ti consigliamo di configurare un pool di identità del carico di lavoro autogestito separato per un sottoinsieme dei tuoi carichi di lavoro e cluster.

Le entità che utilizzano un pool di identità del workload autogestito hanno identificatori diversi nei criteri IAM rispetto alle entità che utilizzano il pool di identità del workload gestito da Google del progetto host del parco risorse. In questo modo, la concessione dell'accesso ai principal in uno spazio dei nomi del parco specifico non concede inavvertitamente l'accesso ad altri principal che corrispondono all'identificatore.

I pool di identità del workload autogestiti richiedono l'utilizzo degli ambiti del team. Gli ambiti dei team consentono di controllare l'accesso a sottoinsiemi di risorse del parco risorse in base al team. Colleghi ambiti specifici del team a cluster specifici dei membri del parco risorse per consentire al team di eseguire il deployment dei carichi di lavoro su questi cluster. All'interno di un ambito del team, i membri del team possono eseguire il deployment dei workload solo negli spazi dei nomi del parco risorse.

L'utilizzo di pool di identità dei workload autogestiti per fornire identità per i workload con ambito team offre vantaggi come i seguenti:

  • Assicurati che le concessioni di accesso alle entità negli spazi dei nomi del parco risorse non vengano applicate involontariamente alle entità in altri spazi dei nomi o cluster.
  • Configura un insieme di cluster del parco risorse per ottenere le identità dal pool autogestito associandole a un ambito del team e configurando il pool autogestito come provider di identità in questi cluster.
  • Configura un sottoinsieme dei cluster associati all'ambito di un team per ottenere le identità dal pool autogestito configurando solo il pool autogestito come provider di identità in cluster specifici.

Esempio di identità identiche in un ambiente con attendibilità mista

Considera il seguente scenario:

  • Hai due cluster membri del parco risorse: frontend-cluster e finance-cluster.
  • Non hai configurato un pool di identità del workload autogestito.
  • Crea un ambito del team finance-team e uno spazio dei nomi del parco risorse finance-ns nell'ambito del team.
  • Colleghi il cluster finance-cluster all'ambito del team finance-team.
  • Concedi un ruolo IAM al ServiceAccount finance-sa Kubernetes nello spazio dei nomi del parco finance-ns.

Tutti i workload che soddisfano i seguenti criteri condividono la stessa identità:

  • Esegui nello spazio dei nomi del parco risorse finance-ns.
  • Utilizza ServiceAccount finance-sa.

Tuttavia, se qualcuno nel cluster frontend-cluster crea uno spazio dei nomi Kubernetes finance-ns e un service account finance-sa, ottiene la stessa identità dei carichi di lavoro nel cluster finance-cluster. Questo perché l'intero parco risorse utilizza il pool di identità dei workload gestito da Google del progetto host del parco risorse e perché l'identificatore dell'entità non specifica un cluster host.

Considera le seguenti modifiche allo scenario precedente:

  • Configuri un pool di identità del workload autogestito nel tuo parco risorse.
  • Configura il cluster finance-cluster per ottenere le identità dal pool autogestito anziché da quello gestito da Google.
  • Crea una concessione di ruolo IAM che specifica il pool autogestito nell'identificatore dell'entità anziché il pool gestito da Google.

I workload eseguiti nello spazio dei nomi del parco progetti finance-ns in finance-cluster ora ottengono un'identità dal pool autogestito. Tuttavia, le entità nello spazio dei nomi Kubernetes finance-ns nel cluster frontend-cluster continuano a ottenere identità dal pool di identità del workload gestito da Google del progetto host del parco progetti.

Queste modifiche comportano i seguenti vantaggi:

  • Puoi concedere esplicitamente ruoli alle entità nello spazio dei nomi del parco veicoli finance-ns.
  • Le entità nel cluster frontend-cluster non possono ottenere lo stesso accesso perché le identità nel cluster frontend-cluster provengono dal pool di identità del workload gestito da Google.

Prima di iniziare

  • Assicurati di aver 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 gcloud CLI per l'utilizzo con il tuo progetto.

Requisiti

Devi utilizzare le funzionalità di gestione dei team del parco risorse, come gli ambiti dei team e gli spazi dei nomi del parco risorse, nel tuo parco risorse. Le istruzioni riportate in questa pagina mostrano come configurare un ambito del team e uno spazio dei nomi del parco risorse di esempio.

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 nel tuo parco risorse e configurati correttamente per utilizzare la federazione delle identità dei 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, procedi nel seguente modo:

  1. Abilita la federazione delle identità dei carichi di lavoro per GKE nel cluster Google Kubernetes Engine, se non è già abilitata.
  2. Registra il cluster nel parco risorse.

Puoi anche abilitare la federazione delle identità per i carichi di lavoro per GKE durante la creazione del cluster e la registrazione del parco risorse.

Cluster esterni a Google Cloud

I seguenti tipi di cluster attivano automaticamente la federazione delle identità dei carichi di lavoro del parco risorse e vengono registrati nel tuo 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 EKS e AKS collegati registrati utilizzando l'API GKE Multi-Cloud vengono registrati con la federazione delle identità dei carichi di lavoro del parco risorse abilitata per impostazione predefinita. Gli 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.

Configura un pool di identità del workload IAM

In questa sezione, crei un nuovo pool di identità del workload IAM nel progetto host del parco risorse e concedi all'agente di servizio del parco risorse l'accesso al nuovo pool.

  1. Crea un pool di identità del workload:

    gcloud iam workload-identity-pools create POOL_NAME \
    --location=global \
    --project=POOL_HOST_PROJECT_ID \
    --mode=TRUST_DOMAIN

    Sostituisci quanto segue:

    • POOL_NAME: il nome del nuovo pool di identità del workload.
    • POOL_HOST_PROJECT_ID: l'ID del progetto in cui vuoi creare il pool di identità del workload autogestito Puoi utilizzare qualsiasi progetto Google Cloud , incluso il progetto host del parco risorse.

  2. Concedi il ruolo Amministratore pool Workload Identity IAM (roles/iam.workloadIdentityPoolAdmin) nel nuovo pool di identità del workload all'agente di servizio del parco risorse:

    gcloud iam workload-identity-pools add-iam-policy-binding POOL_NAME \
    --project=POOL_HOST_PROJECT_ID \
    --location=global \
    --member=serviceAccount:service-FLEET_HOST_PROJECT_NUMBER@gcp-sa-gkehub.iam.gserviceaccount.com \
    --role=roles/iam.workloadIdentityPoolAdmin \
    --condition=None

    Sostituisci FLEET_HOST_PROJECT_NUMBER con il numero di progetto del progetto host del parco risorse.

Aggiungi il pool autogestito alla configurazione del parco risorse

In questa sezione, abiliti i pool autogestiti con la federazione delle identità per i carichi di lavoro del parco risorse e aggiungi il pool che hai creato alla configurazione del parco risorse. Questa sezione fornisce anche istruzioni per creare un nuovo ambito del team e uno spazio dei nomi del parco risorse. Se il tuo parco risorse ha già configurato gli ambiti del team e gli spazi dei nomi del parco risorse, salta questi passaggi.

  1. Abilita la federazione delle identità per i workload del parco risorse a livello di parco risorse:

    gcloud beta container fleet workload-identity enable \
  --project=FLEET_HOST_PROJECT_ID

    Sostituisci FLEET_HOST_PROJECT_ID con l'ID progetto del tuo progetto host del parco.

  2. Aggiungi il pool di identità del workload autogestito alla configurazione del parco:

    gcloud beta container fleet workload-identity scope-tenancy-pool set POOL_NAME

    Sostituisci POOL_NAME con il nome del tuo pool di identità del workload autogestito. Questo valore ha la seguente sintassi:

    POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog

  3. Crea un nuovo ambito del team. Se hai uno spazio dei nomi di team e flotta esistente, vai alla sezione Verifica la configurazione del pool di identità del workload.

    gcloud container fleet scopes create SCOPE_NAME

    Sostituisci SCOPE_NAME con il nome del nuovo ambito del team.

  4. Crea un nuovo spazio dei nomi del parco risorse nell'ambito del team:

    gcloud container fleet scopes namespaces create NAMESPACE_NAME \
    --scope=SCOPE_NAME

    Sostituisci NAMESPACE_NAME con il nome del nuovo spazio dei nomi del parco.

  5. Associa un cluster nel tuo parco risorse all'ambito del team:

    gcloud container fleet memberships bindings create BINDING_NAME \
    --membership=FLEET_CLUSTER_NAME \
    --location=global \
    --scope=SCOPE_NAME

    Sostituisci quanto segue:

    • BINDING_NAME: il nome del nuovo binding dell'abbonamento.
    • FLEET_CLUSTER_NAME: il nome del cluster fleet esistente a cui associare l'ambito del team.

Verifica la configurazione del pool di identità del workload

In questa sezione, ti assicuri che la configurazione del pool di identità per i carichi di lavoro autogestito sia andata a buon fine.

  1. Descrivi la configurazione dell'appartenenza al parco risorse:

    gcloud container fleet memberships describe FLEET_CLUSTER_NAME \
    --location=global

    Sostituisci FLEET_CLUSTER_NAME con il nome di un cluster del parco risorse esistente associato a un ambito del team nel tuo parco risorse.

    L'output è simile al seguente:

    authority:
...
  scopeTenancyIdentityProvider: https://gkehub.googleapis.com/projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/FLEET_CLUSTER_NAME
  scopeTenancyWorkloadIdentityPool: POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog
  workloadIdentityPool: FLEET_HOST_PROJECT_ID.svc.id.goog
...

    Questo output deve contenere i seguenti campi:

    • scopeTenancyIdentityProvider: il provider di identità per i workload che vengono eseguiti negli spazi dei nomi del parco risorse all'interno degli ambiti del team. Il valore è un identificatore di risorsa per il tuo cluster.
    • scopeTenancyWorkloadIdentityPool: il pool di identità del workload da cui i workload negli spazi dei nomi del parco risorse all'interno degli ambiti del team ricevono gli identificatori. Il valore è il tuo pool di identità del workload autogestito, con il formato POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog.
    • workloadIdentityPool: il nome del pool di identità del workload gestito da Google del progetto host del parco risorse, da cui tutti gli altri workload del parco risorse ottengono le identità per impostazione predefinita.

  2. (Facoltativo) Controlla se il tuo pool di identità del workload ha uno spazio dei nomi con lo stesso nome dello spazio dei nomi del parco risorse:

    gcloud iam workload-identity-pools namespaces list \
    --workload-identity-pool=POOL_NAME \
    --location=global

    L'output è simile al seguente:

    ---
description: Fleet namespace NAMESPACE_NAME
name: projects/FLEET_HOST_PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_NAME/namespaces/NAMESPACE_NAME
state: ACTIVE

Ora il tuo parco risorse può utilizzare il pool di workload identity autogestito per ottenere identità per i carichi di lavoro eseguiti negli spazi dei nomi del parco risorse. Per iniziare a utilizzare il pool autogestito, configura il modo in cui i cluster specifici ottengono le identità, come descritto nella sezione successiva.

Fai in modo che i workload utilizzino pool autogestiti per le identità

Per fare in modo che i carichi di lavoro utilizzino il pool autogestito, configura spazi dei nomi fleet specifici nei cluster membri della fleet utilizzando un ConfigMap Kubernetes. Questa configurazione per cluster e per spazio dei nomi ti consente di ridurre ulteriormente l'ambito delle concessioni di accesso dagli spazi dei nomi dell'intero parco risorse ai carichi di lavoro eseguiti in spazi dei nomi del parco risorse specifici in cluster specifici.

  1. Connettiti al cluster membro del parco risorse:

    gcloud container clusters get-credentials FLEET_CLUSTER_NAME \
    --project=CLUSTER_PROJECT_ID \
    --location=CLUSTER_LOCATION

    Sostituisci quanto segue:

    • FLEET_CLUSTER_NAME: il nome di un cluster membro del parco risorse già associato a un ambito del team.
    • CLUSTER_PROJECT_ID: l'ID progetto del progetto cluster.
    • CLUSTER_LOCATION: la posizione del cluster.

  2. Recupera il nome completo del pool di identità del workload autogestito. Ti servirà in un secondo momento.

    kubectl get membership membership -o json | jq -r ".spec.scope_tenancy_workload_identity_pool"

    L'output è simile al seguente:

    POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog

  3. Ottieni il nome del provider di identità per gli ambiti del team. Ti servirà in un secondo momento.

    kubectl get membership membership -o json | jq -r ".spec.scope_tenancy_identity_provider"

    L'output è simile al seguente:

    https://gkehub.googleapis.com/projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/FLEET_CLUSTER_NAME

  4. In un editor di testo, salva il seguente manifest YAML per un oggetto ConfigMap come self-managed-pool.yaml:

    kind: ConfigMap
apiVersion: v1
metadata:
  namespace: NAMESPACE_NAME
  name: google-application-credentials
data:
  config: |
    {
      "type": "external_account",
      "audience": "identitynamespace:SELF_MANAGED_POOL_FULL_NAME: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"
      }
    }

    Sostituisci quanto segue:

    • NAMESPACE_NAME: il nome dello spazio dei nomi del parco.
    • SELF_MANAGED_POOL_FULL_NAME: il nome completo del pool di identità del workload autogestito dall'output dei passaggi precedenti in questa sezione. Ad esempio, example-pool.global.1234567890.workload.id.goog.
    • IDENTITY_PROVIDER: il nome del provider di identità dall'output dei passaggi precedenti di questa sezione. Ad esempio, https://gkehub.googleapis.com/projects/1234567890/locations/global/memberships/example-cluster.

  5. Esegui il deployment di ConfigMap nel tuo cluster:

    kubectl create -f self-managed-pool.yaml

Il deployment di ConfigMap indica a GKE che i workload in questo spazio dei nomi devono utilizzare il pool di identità dei workload autogestito per ottenere le identità.

Concedi ruoli IAM alle entità

In questa sezione, creerai un ServiceAccount Kubernetes in uno spazio dei nomi del parco e concederai un ruolo IAM al ServiceAccount. I pod che utilizzano questo ServiceAccount possono quindi accedere alle risorse Google Cloud su cui concedi il ruolo.

  1. Crea un service account Kubernetes nello spazio dei nomi del tuo parco progetti:

    kubectl create serviceaccount SERVICEACCOUNT_NAME \
    --namespace=NAMESPACE_NAME

    Sostituisci quanto segue:

    • SERVICEACCOUNT_NAME: il nome del nuovo ServiceAccount.
    • NAMESPACE_NAME: il nome dello spazio dei nomi del parco.

  2. Concedi un ruolo IAM a ServiceAccount. Il seguente comando di esempio concede il ruolo Visualizzatore oggetti Storage (roles/storage.objectViewer) su un bucket al service account:

    gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
    --member=principal://iam.googleapis.com/projects/FLEET_HOST_PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog/subject/ns/NAMESPACE_NAME/sa/SERVICEACCOUNT_NAME \
    --role=roles/storage.objectViewer \
    --condition=None

Il flag member contiene l'identificatore dell'entità per il nuovo ServiceAccount che hai creato. Le richieste che i tuoi workload inviano alle API Google Cloudutilizzano un token di accesso federato. Questo token di accesso federato include l'identificatore dell'entità che invia la richiesta. Se l'entità in un criterio di autorizzazione che concede un ruolo sulla risorsa di destinazione corrisponde all'entità nel token di accesso federato, l'autenticazione e l'autorizzazione possono continuare.

Esegui il deployment di workload che utilizzano il pool autogestito

I manifest Kubernetes che applichi nello spazio dei nomi del parco risorse devono essere configurati per ottenere le identità dal pool autogestito. I carichi di lavoro che implementi e che devono chiamare le API Google Cloud devono includere i seguenti campi:

  • metadata.namespace: il nome dello spazio dei nomi del parco.
  • spec.serviceAccountName: il nome di Kubernetes ServiceAccount nello spazio dei nomi del parco risorse.
  • spec.containers.env: una variabile di ambiente denominata GOOGLE_APPLICATION_CREDENTIALS che indica il percorso del file delle credenziali predefinite dell'applicazione (ADC).
  • spec.containers.volumeMounts: un volume di sola lettura che consente al container di utilizzare il token di autenticazione per ServiceAccount.
  • spec.volumes: un volume proiettato che monta un token ServiceAccount nel pod. Il pubblico del token è il pool di identità per i carichi di lavoro autogestito. Il ConfigMap che contiene la configurazione della federazione delle identità per i carichi di lavoro del parco risorse è un'origine per il volume.

Per un esempio di file manifest configurato correttamente, consulta la sezione Verificare l'autenticazione da un workload.

Verifica l'autenticazione da un workload

Questa sezione fornisce istruzioni facoltative per verificare di aver configurato correttamente il pool di identità per i carichi di lavoro autogestito elencando i contenuti di un bucket Cloud Storage di esempio. Crea un bucket, assegna un ruolo al bucket a un ServiceAccount in uno spazio dei nomi del parco risorse e esegui il deployment di un pod per tentare di accedere al bucket.

  1. Crea un bucket Cloud Storage:

    gcloud storage buckets create gs://FLEET_HOST_PROJECT_ID-workload-id-bucket \
    --location=LOCATION \
    --project=FLEET_HOST_PROJECT_ID

  2. Concedi il ruolo roles/storage.objectViewer sul bucket al service account nello spazio dei nomi del parco risorse:

    gcloud storage buckets add-iam-policy-binding gs://FLEET_HOST_PROJECT_ID-workload-id-bucket \
    --condition=None \
    --role=roles/storage.objectViewer \
    --member=principal://iam.googleapis.com/projects/FLEET_PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog/subject/ns/NAMESPACE_NAME/sa/SERVICEACCOUNT_NAME

    Sostituisci quanto segue:

    • FLEET_HOST_PROJECT_NUMBER: il numero di progetto del tuo progetto host del parco.
    • POOL_NAME: il nome del tuo pool di identità del workload autogestito.
    • NAMESPACE_NAME: il nome dello spazio dei nomi del parco risorse in cui vuoi eseguire il pod.
    • SERVICEACCOUNT_NAME: il nome del ServiceAccount Kubernetes che deve essere utilizzato dal pod.

  3. Salva il seguente manifest come pod-bucket-access.yaml:

    apiVersion: v1
kind: Pod
metadata:
  name: bucket-access-pod
  namespace:  NAMESPACE_NAME
spec:
  serviceAccountName: SERVICEACCOUNT_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: POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog
          expirationSeconds: 172800
      - configMap:
          name: my-cloudsdk-config
          optional: false
          items:
          - key: "config"
            path: "google-application-credentials.json"

    Sostituisci quanto segue:

    • NAMESPACE_NAME: il nome dello spazio dei nomi del parco risorse in cui vuoi eseguire il pod.
    • SERVICEACCOUNT_NAME: il nome del ServiceAccount Kubernetes che deve essere utilizzato dal pod.
    • POOL_NAME: il nome del tuo pool di identità del workload autogestito.
    • FLEET_HOST_PROJECT_NUMBER: il numero di progetto del tuo progetto host del parco.

  4. Esegui il deployment del pod nel cluster:

    kubectl apply -f pod-bucket-access.yaml

  5. Apri una sessione shell nel pod:

    kubectl exec -it bucket-access-pod -n NAMESPACE_NAME -- /bin/bash

  6. 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_HOST_PROJECT_ID-workload-id-bucket/o"

    L'output è il seguente:

    {
  "kind": "storage#objects"
}

Se vuoi, puoi verificare che uno spazio dei nomi e un service account simili in un cluster membro del parco risorse diverso non possano asserire la stessa identità. In un cluster che utilizza la federazione delle identità per i carichi di lavoro del parco risorse, ma non ha uno spazio dei nomi del parco risorse o una configurazione del pool autogestito, segui questi passaggi:

  1. Crea un nuovo spazio dei nomi Kubernetes con lo stesso nome dello spazio dei nomi del parco risorse in cui hai configurato il pool di identità dei workload autogestito.
  2. Crea un nuovo ServiceAccount Kubernetes con lo stesso nome del ServiceAccount a cui hai concesso un ruolo IAM nelle sezioni precedenti.

  3. Esegui il deployment di un pod che utilizza lo stesso ServiceAccount e lo stesso spazio dei nomi, ma per il quale il campo spec.volumes.projected.sources.serviceAccountToken specifica il pool di identità del workload gestito da Google. Questo pool ha la seguente sintassi:

    FLEET_HOST_PROJECT_ID.svc.id.goog

  4. Prova ad accedere al bucket Cloud Storage da una sessione shell nel pod.

L'output deve essere un errore 401: Unauthorized, perché l'identificatore principale per il pod che utilizza il pool di identità del workload gestito da Google è diverso dall'identificatore principale per il pod che utilizza il pool autogestito.

Passaggi successivi