Usa Workload Identity

En esta página, se explica la forma en que se recomienda que las aplicaciones de Google Kubernetes Engine (GKE) consuman los servicios proporcionados por las API de Google.

Descripción general

Workload Identity es la forma recomendada de acceder a los servicios de Google Cloud desde aplicaciones que se ejecutan dentro de GKE debido a sus propiedades de seguridad y capacidad de administración mejoradas. Si deseas obtener información sobre formas alternativas para acceder a las API de Google Cloud desde GKE, consulta la sección alternativas a continuación.

Terminología

En este documento, se distingue entre cuentas de servicio de Kubernetes y cuentas de servicio de Google. Las cuentas de servicio de Kubernetes son recursos de Kubernetes, mientras que las cuentas de servicio de Google son específicas de Google Cloud. En otros documentos de Google Cloud, se hace referencia a las cuentas de servicio de Google como “cuentas de servicio”.

Conceptos

Las aplicaciones que se ejecutan en GKE deben autenticarse para usar las API de Google Cloud, como las API de Compute, las API de Storage y Database o las API de aprendizaje automático.

Con Workload Identity, puedes configurar una cuenta de servicio de Kubernetes para que actúe como una cuenta de servicio de Google. Los Pods que se ejecutan como la cuenta de servicio de Kubernetes se autenticarán de forma automática como la cuenta de servicio de Google cuando se acceda a las API de Google Cloud. Esto te permite asignar identidades y autorizaciones distintas y detalladas para cada aplicación de tu clúster.

Para realizar una mapeo seguro entre las cuentas de servicio de Kubernetes y las cuentas de servicio de Google, Workload Identity presenta el concepto del grupo de identidades de la carga de trabajo de un clúster, que permite que la administración de identidades y accesos (IAM) confíe y comprenda las credenciales de la cuenta de servicio de Kubernetes.

Cuando habilites Workload Identity en tu clúster de GKE, el grupo de Workload Identity del clúster se configurará como PROJECT_ID.svc.id.goog. Esto permite que IAM autentique las cuentas de servicio de Kubernetes como el siguiente nombre de miembro:

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

En este nombre de miembro, se da lo siguiente:

  • PROJECT_ID.svc.id.goog es el grupo de identidades de carga de trabajo configurado en el clúster.
  • KSA_NAME es el nombre de la cuenta de servicio de Kubernetes que realiza la solicitud.
  • K8S_NAMESPACE es el espacio de nombres de Kubernetes en el que se define la cuenta de servicio de Kubernetes.

Solo hay un grupo de identidades de carga de trabajo fijo por proyecto de Google Cloud, PROJECT_ID.svc.id.goog, y se crea automáticamente para ti.

Similitud de identidad en los clústeres

Todas las cuentas de servicio de Kubernetes que comparten un nombre, un nombre de espacio de nombres y un grupo de identidad de carga de trabajo se resuelven con el mismo nombre de miembro y, por lo tanto, comparten el acceso a los recursos de Google Cloud. Esta identidad común permite otorgar a las aplicaciones dentro de un grupo de identidades de carga de trabajo acceso a un recurso externo una vez y no por clúster.

Para ilustrar este punto con más detalle, considera el siguiente ejemplo. Los clústeres A, B y C están inscritos en el mismo grupo de identidades de las cargas de trabajo. Cuando las aplicaciones en el espacio de nombres backend acceden a los recursos de Google Cloud, sus identidades se asignan a una cuenta de servicio común de Google llamada back, sin importar el clúster que aloje la aplicación. Se puede autorizar la cuenta de servicio de Google back en cualquier cantidad de API de Google Cloud, desde Cloud Storage hasta Cloud SQL.

Debido a la similitud de identidad, es importante que todos los clústeres de un grupo de identidades de cargas de trabajo sean confiables y estén bien protegidos. En el ejemplo anterior, si el clúster C es propiedad de un equipo independiente que no es de confianza, también pueden crear un espacio de nombres de backend y acceder a las API de Google Cloud como si fueran el backend en el clúster A. o B.

