Workload Identity

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

Descripción general

Workload Identity es la manera recomendada de acceder a los servicios de Google Cloud desde GKE, ya que ofrece propiedades de seguridad y capacidad de administración mejoradas. Para obtener información sobre formas alternativas de acceder a las API de Google desde GKE, consulta la sección Alternativas más abajo.

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

Con Workload Identity, configura una cuenta de servicio de Kubernetes (KSA) para que actúe como una cuenta de servicio de Google (GSA). Cualquier carga de trabajo que se ejecute como KSA se autenticará automáticamente como GSA cuando se acceda a las API de Google Cloud.

Para obtener información sobre cómo autorizar a las GSA a acceder a las API de Google Cloud, consulta Comprender las cuentas de servicio.

Terminología

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

Autentica cuentas de servicio de Kubernetes

De forma predeterminada, Google Cloud no puede autenticar solicitudes de una cuenta de servicio de Kubernetes (KSA) porque la cuenta de servicio se origina en un sistema de identidad externo.

Cuando habilites Workload Identity para tu clúster de GKE, configura el grupo de identidades de carga de trabajo del clúster como some.workload-pool.id.goog. GKE autentica las solicitudes de las KSA en Google Cloud mediante el siguiente nombre de miembro:

serviceAccount:some.workload-pool.id.goog[k8s_namespace/ksa_name]

En este nombre de miembro, se da lo siguiente:

  • some.workload-pool.id.goog es el grupo de identidades de carga de trabajo configurado en el clúster.
  • ksa_name es el nombre de la KSA que realiza la solicitud.
  • k8s_namespace es el espacio de nombres de Kubernetes en el que se define la KSA.

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.

Crea una relación entre las KSA y las GSA

Debido a que Workload Identity permite que Google Cloud autentique las KSA, puedes usar Cloud IAM para autorizar que una KSA funcione como una GSA.

No es necesario que la GSA esté en el mismo proyecto que el clúster. Puedes usar cualquier GSA de tu organización.

Con los siguientes comandos, se autoriza a una KSA alojada en cluster_project para que funcione como una GSA en gsa_project:

gcloud config set project gsa_project
gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:cluster_project.svc.id.goog[k8s_namespace/ksa_name]" \
  gsa_name@gsa_project.iam.gserviceaccount.com

Para anotar la KSA a fin de completar la vinculación entre la KSA y la GSA, haz lo siguiente:

kubectl annotate serviceaccount \
  --namespace k8s_namespace \
   ksa_name \
   iam.gke.io/gcp-service-account=gsa_name@gsa_project.iam.gserviceaccount.com

Usa Workload Identity desde tu 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, tus 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.

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 en http://metadata.google.internal (169.254.169.254:80), incluidas las solicitudes como GET /computeMetadata/v1/instance/service-accounts/default/token y, de ese modo, recupera un token para el pod que se configuró con el fin de que funcione como GSA. El tráfico del servidor de metadatos nunca sale de la instancia de VM que aloja al pod.

Comparte identidades entre clústeres

Todas las KSA que comparten un nombre, un nombre de espacio de nombres y un grupo de identidades de carga de trabajo se resuelven en el mismo nombre de miembro y, por lo tanto, comparten el acceso a las GSA. Esto puede ser útil si varios clústeres contienen las mismas identidades, pero podría ser peligroso si no se administran con cuidado los nombres y los espacios de nombres de las KSA.

Por ejemplo, si se habilita Workload Identity en el clúster, el siguiente comando otorga el mismo acceso a todas las cargas de trabajo de Kubernetes en cualquier clúster del proyecto que use la cuenta de servicio y el espacio de nombres predeterminados:

gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:project-id.svc.id.goog[default/default]" \
  gsa-name@project-id.iam.gserviceaccount.com

Limitaciones

  • Actualmente, 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.

  • En este momento, no se admite Workload Identity cuando se ejecuta una carga de trabajo en un clúster de Anthos GKE On-Prem.

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

  • Cuando el servidor de metadatos de GKE se habilite 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 es los pods que se ejecutan en la red del host (consulta el siguiente elemento).

  • No se puede usar Workload Identity con 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.

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

  • Workload Identity no es compatible con los nodos de Windows.

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

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

  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.

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 regionales, establece 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 nuevo

