Autenticación en las APIs de Google Cloud desde cargas de trabajo de flotas de confianza mixta

En esta página, se muestra cómo configurar tus aplicaciones para que se autentiquen en las APIs deGoogle Cloud , como la API de Compute Engine o la API de AI Platform, desde flotas que tienen un modelo de confianza mixto en toda la flota. Si tu flota tiene un modelo de confianza compartido en toda la flota, consulta Autenticación en APIs de Google Cloud desde cargas de trabajo de flotas con confianza compartida.

Esta página está destinada a los administradores y operadores de la plataforma, y a los ingenieros de seguridad que desean autenticarse de forma programática desde cargas de trabajo de flotas en las APIs de Google Cloud. Para obtener más información sobre los roles de usuario y las tareas de ejemplo a las que hacemos referencia en la documentación de Google Cloud, consulta Tareas y roles comunes de los usuarios de GKE.

Antes de leer este documento, asegúrate de estar familiarizado con los siguientes conceptos:

Acerca de la federación de identidades para cargas de trabajo de la flota para entornos de confianza mixta

La federación de Workload Identity de la flota te permite otorgar roles de IAM en las APIs y los recursos deGoogle Cloud a entidades de tu flota, como cargas de trabajo en un espacio de nombres específico. De forma predeterminada, tu proyecto host de flota usa un grupo de identidades de carga de trabajo administrado por Google para aprovisionar identidades para las entidades de toda la flota. Sin embargo, en entornos de confianza mixta, como flotas de varios arrendatarios o en proyectos host de la flota que ejecutan clústeres independientes, te recomendamos que configures un grupo de identidades para cargas de trabajo autoadministrado independiente para un subconjunto de tus cargas de trabajo y clústeres.

Las entidades que usan un grupo de identidades para cargas de trabajo autoadministrado tienen identificadores diferentes en las políticas de IAM que las entidades que usan el grupo de identidades para cargas de trabajo administrado por Google del proyecto host de la flota. Esto garantiza que otorgar acceso a principales en un espacio de nombres de flota específico no otorgue acceso de forma involuntaria a ningún otro principal que coincida con el identificador.

Los grupos de identidades para cargas de trabajo autoadministrados requieren que uses alcances de equipo. Los permisos del equipo te permiten controlar el acceso a subconjuntos de recursos de flota por equipo. Vinculas permisos de equipo específicos a clústeres miembros de la flota específicos para permitir que ese equipo implemente cargas de trabajo en esos clústeres. Dentro de un permiso de equipo, los miembros del equipo solo pueden implementar cargas de trabajo en espacios de nombres de la flota.

Usar grupos de identidades para cargas de trabajo autoadministrados para proporcionar identidades para cargas de trabajo con alcance de equipo tiene beneficios como los siguientes:

  • Asegúrate de que los permisos de acceso a las entidades en los espacios de nombres de la flota no se apliquen de forma involuntaria a las entidades en otros espacios de nombres o clústeres.
  • Configura un conjunto de clústeres de la flota para obtener identidades del grupo autoadministrado vinculándolos a un alcance del equipo y configurando el grupo autoadministrado como proveedor de identidad en esos clústeres.
  • Configura un subconjunto de los clústeres vinculados de un alcance del equipo para obtener identidades del grupo autoadministrado. Para ello, configura el grupo autoadministrado solo como proveedor de identidad en clústeres específicos.

Ejemplo de similitud de identidad en un entorno de confianza mixta

Considera la siguiente situación:

  • Tienes dos clústeres miembros de la flota: frontend-cluster y finance-cluster.
  • No configuraste un grupo de identidades para cargas de trabajo autoadministrado.
  • Creas un permiso de equipo finance-team y un espacio de nombres de flota finance-ns en el permiso de equipo.
  • Vinculas el clúster finance-cluster al permiso del equipo finance-team.
  • Otorgas un rol de IAM a la ServiceAccount de Kubernetes finance-sa en el espacio de nombres de la flota finance-ns.

Las cargas de trabajo que cumplen con los siguientes criterios comparten la misma identidad:

  • Se ejecuta en el espacio de nombres de la flota finance-ns.
  • Usa la cuenta de servicio de finance-sa.

