Workload Identity


Workload Identity es la manera recomendada para que las cargas de trabajo que se ejecutan en Google Kubernetes Engine (GKE) accedan a los servicios de Google Cloud de manera segura y administrable.

Para obtener más información sobre cómo habilitar y usar Workload Identity en GKE, consulta Usa Workload Identity.

Puedes usar la identidad de carga de trabajo de flota para proporcionar asistencia de federación de identidades de carga de trabajo para clústeres registrados en flotas, incluidos los clústeres de Anthos.

Terminología

En este documento, se distingue entre cuentas de servicio de Kubernetes y cuentas de servicio de Identity and Access Management (IAM).

Cuentas de servicio de Kubernetes
Recursos de Kubernetes que proporcionan una identidad para los procesos que se ejecutan en tus Pods de GKE.
Cuentas de servicio de IAM
Recursos de Google Cloud que permiten a las aplicaciones realizar llamadas autorizadas a las API de Google Cloud.

¿Qué es Workload Identity?

Es posible que las aplicaciones que se ejecutan en GKE necesiten acceso a las API de Google Cloud, como la API de Compute Engine, la API de BigQuery Storage o las API de aprendizaje automático.

Workload Identity permite que una cuenta de servicio de Kubernetes en tu clúster de GKE actúe como una cuenta de servicio de IAM. Los pods que usan la cuenta de servicio de Kubernetes configurada se autentican de forma automática como la cuenta de servicio de IAM cuando accedes a las API de Google Cloud. El uso de Workload Identity te permite asignar identidades y autorizaciones distintas y detalladas para cada aplicación en el clúster.

Cómo funciona Workload Identity

Cuando habilitas Workload Identity en un clúster, GKE crea de forma automática un grupo de identidades de carga de trabajo fijo para el proyecto de Google Cloud del clúster. Un grupo de Workload Identity permite que IAM comprenda y confíe en las credenciales de la cuenta de servicio de Kubernetes. El grupo de Workload Identity tiene el siguiente formato:

PROJECT_ID.svc.id.goog

GKE usa este grupo para todos los clústeres del proyecto que usan Workload Identity.

Cuando configuras una cuenta de servicio de Kubernetes en un espacio de nombres para que use Workload Identity, IAM autentica las credenciales con el siguiente nombre de miembro:

serviceAccount:PROJECT_ID.svc.id.goog[KUBERNETES_NAMESPACE/KUBERNETES_SERVICE_ACCOUNT]

En este nombre de miembro, se da lo siguiente:

  • PROJECT_ID: Es el ID de tu proyecto de Google Cloud.
  • KUBERNETES_NAMESPACE: Es el espacio de nombres de la cuenta de servicio de Kubernetes.
  • KUBERNETES_SERVICE_ACCOUNT: Es el nombre de la cuenta de servicio de Kubernetes que realiza la solicitud.

El proceso de configuración de Workload Identity incluye el uso de una vinculación de política de IAM para vincular el nombre de miembro de la cuenta de servicio de Kubernetes a una cuenta de servicio de IAM que tenga los permisos que necesitan las cargas de trabajo. Cualquier llamada a la API de Google Cloud desde cargas de trabajo que usan esta cuenta de servicio de Kubernetes se autentica como la cuenta de servicio de IAM vinculada.

Similitud de identidad

El nombre del miembro que IAM usa para verificar una cuenta de servicio de Kubernetes con Workload Identity usa las siguientes variables:

  • El nombre de la cuenta de servicio de Kubernetes.
  • El espacio de nombres de la cuenta de servicio de Kubernetes.
  • El ID del proyecto de Google Cloud.

Si tu proyecto tiene varios clústeres que tienen el mismo nombre y espacio de nombres para una cuenta de servicio de Kubernetes, todas las cuentas se resuelven en el mismo nombre de miembro. Esta identidad común te permite otorgar acceso a los recursos de Google Cloud al grupo de identidades de carga de trabajo en lugar de los clústeres individuales.

Por ejemplo, considera el siguiente diagrama. Los clústeres A, B y C pertenecen al mismo proyecto de Google Cloud y, por lo tanto, al mismo grupo de Workload Identity. Las aplicaciones que se encuentran en el espacio de nombres backend del Clúster A y el Clúster B pueden autenticarse como la cuenta de servicio de IAM back cuando acceden a los recursos de Google Cloud. IAM no distingue entre los clústeres que realizan las llamadas.

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