Diagrama que ilustra la similitud de identidad en un grupo de identidades de carga de trabajo
Similitud de identidad con acceso a las API de Google Cloud con Workload Identity

Para evitar que los clústeres compartan permisos, deben estar en proyectos diferentes o deben usar nombres de espacio de nombres de Kubernetes distintos. Como ejemplo específico, los usuarios con clústeres “dev” permisivos y “prod” bloqueados deberían considerar separarlos en proyectos distintos para obtener grupos de identidades de carga de trabajo diferentes.

Limitaciones

  • Actualmente, solo hay un grupo de Workload Identity fijo por proyecto de Google Cloud, PROJECT_ID.svc.id.goog, y se crea de forma automática para ti.

  • Por el momento, Workload Identity no es compatible cuando una carga de trabajo se ejecuta en clústeres de Anthos alojados en VMware.

  • Workload Identity reemplaza la necesidad de usar ocultamiento de metadatos y, por lo tanto, los dos enfoques son incompatibles. Workload Identity también protege los metadatos sensibles protegidos con la ocultación de metadatos.

  • Cuando el servidor de metadatos de GKE se habilita en un grupo de nodos, los Pods ya no podrán acceder al servidor de metadatos de Compute Engine. En su lugar, la solicitud realizada desde estos Pods a las API de metadatos se enrutará al servidor de metadatos de GKE. La única excepción son los Pods que se ejecutan en la red del host (consulta el siguiente elemento).

  • No se puede usar Workload Identity en los Pods que se ejecutan en la red del host. Las solicitudes realizadas desde estos Pods a las API de metadatos se enrutarán al servidor de metadatos de Compute Engine.

  • El servidor de metadatos de GKE necesita unos segundos antes de comenzar a aceptar solicitudes en un Pod recién creado. Por lo tanto, los intentos de autenticación mediante Workload Identity en los primeros segundos de la vida del Pod podrían fallar. Volver a intentar la llamada resolverá el problema. Si quieres obtener más información, revisa la sección de solución de problemas que se encuentra más abajo.

  • Los agentes integrados de supervisión y registro de GKE seguirán usando la cuenta de servicio del nodo.

  • Workload Identity requiere una configuración manual para Cloud Run for Anthos en Google Cloud a fin de continuar lanzando métricas de solicitudes.

  • Workload Identity instala ip-masq-agent si el clúster se crea sin la marca --disable-default-snat.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

Establece la configuración de gcloud predeterminada mediante uno de los siguientes métodos:

  • Usa gcloud init si deseas ver una explicación sobre cómo configurar parámetros predeterminados.
  • Usa gcloud config para establecer el ID, la zona y la región del proyecto de manera individual.

Usa gcloud init

Si recibes el error One of [--zone, --region] must be supplied: Please specify location, completa esta sección.

  1. Ejecuta gcloud init y sigue las instrucciones:

    gcloud init

    Si usas SSH en un servidor remoto, usa la marca --console-only para evitar que el comando abra un navegador:

    gcloud init --console-only
  2. Sigue las instrucciones a fin de autorizar a gcloud para que use tu cuenta de Google Cloud.
  3. Crea una configuración nueva o selecciona una existente.
  4. Elige un proyecto de Google Cloud.
  5. Elige una zona predeterminada de Compute Engine para clústeres zonales o una región para clústeres regionales o de Autopilot.

Usa gcloud config

  • Establece tu ID del proyecto predeterminado:
    gcloud config set project PROJECT_ID
  • Si trabajas con clústeres zonales, establece tu zona de procesamiento predeterminada: 
    gcloud config set compute/zone COMPUTE_ZONE
  • Si trabajas con clústeres de Autopilot o regionales, configura tu región de procesamiento predeterminada: 
    gcloud config set compute/region COMPUTE_REGION
  • Actualiza gcloud a la versión más reciente:
    gcloud components update

Habilita Workload Identity en un clúster