Sin embargo, si alguien en el clúster frontend-cluster crea un espacio de nombres de Kubernetes finance-ns y una ServiceAccount finance-sa, obtiene la misma identidad que las cargas de trabajo en el clúster finance-cluster. Esto se debe a que toda la flota usa el grupo de identidades para cargas de trabajo administrado por Google del proyecto host de la flota y a que el identificador principal no especifica un clúster host.

Considera los siguientes cambios en la situación anterior:

  • Configuraste un grupo de identidades para cargas de trabajo autoadministrado en tu flota.
  • Configuras el clúster finance-cluster para obtener identidades del grupo autoadministrado en lugar del grupo administrado por Google.
  • Creas un otorgamiento de rol de IAM que especifica el grupo autoadministrado en el identificador principal en lugar del grupo administrado por Google.

Las cargas de trabajo que se ejecutan en el espacio de nombres de la flota finance-ns en finance-cluster ahora obtienen una identidad del grupo autoadministrado. Sin embargo, las entidades en el espacio de nombres de Kubernetes finance-ns en el clúster frontend-cluster siguen obteniendo identidades del grupo de identidades de cargas de trabajo administrado por Google del proyecto host de la flota.

Estos cambios generan los siguientes beneficios:

  • Puedes otorgar roles de forma explícita a las entidades en el espacio de nombres de la flota finance-ns.
  • Las entidades del clúster frontend-cluster no pueden obtener el mismo acceso porque las identidades del clúster frontend-cluster provienen del grupo de identidades de cargas de trabajo administrado por Google.

Antes de comenzar

  • Asegúrate de tener instaladas las siguientes herramientas de línea de comandos:

    • La versión más reciente de Google Cloud CLI, que incluye gcloud, la herramienta de línea de comandos para interactuar con Google Cloud.
    • kubectl

    Si usas Cloud Shell como entorno de shell para interactuar con Google Cloud, estas herramientas están instaladas.

  • Asegúrate de haber inicializado la CLI de gcloud para usarla en tu proyecto.

Requisitos

Debes usar funciones de administración de equipos de flotas, como permisos de equipo y espacios de nombres de flota, en tu flota. En las instrucciones de esta página, se muestra cómo configurar un permiso de equipo y un espacio de nombres de la flota de ejemplo.

Prepara tus clústeres

Antes de que las aplicaciones de tu flota puedan recibir una identidad federada, los clústeres en los que se ejecutan deben registrarse en tu flota y estar configurados de forma correcta para usar la federación de identidades para cargas de trabajo de flota. En las siguientes secciones, se describe cómo configurar la federación de identidades para cargas de trabajo de la flota para diferentes tipos de clústeres.

GKE

En el caso de los clústeres de GKE, haz lo siguiente:

  1. Habilita Workload Identity Federation for GKE en tu clúster de Google Kubernetes Engine, si aún no está habilitada.
  2. Registra el clúster en la flota.

También puedes habilitar la Workload Identity Federation for GKE durante el proceso de creación del clúster y el registro de la flota.

Clústeres fuera de Google Cloud

Los siguientes tipos de clústeres habilitan automáticamente la federación de identidades para cargas de trabajo de la flota y se registran en tu flota durante la creación del clúster:

  • Google Distributed Cloud (solo software) en VMware
  • Google Distributed Cloud (solo software) en equipos físicos
  • GKE en AWS
  • GKE en Azure

Clústeres adjuntos

Los clústeres adjuntos de EKS y AKS registrados con la API de GKE Multi-cloud se registran con la federación de identidades para cargas de trabajo de la flota habilitada de forma predeterminada. Otros clústeres vinculados se pueden registrar con la federación de identidades para cargas de trabajo de la flota habilitada si cumplen con los requisitos necesarios. Sigue las instrucciones para el tipo de clúster en Registra un clúster.

Configura un grupo de identidades para cargas de trabajo de IAM