Esta similitud de identidad también significa que debes poder confiar en cada clúster de un grupo de identidades de carga de trabajo específico. Por ejemplo, si el clúster C del ejemplo anterior fuera propiedad de un equipo no confiable, este podría crear un espacio de nombres backend y acceder a las API de Google Cloud mediante la cuenta de servicio back de IAM, al igual que el clúster A y el clúster B.

Para evitar el acceso no confiable, coloca tus clústeres en proyectos separados a fin de asegurarte de que tengan grupos de Workload Identity diferentes o asegúrate de que los nombres de los espacios de nombres sean distintos para evitar un nombre de miembro común.

Comprende el servidor de metadatos de GKE

Cada nodo en un GKE con Workload Identity habilitado almacena sus metadatos en el servidor de metadatos de GKE. El servidor de metadatos de GKE es un subconjunto de los extremos del servidor de metadatos de Compute Engine necesarios para las cargas de trabajo de Kubernetes.

El servidor de metadatos de GKE se ejecuta como un DaemonSet, con un Pod en cada nodo de Linux o un servicio nativo de Windows en cada nodo de Windows del clúster. El servidor de metadatos intercepta las solicitudes HTTP a http://metadata.google.internal (169.254.169.254:80). Por ejemplo, la solicitud GET /computeMetadata/v1/instance/service-accounts/default/token recupera un token para la cuenta de servicio de IAM a la que el Pod está configurado en nombre de una cuenta. El tráfico del servidor de metadatos de GKE nunca sale de la instancia de VM que aloja al Pod.

En las siguientes tablas, se describe el subconjunto de extremos del servidor de metadatos de Compute Engine disponibles con el servidor de metadatos de GKE. Para obtener una lista completa de los extremos disponibles en el servidor de metadatos de Compute Engine, consulta los valores de metadatos de VM predeterminados.

Metadatos de la instancia

Los metadatos de la instancia se almacenan en el siguiente directorio.

http://metadata.google.internal/computeMetadata/v1/instance/

Entrada Descripción
hostname

El nombre de host de tu nodo.

id

El ID único de tu nodo.

service-accounts/

Un directorio de cuentas de servicio asociadas a la instancia. Para cada cuenta de servicio, está disponible la siguiente información:

  • aliases
  • email: la dirección de correo electrónico de la cuenta de servicio.
  • identity: un token web JSON (JWT) único del nodo. Debes incluir el parámetro audience en tu solicitud. Por ejemplo, ?audience=http://www.example.com.
  • scopes: Los niveles de acceso asignados a la cuenta de servicio.
  • token: El token de acceso de OAuth 2.0 para autenticar tus cargas de trabajo.
zone

La zona de Compute Engine de tu nodo de GKE.

Atributos de la instancia

Los atributos de instancias se almacenan en el siguiente directorio:

http://metadata.google.internal/computeMetadata/v1/instance/attributes/

Entrada Descripción
cluster-location

La zona o región de Compute Engine de tu clúster.

cluster-name

El nombre del clúster de GKE.

cluster-uid

El UID del clúster de GKE.

Metadatos del proyecto

Los metadatos del proyecto del clúster se almacenan en el siguiente directorio.

http://metadata.google.internal/computeMetadata/v1/project/

Entrada Descripción
project-id

Tu ID del proyecto de Google Cloud.

numeric-project-id

Es el número de tu proyecto de Google Cloud.

Alternativas a Workload Identity

Puedes usar una de las siguientes alternativas a Workload Identity para acceder a las API de Google Cloud desde GKE.

  • Exporta claves de cuenta de servicio y almacénalas como secretos de Kubernetes. Las claves de las cuentas de servicio de Google no vencen y requieren rotación manual. 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. Si se roba una clave exportada, un atacante puede usarla para autenticarse como esa cuenta de servicio hasta que notas y revoques la clave de forma manual.

  • Usa la cuenta de servicio predeterminada 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 usa la cuenta de servicio predeterminada de Compute Engine para el proyecto. Todas las cargas de trabajo implementadas en ese nodo comparten la cuenta de servicio de Compute Engine. Esto puede generar un aprovisionamiento excesivo de permisos, lo que infringe el principio de privilegio mínimo y es inapropiado para los clústeres de usuarios múltiples.

¿Qué sigue?