Puedes habilitar Workload Identity en un clúster estándar de GKE nuevo o existente con la herramienta de gcloud. De forma predeterminada, Workload Identity está habilitada en clústeres de Autopilot de GKE.

  1. Asegúrate de que habilitaste la API de credenciales de la cuenta de servicio de IAM.

    Habilitar la API de credenciales IAM

  2. Para crear un clúster nuevo con Workload Identity habilitado, usa el siguiente comando:

    gcloud container clusters create CLUSTER_NAME \
  --workload-pool=PROJECT_ID.svc.id.goog

    Reemplaza los siguientes elementos:

    • CLUSTER_NAME: Es el nombre de tu clúster.
    • PROJECT_ID: El ID del proyecto de Google Cloud.

    Esta acción requiere el permiso container.clusters.create en el proyecto.

  3. Para habilitar Workload Identity en un clúster existente, modifica el clúster con el siguiente comando:

    gcloud container clusters update CLUSTER_NAME \
  --workload-pool=PROJECT_ID.svc.id.goog

    Los grupos de nodos existentes no se ven afectados; los grupos de nodos nuevos se establecen de forma predeterminada como --workload-metadata=GKE_METADATA.

    Esta acción requiere permisos container.clusters.update en el clúster.

Migra aplicaciones a Workload Identity

Selecciona la estrategia de migración ideal para tu entorno. Los grupos de nodos se pueden migrar en el lugar o puedes crear grupos de nodos nuevos con Workload Identity habilitada. Te recomendamos crear grupos de nodos nuevos si también necesitas modificar la aplicación para que sea compatible con esta característica.

Agrega un grupo de nodos nuevo al clúster con Workload Identity habilitado y migra cargas de trabajo a ese grupo de forma manual. Esto tiene éxito solo si Workload Identity está habilitada en el clúster.

gcloud container node-pools create NODEPOOL_NAME \
  --cluster=CLUSTER_NAME \
  --workload-metadata=GKE_METADATA

Si un clúster tiene Workload Identity habilitada, puedes inhabilitarla de forma selectiva en un grupo de nodos en particular si especificas --workload-metadata=GCE_METADATA explícitamente. Para obtener más información, consulta Protege metadatos del clúster.

Opción 2: modificación del grupo de nodos

Modifica un grupo de nodos existente para habilitar GKE_METADATA. Esta actualización tiene éxito solo si Workload Identity está habilitada en el clúster. Habilita de inmediato Workload Identity para las cargas de trabajo implementadas en el grupo de nodos. Este cambio evitará que las cargas de trabajo usen la cuenta de servicio de Compute Engine y se debe implementar con mucho cuidado.

gcloud container node-pools update NODEPOOL_NAME \
  --cluster=CLUSTER_NAME \
  --workload-metadata=GKE_METADATA

Esta acción requiere permisos container.nodes.update en el proyecto.

Autentica en Google Cloud

En esta sección, se explica cómo una aplicación puede autenticarse en Google Cloud mediante Workload Identity. A fin de hacer esto, asigna una cuenta de servicio de Kubernetes a la aplicación y configúrala para que actúe como una cuenta de servicio de Google:

  1. Configura kubectl para comunicarse con el clúster:

    gcloud container clusters get-credentials CLUSTER_NAME

    Reemplaza CLUSTER_NAME por el nombre del clúster que creaste en el paso anterior.

    Esta acción requiere el permiso container.clusters.get en el proyecto.

  2. Como la mayoría de los otros recursos, las cuentas de servicio de Kubernetes se alojan en un espacio de nombres. Crea el espacio de nombres para usar en la cuenta de servicio de Kubernetes.

    kubectl create namespace K8S_NAMESPACE

    Esta acción requiere crear el permiso RBAC de espacio de nombres dentro del clúster.

  3. Crea la cuenta de servicio de Kubernetes para usar en la aplicación:

    kubectl create serviceaccount --namespace K8S_NAMESPACE KSA_NAME

    Reemplaza los siguientes elementos:

    • K8S_NAMESPACE: El nombre del espacio de nombres de Kubernetes que creaste en el paso anterior.
    • KSA_NAME: El nombre que deseas usar para la cuenta de servicio de Kubernetes.

    Para esta acción, se requiere crear el permiso RBAC de cuentas de servicio dentro del espacio de nombres.

    Como alternativa, puedes usar el espacio de nombres predeterminado o la cuenta de servicio predeterminada de Kubernetes en cualquier espacio de nombres.

  4. Crea una cuenta de servicio de Google para tu aplicación o usa una cuenta de servicio de Google existente. Puedes usar cualquier cuenta de servicio de Google en cualquier proyecto de tu organización. En Config Connector, aplica el objeto IAMServiceAccount para la cuenta de servicio elegida.

    gcloud

    Para crear una nueva cuenta de servicio de Google con la herramienta de gcloud, ejecuta el siguiente comando.

    gcloud iam service-accounts create GSA_NAME

    Reemplaza GSA_NAME con el nombre de la nueva cuenta de servicio de Google.

    Config Connector

    Para usar una cuenta de servicio de Google nueva o existente con Config Connector, aplica el siguiente archivo de configuración.

    Nota: En este paso, se necesita Config Connector. Sigue las instrucciones de instalación para instalar Config Connector en el clúster.

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMServiceAccount
metadata:
  name: [GSA_NAME]