En esta sección, crearás un nuevo grupo de identidades para cargas de trabajo de IAM en el proyecto host de la flota y le otorgarás acceso al agente de servicio de la flota al nuevo grupo.

  1. Crea un grupo de identidades para cargas de trabajo:

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

    Reemplaza lo siguiente:

    • POOL_NAME: Es el nombre del nuevo grupo de identidades para cargas de trabajo.
    • POOL_HOST_PROJECT_ID: Es el ID del proyecto en el que deseas crear el grupo de identidades para cargas de trabajo autoadministrado. Puedes usar cualquier proyecto Google Cloud , incluido el proyecto host de tu flota.

  2. Otorga el rol de administrador de grupos de identidades para cargas de trabajo de IAM (roles/iam.workloadIdentityPoolAdmin) en el nuevo grupo de identidades para cargas de trabajo al agente de servicio de la flota:

    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

    Reemplaza FLEET_HOST_PROJECT_NUMBER por el número del proyecto host de la flota.

Agrega el grupo autoadministrado a la configuración de tu flota

En esta sección, habilitarás los grupos autoadministrados con la federación de identidades para cargas de trabajo de la flota y agregarás el grupo que creaste a la configuración de la flota. En esta sección, también se proporcionan instrucciones para crear un nuevo permiso de equipo y un espacio de nombres de flota. Si tu flota ya tiene configurados los permisos de equipo y los espacios de nombres de la flota, omite esos pasos.

  1. Habilita la federación de identidades para cargas de trabajo de la flota a nivel de la flota:

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

    Reemplaza FLEET_HOST_PROJECT_ID por el ID del proyecto host de tu flota.

  2. Agrega el grupo de identidades para cargas de trabajo autoadministrado a la configuración de la flota:

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

    Reemplaza POOL_NAME por el nombre de tu grupo de identidades para cargas de trabajo autoadministrado. Este valor tiene la siguiente sintaxis:

    POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog

  3. Crea un permiso de equipo nuevo. Si ya tienes un alcance del equipo y un espacio de nombres de la flota existentes, ve a la sección Verifica la configuración del grupo de identidades para cargas de trabajo.

    gcloud container fleet scopes create SCOPE_NAME

    Reemplaza SCOPE_NAME por el nombre de tu nuevo alcance del equipo.

  4. Crea un espacio de nombres de flota nuevo en el permiso del equipo:

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

    Reemplaza NAMESPACE_NAME por el nombre de tu nuevo espacio de nombres de la flota.

  5. Vincula un clúster de tu flota al permiso de equipo:

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

    Reemplaza lo siguiente:

    • BINDING_NAME: Es el nombre de la nueva vinculación de membresía.
    • FLEET_CLUSTER_NAME: Es el nombre del clúster de flota existente que se vinculará al permiso del equipo.

Verifica la configuración del grupo de identidades para cargas de trabajo

En esta sección, te asegurarás de que la configuración de tu grupo de identidades para cargas de trabajo autoadministrado se haya realizado correctamente.

  1. Describe la configuración de membresía de la flota:

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

    Reemplaza FLEET_CLUSTER_NAME por el nombre de un clúster de flota existente que esté vinculado a cualquier alcance de equipo de tu flota.

    El resultado es similar a este:

    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
...

    Este resultado debería contener los siguientes campos:

    • scopeTenancyIdentityProvider: Es el proveedor de identidad para las cargas de trabajo que se ejecutan en espacios de nombres de la flota dentro de los permisos del equipo. El valor es un identificador de recurso para tu clúster.
    • scopeTenancyWorkloadIdentityPool: Es el grupo de identidades para cargas de trabajo desde el que las cargas de trabajo en los espacios de nombres de la flota dentro de los alcances del equipo obtienen identificadores. El valor es tu grupo de identidades para cargas de trabajo autoadministrado, con el formato POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog.
    • workloadIdentityPool: Es el nombre del grupo de identidades para cargas de trabajo administrado por Google del proyecto host de la flota, desde el cual todas las demás cargas de trabajo de la flota obtienen identidades de forma predeterminada.

  2. Opcional: Verifica si tu grupo de identidades de cargas de trabajo tiene un espacio de nombres con el mismo nombre que el espacio de nombres de tu flota:

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

    El resultado es similar a este:

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

Tu flota ahora puede usar el grupo de identidades para cargas de trabajo autoadministrado para obtener identidades para las cargas de trabajo que se ejecutan en los espacios de nombres de la flota. Para comenzar a usar el grupo autoadministrado, configura cómo los clústeres específicos obtienen identidades, como se describe en la siguiente sección.

