Workload Identity

En esta página, se explica la manera recomendada para que tus aplicaciones de GKE consuman servicios proporcionados por las API de Google. Esto se logra mediante la configuración de una cuenta de servicio de Kubernetes para que actúe como una cuenta de servicio de Google. Cualquier pod que se ejecute como la cuenta de servicio de Kubernetes luego usa la cuenta de servicio de Google para autenticarse en los servicios en la nube.

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 superiores. Para obtener más información, consulta las alternativas a continuación.

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 aprendizaje automático. Una vez que configures la relación entre una cuenta de servicio de Kubernetes y una de Google, cualquier carga de trabajo que se ejecute como la cuenta de servicio de Kubernetes se autentica de manera automática como la cuenta de servicio de Google cuando se accede a las API de Google Cloud.

Para obtener información sobre la autorización de las cuenta de servicio de Google a fin de acceder a las API de Cloud, consulta la página con información sobre 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 Platform. Otra documentación de GCP se refiere a las GSA como “cuentas de servicio”.

Identidad entre distintos clústeres

La relación entre las GSA y las KSA está definida por el espacio de nombres de identidad asociado con el proyecto. Todas las cuentas de servicio de Kubernetes que comparten un nombre, un nombre de espacio de nombres y un espacio de nombres de identidad comparten acceso a las GSA. Esto puede ser útil si varios clústeres contienen las mismas identidades, pero puede ser peligroso si los nombres de cuentas de servicio y espacios de nombres de Kubernetes no se administran con cuidado.

Por ejemplo, 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, y que tenga habilitada Workload Identity en el clúster. 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 un ejemplo específico: los usuarios con “dev” permisivo y clústeres “prod” bloqueados deberían considerar separar esos grupos en distintos proyectos para obtener espacios de nombres de identidad diferentes.

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

  • Workload Identity está disponible para los clústeres que ejecutan la versión 1.12 de GKE y versiones posteriores.

  • 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 Workload Identity está habilitada, ya no puedes usar la cuenta de servicio predeterminada de Compute Engine. Para obtener más información, consulta la sección de alternativas a continuación.

  • No se puede usar Workload Identity con los pods que se ejecutan en la red host.

  • Los pods de infraestructura de GKE, como Stackdriver y Heapster, seguirán con el uso de la cuenta de servicio del nodo.

Antes de comenzar

Sigue estos pasos a fin de prepararte para esta tarea:

  • Asegúrate de haber habilitado la API de Google Kubernetes Engine.
    • Habilitar la API de Google Kubernetes Engine
  • Asegúrate de haber instalado el SDK de Cloud.
  • 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 haber habilitado la API de credenciales IAM.

    Habilitar la API de credenciales IAM

  2. Crea un clúster con Workload Identity habilitada y reemplaza [CLUSTER_NAME] por el nombre del clúster y [PROJECT_ID] por el nombre del proyecto de GCP:

    gcloud beta container clusters create [CLUSTER_NAME] \
  --cluster-version=1.12 \
  --identity-namespace=[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 privilegios mínimos. En cada paso se toma nota de los permisos que se requieren.

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

    gcloud container clusters get-credentials [CLUSTER_NAME]

    en el que [CLUSTER_NAME] es el nombre del clúster que creaste en el paso anterior.

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

  4. Crea la cuenta de servicio de Google y reemplaza [GSA_NAME] por el nombre que elegiste para la cuenta de servicio. Si tienes una cuenta de servicio existente, puedes usarla en lugar de crear una nueva cuenta de servicio.

    gcloud iam service-accounts create [GSA_NAME]

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

  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. Usa el espacio de nombres que creaste en el paso anterior para la opción --namespace. Reemplaza [KSA_NAME] por el nombre que deseas usar para la cuenta de servicio.

    kubectl create serviceaccount \
 --namespace [K8S_NAMESPACE] \
 [KSA_NAME]

    Esta acción requiere crear el permiso serviceaccounts RBAC 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 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.

    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

    Esta acción requiere un permiso iam.serviceAccounts.setIamPolicy en la cuenta de servicio de Google.

  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

    Esta acción requiere permisos de edición RBAC 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 \
  --serviceaccount [KSA_NAME] \
  --namespace [K8S_NAMESPACE] \
  workload-identity-test

    La imagen google/cloud-sdk incluye la herramienta de línea de comandos de gcloud, la cual es una manera conveniente de consumir API de Google Cloud Platform. 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:

    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]@[PROJECT_ID].iam.gserviceaccount.com

    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 este 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 beta 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. Modifica el clúster para habilitar Workload Identity. Los grupos de nodos existentes no se ven afectados. Los nuevos grupos de nodos están configurados como --workload-metadata-from-node=GKE_METADATA_SERVER de forma predeterminada

    gcloud beta container clusters update [CLUSTER_NAME] \
  --identity-namespace=[PROJECT_ID].svc.id.goog

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

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 nuevos grupos de nodos con Workload Identity habilitada. Te recomendamos crear nuevos grupos de nodos 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 el grupo de nodos existente para habilitar GKE_METADATA_SERVER. 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 beta container node-pools update [NODEPOOL_NAME] \
  --cluster=[CLUSTER_NAME] \
  --workload-metadata-from-node=GKE_METADATA_SERVER

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 nuevo grupo de nodos 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 beta container node-pools create [NODEPOOL_NAME] \
  --cluster=[CLUSTER_NAME] \
  --workload-metadata-from-node=GKE_METADATA_SERVER

Si un clúster tiene Workload Identity habilitada, puedes inhabilitarla de forma selectiva en un grupo de nodos en concreto si especificas --workload-metadata-from-node=EXPOSED o --workload-metadata-from-node=SECURE de manera explícita. Consulta la página sobre cómo proteger los metadatos del clúster para obtener más información.

gcloud beta container node-pools create [NODEPOOL_NAME] \
  --cluster=[CLUSTER_NAME] \
  --workload-metadata-from-node=SECURE

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

Realiza una limpieza

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

    gcloud beta container node-pools update [NODEPOOL_NAME] \
  --cluster=[CLUSTER_NAME] \
  --workload-metadata-from-node=EXPOSED

    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 ven afectados (pero la modificación se bloquea si algún grupo de nodos usa GKE_METADATA_SERVER). 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 beta 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 cuenta de servicio de Google caducan después de 10 años y se rotan de forma manual. Esto tiene el potencial de expandir el alcance de una brecha de seguridad si no se detecta.

  2. Usa la cuenta de servicio predeterminada de Compute Engine en tus nodos. Todas las cargas de trabajo implementadas en ese nodo comparten la cuenta de servicio predeterminada de Compute Engine. Esto puede generar un exceso de aprovisionamiento de permisos.

Qué sigue

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Esta página
Comentarios sobre la documentación
Documentación de Kubernetes Engine
Comentarios sobre el producto