spec:
  displayName: [GSA_NAME]
    Para implementar este manifiesto, descárgalo en tu equipo como service-account.yaml.

    Usa kubectl para aplicar el manifiesto:

    kubectl apply -f service-account.yaml

    Esta acción requiere el permiso iam.serviceAccounts.create en el proyecto.

    Para obtener información sobre la autorización de cuentas de servicio de Google a fin de acceder a las API de Google Cloud, consulta la página Comprende las cuentas de servicio.

  5. Para permitir que la cuenta de servicio de Kubernetes actúe en nombre de la cuenta de servicio de Google, crea una vinculación de política de IAM entre las dos. Esta vinculación permite que la cuenta de servicio de Kubernetes actúe como la cuenta de servicio de Google.

    gcloud

    gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME]" \
  GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

    Config Connector

    Nota: En este paso, se necesita Config Connector. Sigue las instrucciones de instalación para instalar Config Connector en el clúster.

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicy
metadata:
  name: iampolicy-workload-identity-sample
spec:
  resourceRef:
    apiVersion: iam.cnrm.cloud.google.com/v1beta1
    kind: IAMServiceAccount
    name: [GSA_NAME]
  bindings:
    - role: roles/iam.workloadIdentityUser
      members:
        - serviceAccount:[PROJECT_ID].svc.id.goog[[K8S_NAMESPACE]/[KSA_NAME]]
    Para implementar este manifiesto, descárgalo en tu equipo como policy-binding.yaml. Reemplaza GSA_NAME, PROJECT_ID, K8S_NAMESPACE y KSA_NAME por los valores para tu entorno. Luego, ejecuta lo siguiente:

    kubectl apply -f policy-binding.yaml

    Esta acción requiere el permiso iam.serviceAccounts.setIamPolicy en el proyecto.

  6. Agrega la anotación iam.gke.io/gcp-service-account=GSA_NAME@PROJECT_ID a la cuenta de servicio de Kubernetes mediante la dirección de correo electrónico de la cuenta de servicio de Google.

    kubectl

    kubectl annotate serviceaccount \
  --namespace K8S_NAMESPACE \
  KSA_NAME \
  iam.gke.io/gcp-service-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

    yaml

    apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    iam.gke.io/gcp-service-account: GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
  name: KSA_NAME
  namespace: K8S_NAMESPACE

    Para esta acción, se necesitan permisos RBAC de edición en la cuenta de servicio de Kubernetes.

  7. Para verificar que las cuentas de servicio estén configuradas de forma correcta, crea un Pod con la cuenta de servicio de Kubernetes que ejecute la imagen de contenedor específica del SO y, a continuación, conéctate a ella con una sesión interactiva.

    Para los nodos de Linux

    1. Crea un Pod con la cuenta de servicio de Kubernetes que ejecuta la imagen de contenedor cloud-sdk:

      kubectl

      kubectl run -it \
  --image google/cloud-sdk:slim \
  --serviceaccount KSA_NAME \
  --namespace K8S_NAMESPACE \
  workload-identity-test

      yaml

      apiVersion: v1