En esta sección, se explica cómo crear un clúster con Workload Identity habilitada y cómo iniciar un pod con una identidad de cuenta de servicio de Google (GSA).

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

    Habilitar la API de credenciales de Cloud IAM

  2. Crea un clúster con Workload Identity habilitada y reemplaza cluster-name por el nombre de tu clúster y project-id por el ID de tu proyecto de Google Cloud:

    gcloud beta container clusters create cluster-name \
  --release-channel regular \
  --workload-pool=project-id.svc.id.goog

    Crear el clúster tarda varios minutos.

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

    Realiza el resto de los pasos con una función menos privilegiada, de acuerdo con el Principio de mínimo privilegio. En cada paso, se toma nota de los permisos que se requieren.

  3. Configura kubectl para que se comunique con el clúster:

    gcloud container clusters get-credentials cluster-name

    En este ejemplo cluster-name es el nombre del clúster que creaste en el paso anterior.

    Para esta acción, se requiere el permiso container.clusters.get en el proyecto.

  4. Crea la cuenta de servicio de Google. Para esta acción, se requiere el permiso iam.serviceAccounts.create en el proyecto. Si tienes una cuenta de servicio existente, puedes usarla en lugar de crear una nueva.

    gcloud

    Reemplaza gsa-name por el nombre que elijas para la cuenta de servicio.

    gcloud iam service-accounts create gsa-name

    Config Connector

    Si ya instalaste Config Connector en un clúster, puedes crear un clúster de GKE nuevo con Workload Identity habilitada mediante una configuración de 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: IAMServiceAccount
metadata:
  name: [GSA_NAME]
spec:
  displayName: [GSA_NAME]
    Para implementar este manifiesto, descárgalo en tu equipo como service-account.yaml. Reemplaza GSA_NAME por el nombre que elijas para la cuenta de servicio. Luego, usa kubectl para aplicar el manifiesto.

    kubectl apply -f service-account.yaml

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

  6. Crea la cuenta de servicio de Kubernetes:

    kubectl create serviceaccount --namespace k8s-namespace ksa-name

    donde:

    • k8s-namespace es el nombre del espacio de nombres que creaste en el paso anterior.
    • ksa-name es el nombre que deseas usar para la cuenta de servicio.

    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.

  7. Para permitir que la cuenta de servicio de Kubernetes use la cuenta de servicio de Google, crea una vinculación de la política de Cloud IAM entre los dos. Esta vinculación permite que la cuenta de servicio de Kubernetes actúe como la cuenta de servicio de Google. Para esta acción, se requiere el permiso iam.serviceAccounts.setIamPolicy en el proyecto.

    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

  8. 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 annotate serviceaccount \
  --namespace k8s-namespace \
  ksa-name \
  iam.gke.io/gcp-service-account=gsa-name@project-id.iam.gserviceaccount.com

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

  9. 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 del contenedor cloud-sdk y conéctate a ella con una sesión interactiva.

    kubectl run -it \
  --generator=run-pod/v1 \
  --image google/cloud-sdk:slim \
  --serviceaccount ksa-name \
  --namespace k8s-namespace \
  workload-identity-test

    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.

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

    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.

Realiza una limpieza

  1. Revoca el acceso a la cuenta de servicio de Google de la siguiente manera:

    gcloud

    Reemplaza gsa-name por el nombre que elijas para la cuenta de servicio.

    gcloud iam service-accounts delete gsa-name

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

Habilita Workload Identity en un clúster existente

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

    Habilitar la API de credenciales de Cloud IAM

  2. Modifica el clúster para habilitar Workload Identity. Los grupos de nodos existentes no se verán afectados. Los grupos de nodos nuevos están configurados como --workload-metadata=GKE_METADATA de forma predeterminada.

    gcloud container clusters update cluster-name \
  --workload-pool=project-id.svc.id.goog

Migra cargas de trabajo 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 tu aplicación para que sea compatible con esta característica.

Opción 1: 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.

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.

Opción 2: creación de grupos de nodos con Workload Identity

Agrega un grupo de nodos nuevo al clúster con Workload Identity habilitada 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.

Limpieza

  1. Modifica los grupos de nodos existentes para inhabilitar Workload Identity:

    gcloud container node-pools update nodepool-name \
  --cluster=cluster-name \
  --workload-metadata=GCE_METADATA

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

  2. Modifica el clúster para inhabilitar Workload Identity. Los grupos de nodos existentes no se verán afectados (pero si algún grupo de nodos usa GKE_METADATA, la modificación se bloqueará). En los grupos de nodos creados después de inhabilitar Workload Identity, los pods que se ejecutan en el grupo de nodos tienen acceso al servidor de metadatos subyacente de Compute Engine de su nodo.

    gcloud container clusters update cluster-name \
  --disable-workload-identity

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

Alternativas:

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.

Inhabilita Workload Identity en tu organización

Desde una perspectiva de seguridad, Workload Identity permite a GKE confirmar las identidades de las KSA que se pueden autenticar y autorizar en los recursos de Google Cloud. En el caso de los administradores que tomaron medidas 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, podrían también querer inhabilitar Workload Identity para tu organización.

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

Próximos pasos