Haz que las cargas de trabajo usen grupos autoadministrados para las identidades

Para que las cargas de trabajo usen el grupo autoadministrado, debes configurar espacios de nombres específicos de la flota en los clústeres miembros de la flota con un ConfigMap de Kubernetes. Esta configuración por clúster y por espacio de nombres te permite reducir aún más el alcance de las concesiones de acceso de espacios de nombres de toda la flota a cargas de trabajo que se ejecutan en espacios de nombres de la flota específicos en clústeres específicos.

  1. Conéctate al clúster miembro de tu flota:

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

    Reemplaza lo siguiente:

    • FLEET_CLUSTER_NAME: Es el nombre de un clúster miembro de la flota que ya está vinculado a un permiso del equipo.
    • CLUSTER_PROJECT_ID: Es el ID del proyecto del clúster.
    • CLUSTER_LOCATION: Es la ubicación del clúster.

  2. Obtén el nombre completo del grupo de identidades para cargas de trabajo autoadministrado. La necesitarás más adelante.

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

    El resultado es similar a este:

    POOL_NAME.global.FLEET_HOST_PROJECT_NUMBER.workload.id.goog

  3. Obtén el nombre del proveedor de identidad para los permisos del equipo. La necesitarás más tarde.

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

    El resultado es similar a este:

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

  4. En un editor de texto, guarda el siguiente manifiesto YAML para un ConfigMap como 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"
      }
    }

    Reemplaza lo siguiente:

    • NAMESPACE_NAME: Es el nombre del espacio de nombres de la flota.
    • SELF_MANAGED_POOL_FULL_NAME: Es el nombre completo del grupo de identidades para cargas de trabajo autoadministrado que se obtuvo en los pasos anteriores de esta sección. Por ejemplo, example-pool.global.1234567890.workload.id.goog
    • IDENTITY_PROVIDER: Es el nombre del proveedor de identidad que se obtuvo en los pasos anteriores de esta sección. Por ejemplo: https://gkehub.googleapis.com/projects/1234567890/locations/global/memberships/example-cluster..

  5. Implementa el ConfigMap en tu clúster:

    kubectl create -f self-managed-pool.yaml

Implementar el ConfigMap le indica a GKE que las cargas de trabajo en ese espacio de nombres deben usar el grupo de identidades para cargas de trabajo autoadministrado para obtener identidades.

Otorga roles de IAM a las principales

En esta sección, crearás una ServiceAccount de Kubernetes en un espacio de nombres de la flota y le otorgarás un rol de IAM. Los Pods que usan esta ServiceAccount pueden acceder a los recursos Google Cloud en los que otorgas el rol.

  1. Crea una ServiceAccount de Kubernetes en el espacio de nombres de tu flota:

    kubectl create serviceaccount SERVICEACCOUNT_NAME \
    --namespace=NAMESPACE_NAME

    Reemplaza lo siguiente:

    • SERVICEACCOUNT_NAME: Es el nombre de tu ServiceAccount nueva.
    • NAMESPACE_NAME: Es el nombre del espacio de nombres de la flota.

  2. Otorga un rol de IAM a la ServiceAccount. En el siguiente ejemplo, se otorga el rol de visualizador de objetos de almacenamiento (roles/storage.objectViewer) en un bucket a la cuenta de servicio:

    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

La marca member contiene el identificador principal del nuevo ServiceAccount que creaste. Las solicitudes que tus cargas de trabajo envían a las APIs de Google Cloudusan un token de acceso federado. Este token de acceso federado incluye el identificador principal de la entidad que envía la solicitud. Si la principal de una política de permisos que otorga un rol en el recurso de destino coincide con la principal del token de acceso federado, la autenticación y la autorización pueden continuar.

Implementa cargas de trabajo que usen el grupo autoadministrado