kind: Pod
metadata:
  name: workload-identity-test
  namespace: K8S_NAMESPACE
spec:
  containers:
  - image: google/cloud-sdk:slim
    name: workload-identity-test
    command: ["sleep","infinity"]
  serviceAccountName: KSA_NAME

      La imagen google/cloud-sdk incluye la herramienta de línea de comandos de gcloud, que es una manera conveniente de usar las API de Google Cloud. La descarga de la imagen puede tomar un tiempo.

      Esta acción requiere crear permisos RBAC de Pods dentro del espacio de nombres.

    2. Ahora estás conectado a un shell interactivo dentro del Pod creado. Ejecuta el siguiente comando dentro del Pod:

      gcloud auth list

      Si las cuentas de servicio están configuradas de forma correcta, la dirección de correo electrónico de la cuenta de servicio de Google aparece como la identidad activa (y única). Esto demuestra que, de forma predeterminada, el Pod usa la autoridad de la cuenta de servicio de Google cuando llama a las API de Google Cloud.

    Para los nodos de Windows Server

    1. Crea un Pod con la cuenta de servicio de Kubernetes que ejecuta la imagen de contenedor servercore:

      kubectl run -it \
  --image IMAGE_NAME \
  --serviceaccount KSA_NAME \
  --namespace K8S_NAMESPACE \
  --overrides='{"spec":{"nodeSelector":{"kubernetes.io/os":"windows"}}}' \
  workload-identity-test

      Reemplaza IMAGE_NAME por uno de los siguientes valores:

      • Para los nodos WINDOWS_LTSC, usa mcr.microsoft.com/windows/servercore:ltsc2019.
      • Para los nodos WINDOWS_SAC, usa mcr.microsoft.com/windows/servercore:1909.

      Esta acción requiere crear permisos RBAC de Pods dentro del espacio de nombres.

    2. Ahora estás conectado a un shell interactivo dentro del Pod creado. Ejecuta el siguiente comando dentro del Pod:

      Invoke-WebRequest  -Headers @{"Metadata-Flavor"="Google"} -Uri  http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/email  -UseBasicParsing

      Si las cuentas de servicio están configuradas de forma correcta, la dirección de correo electrónico de la cuenta de servicio de Google aparece como la identidad activa (y única). Esto demuestra que, de forma predeterminada, el Pod usa la autoridad de la cuenta de servicio de Google cuando llama a las API de Google Cloud.

Usa Workload Identity desde el código

La autenticación en los servicios de Google Cloud desde tu código es el mismo proceso que la autenticación mediante el servidor de metadatos de Compute Engine. Cuando usas Workload Identity, las solicitudes al servidor de metadatos de la instancia se enrutan al servidor de metadatos de GKE. El código existente que se autentica mediante el servidor de metadatos de la instancia (como el código que usa las bibliotecas cliente de Google Cloud) debería funcionar sin modificaciones.

Comprende el servidor de metadatos de GKE

El servidor de metadatos de GKE es un servidor de metadatos nuevo diseñado para usarse con Kubernetes. Se ejecuta como un daemonset, con un Pod en cada nodo del clúster. El servidor de metadatos intercepta las solicitudes HTTP a http://metadata.google.internal (169.254.169.254:80), incluidas las solicitudes como GET /computeMetadata/v1/instance/service-accounts/default/token con el fin de recuperar un token para la cuenta de servicio de Google que el Pod está configurado para suplantar. El tráfico del servidor de metadatos nunca sale de la instancia de VM que aloja al Pod.

El servidor de metadatos de GKE solo implementa un subconjunto de extremos del servidor de metadatos de Compute Engine que son relevantes y seguros para las cargas de trabajo de Kubernetes:

  • /computeMetadata/v1/instance/attributes/cluster-location
  • /computeMetadata/v1/instance/attributes/cluster-name
  • /computeMetadata/v1/instance/attributes/cluster-uid
  • /computeMetadata/v1/instance/hostname
  • /computeMetadata/v1/instance/id
  • /computeMetadata/v1/project/numeric-project-id
  • /computeMetadata/v1/project/project-id
  • /computeMetadata/v1/instance/service-accounts
  • /computeMetadata/v1/instance/service-accounts/default
  • /computeMetadata/v1/instance/service-accounts/default/aliases
  • /computeMetadata/v1/instance/service-accounts/default/email
  • /computeMetadata/v1/instance/service-accounts/default/identity
  • /computeMetadata/v1/instance/service-accounts/default/identity?audience=audience
  • /computeMetadata/v1/instance/service-accounts/default/scopes
  • /computeMetadata/v1/instance/service-accounts/default/token
  • /computeMetadata/v1/instance/service-accounts/default/token?scopes=comma-separated-list-of-scopes

Revoca el acceso

  1. Revoca el acceso a la cuenta de servicio de Google mediante IAM:

    gcloud

    gcloud iam service-accounts remove-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME]" \
  GSA_NAME@GSA_PROJECT_ID.iam.gserviceaccount.com

    Reemplaza los siguientes elementos:

    • PROJECT_ID: El contenedor del ID del proyecto del clúster de GKE.
    • K8S_NAMESPACE: El nombre del espacio de nombres de Kubernetes en el que se encuentra la cuenta de servicio de Kubernetes.
    • KSA_NAME: El nombre de la cuenta de servicio de Kubernetes a la que se le revocará el acceso.
    • GSA_NAME: El nombre de la cuenta de servicio de Google.
    • GSA_PROJECT_ID: El ID del proyecto que contiene la cuenta de servicio de Google.

    Config Connector

    Si usaste Config Connector para crear la cuenta de servicio, borra la cuenta de servicio con kubectl.

    kubectl delete -f service-account.yaml

    Esta acción requiere permisos iam.serviceAccounts.setIamPolicy en la cuenta de servicio.

    Los tokens almacenados en caché pueden tardar hasta 30 minutos en caducar. Puedes verificar si los tokens almacenados en caché caducaron con el siguiente comando:

    gcloud auth list

    Los tokens almacenados en caché caducaron si la salida de ese comando ya no incluye GSA_NAME@PROJECT_ID.iam.gserviceaccount.com.

  2. Quita la anotación de la cuenta de servicio de Kubernetes. Este paso es opcional porque IAM revocó el acceso.

    kubectl annotate serviceaccount KSA_NAME \
  --namespace K8S_NAMESPACE \
  iam.gke.io/gcp-service-account-

Soluciona problemas

El Pod no se puede autenticar en Google Cloud

Si la aplicación no puede autenticarse en Google Cloud, asegúrate de que estas opciones estén configuradas de forma correcta:

  1. Asegúrate de tener habilitada la API de credenciales de la cuenta de servicio de IAM en el proyecto que contiene el clúster de GKE.

    Habilitar la API de credenciales IAM

  2. Asegúrate de que Workload Identity esté habilitado en el clúster mediante la verificación de que tiene un grupo de identidades de cargas de trabajo configurado:

    gcloud container clusters describe CLUSTER_NAME \
  --format="value(workloadIdentityConfig.workloadPool)"

  3. Asegúrate de que el servidor de metadatos de GKE (GKE_METADATA) esté configurado en el grupo de nodos en el que se ejecuta la aplicación:

    gcloud container node-pools describe NODEPOOL_NAME \
  --cluster=CLUSTER_NAME \
  --format="value(config.workloadMetadataConfig.mode)"

  4. Asegúrate de que la cuenta de servicio de Kubernetes esté anotada de forma correcta

    kubectl describe serviceaccount \
  --namespace K8S_NAMESPACE \
  KSA_NAME

    Debería haber una anotación en el siguiente formato:

    iam.gke.io/gcp-service-account: GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

  5. Asegúrate de que la cuenta de servicio de Google esté configurada de forma correcta

    gcloud iam service-accounts get-iam-policy \
  GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

    Verifica que haya una vinculación con el siguiente formato:

    - members:
  - serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME]
  role: roles/iam.workloadIdentityUser

  6. Si tienes una política de red del clúster, asegúrate de que se permita la salida a 127.0.0.1/32 en el puerto 988:

    kubectl describe networkpolicy NETWORK_POLICY_NAME