Los manifiestos de Kubernetes que apliques en el espacio de nombres de tu flota deben configurarse para obtener identidades del grupo autoadministrado. Las cargas de trabajo que implementes y que necesiten llamar a las APIs de Google Cloud deben incluir los siguientes campos:

  • metadata.namespace: Es el nombre del espacio de nombres de la flota.
  • spec.serviceAccountName: Es el nombre de la ServiceAccount de Kubernetes en el espacio de nombres de la flota.
  • spec.containers.env: Es una variable de entorno llamada GOOGLE_APPLICATION_CREDENTIALS que indica la ruta de acceso al archivo de credenciales predeterminadas de la aplicación (ADC).
  • spec.containers.volumeMounts: Es un volumen de solo lectura que permite que el contenedor use el token de portador para ServiceAccount.
  • spec.volumes: Es un volumen proyectado que activa un token de ServiceAccount en el Pod. El público del token es el grupo de identidades para cargas de trabajo autoadministrado. El ConfigMap que contiene la configuración de la federación de identidades para cargas de trabajo de la flota es una fuente para el volumen.

Para ver un ejemplo de un archivo de manifiesto configurado correctamente, consulta la sección Verifica la autenticación desde una carga de trabajo.

Verifica la autenticación desde una carga de trabajo

En esta sección, se proporcionan instrucciones opcionales para verificar que configuraste correctamente el grupo de identidades para cargas de trabajo autoadministrado. Para ello, se enumeran los contenidos de un bucket de Cloud Storage de ejemplo. Crearás un bucket, otorgarás un rol en el bucket a una ServiceAccount en un espacio de nombres de flota y, luego, implementarás un Pod para intentar acceder al bucket.

  1. Crea un bucket de Cloud Storage:

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

  2. Otorga el rol roles/storage.objectViewer en el bucket a la ServiceAccount en el espacio de nombres de la flota:

    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

    Reemplaza lo siguiente:

    • FLEET_HOST_PROJECT_NUMBER: Es el número del proyecto host de tu flota.
    • POOL_NAME: Es el nombre de tu grupo de identidades para cargas de trabajo autoadministrado.
    • NAMESPACE_NAME: Es el nombre del espacio de nombres de la flota en el que deseas ejecutar el Pod.
    • SERVICEACCOUNT_NAME: Es el nombre de la ServiceAccount de Kubernetes que debe usar el Pod.

  3. Guarda el siguiente manifiesto como 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"

    Reemplaza lo siguiente:

    • NAMESPACE_NAME: Es el nombre del espacio de nombres de la flota en el que deseas ejecutar el Pod.
    • SERVICEACCOUNT_NAME: Es el nombre de la ServiceAccount de Kubernetes que debe usar el Pod.
    • POOL_NAME: Es el nombre de tu grupo de identidades para cargas de trabajo autoadministrado.
    • FLEET_HOST_PROJECT_NUMBER: Es el número del proyecto host de tu flota.

  4. Implementa el Pod en tu clúster:

    kubectl apply -f pod-bucket-access.yaml

  5. Abre una sesión de shell en el Pod:

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

  6. Intenta enumerar los objetos del 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"

    Esta es la salida:

    {
  "kind": "storage#objects"
}

De manera opcional, puedes verificar que un espacio de nombres y una ServiceAccount similares en un clúster miembro de una flota diferente no podrán confirmar la misma identidad. En un clúster que usa la federación de Workload Identity de la flota, pero no tiene un espacio de nombres de la flota ni una configuración de grupo autoadministrado, sigue estos pasos:

  1. Crea un nuevo espacio de nombres de Kubernetes con el mismo nombre que el espacio de nombres de la flota en el que configuraste el grupo de identidades para cargas de trabajo autoadministrado.
  2. Crea una ServiceAccount de Kubernetes nueva con el mismo nombre que la ServiceAccount a la que le otorgaste un rol de IAM en secciones anteriores.

  3. Implementa un Pod que use el mismo ServiceAccount y espacio de nombres, pero para el que el campo spec.volumes.projected.sources.serviceAccountToken especifique el grupo de identidades de cargas de trabajo administrado por Google. Este grupo tiene la siguiente sintaxis:

    FLEET_HOST_PROJECT_ID.svc.id.goog

  4. Intenta acceder al bucket de Cloud Storage desde una sesión de shell en el Pod.

El resultado debería ser un error de 401: Unauthorized, ya que el identificador principal del Pod que usa el grupo de identidades para cargas de trabajo administrado por Google es diferente del identificador principal del Pod que usa el grupo autoadministrado.

¿Qué sigue?