Errores de tiempo de espera en el inicio del Pod

El servidor de metadatos de GKE necesita unos segundos antes de comenzar a aceptar solicitudes en un Pod recién creado. Por lo tanto, los intentos de autenticarse con Workload Identity en los primeros segundos de la vida del Pod pueden fallar para aplicaciones y bibliotecas cliente de Google Cloud configuradas con un tiempo de espera breve.

Si encuentras errores de tiempo de espera, puedes cambiar el código de la aplicación para esperar unos segundos y volver a intentarlo. Como alternativa, puedes implementar un initContainer que espere hasta que el servidor de metadatos de GKE esté listo antes de ejecutar el contenedor principal del Pod.

A continuación, se muestra un Pod con un initContainer de ejemplo:

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-initcontainer
spec:
  serviceAccountName: ksa-name
  initContainers:
  - image:  gcr.io/google.com/cloudsdktool/cloud-sdk:326.0.0-alpine
    name: workload-identity-initcontainer
    command:
    - '/bin/bash'
    - '-c'
    - |
      curl -s -H 'Metadata-Flavor: Google' 'http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token' --retry 30 --retry-connrefused --retry-max-time 30 > /dev/null || exit 1
  containers:
  - image: gcr.io/your-project/your-image
    name: your-main-application-container

Workload Identity falla

Si el servidor de metadatos de GKE se bloquea por algún motivo, Workload Identity fallará.

Si usas Istio, debes agregar la siguiente anotación a nivel de la aplicación a todas las cargas de trabajo que usan Workload Identity:

"traffic.sidecar.istio.io/excludeOutboundIPRanges=169.254.169.254/32"

Como alternativa, puedes cambiar la clave global.proxy.excludeIPRanges de ConfigMap de Istio para hacer lo mismo.

Inhabilita Workload Identity en un clúster

Solo puedes inhabilitar Workload Identity en los clústeres estándar de GKE.

  1. Inhabilita Workload Identity en cada grupo de nodos:

    gcloud container node-pools update NODEPOOL_NAME \
  --cluster=CLUSTER_NAME \
  --workload-metadata=GCE_METADATA

    Repite este comando para cada grupo de nodos del clúster.

  2. Inhabilita Workload Identity en el clúster:

    gcloud container clusters update CLUSTER_NAME \
  --disable-workload-identity

    Esta acción requiere permisos container.clusters.update en el clúster.

Inhabilita Workload Identity en la organización

Desde la perspectiva de seguridad, Workload Identity permite que GKE confirme las identidades de las cuentas de servicio de Kubernetes que se pueden autenticar y autorizar en los recursos de Google Cloud. Los administradores que realizaron acciones con el fin de aislar las cargas de trabajo de los recursos de Google Cloud, como inhabilitar la creación de cuentas de servicio o inhabilitar la creación de claves de cuentas de servicio, también podrían querer inhabilitar Workload Identity en la organización.

Consulta estas instrucciones para inhabilitar Workload Identity en la organización.

Alternativas a Workload Identity

Hay dos métodos alternativos para acceder a las API de Cloud desde GKE. Con el lanzamiento de Workload Identity, ya no recomendamos estos enfoques debido a los compromisos que requieren.

  1. Exporta claves de cuenta de servicio y almacénalas como secretos de Kubernetes. Las claves de las cuentas de servicio de Google vencen después de 10 años y se rotan manualmente. Exportar claves de cuentas de servicio tiene el potencial de expandir el alcance de un incumplimiento de las normas de seguridad si no se detecta.

  2. Usa la cuenta de servicio de Compute Engine de tus nodos. Puedes ejecutar grupos de nodos como cualquier cuenta de servicio de IAM en tu proyecto. Si no especificas una cuenta de servicio durante la creación del grupo de nodos, GKE usará la cuenta de servicio predeterminada de Compute Engine del proyecto. Todas las cargas de trabajo implementadas en ese nodo comparten la cuenta de servicio de Compute Engine. Esto puede generar un exceso de aprovisionamiento de permisos.

¿Qué sigue?