Acerca de la federación de identidades para cargas de trabajo para GKE


La Federación de identidades para cargas de trabajo 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.

La federación de identidades para cargas de trabajo para GKE está disponible a través de la federación de identidades para cargas de trabajo de IAM, que proporciona identidades para las cargas de trabajo que se ejecutan en entornos dentro y fuera de Google Cloud. Puedes usar la federación de identidades para cargas de trabajo de IAM para autenticarte de forma segura en las APIs de Google Cloud compatibles desde cargas de trabajo que se ejecutan en, por ejemplo, AWS, Azure y Kubernetes autoadministrado. En GKE, Google Cloud administra el grupo y el proveedor de Workload Identity por ti y no requiere un proveedor de identidad externo.

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 APIs de Google Cloud.

¿Qué es la federación de identidades para cargas de trabajo para GKE?

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

La federación de identidades para cargas de trabajo para GKE te permite usar políticas de IAM para otorgar a las cargas de trabajo de Kubernetes en tu clúster de GKE acceso a APIs específicas de Google Cloud sin necesidad de una configuración manual ni métodos menos seguros, como los archivos de claves de la cuenta de servicio. El uso de la federación de identidades para cargas de trabajo para GKE te permite asignar identidades y autorizaciones distintas y detalladas para cada aplicación en el clúster.

La federación de identidades para cargas de trabajo para GKE reemplaza la necesidad de usar ocultamiento de metadatos. Los metadatos sensibles protegidos con la ocultación de metadatos también están protegidos por la federación de identidades para cargas de trabajo para GKE.

Cómo funciona la federación de identidades para cargas de trabajo para GKE

Cuando habilitas la federación de identidades para cargas de trabajo para GKE en un clúster, GKE hace lo siguiente:

  • Crea un grupo de identidades para cargas de trabajo fijo para el proyecto de Google Cloud del clúster con el siguiente formato:

    PROJECT_ID.svc.id.goog
    

    El grupo de identidades para cargas de trabajo proporciona un formato de nombre que permite a IAM comprender y confiar en las credenciales de la cuenta de servicio de Kubernetes.

  • Registra el clúster de GKE como un proveedor de identidad en el grupo de Workload Identity.

  • Implementa el servidor de metadatos de GKE, que intercepta las solicitudes de credenciales de las cargas de trabajo en cada nodo.

Crea políticas de permisos de IAM en los recursos de Google Cloud

Para proporcionar acceso con la federación de identidades para cargas de trabajo para GKE, crea una política de permisos de IAM que otorgue acceso en un recurso específico de Google Cloud a una principal que corresponda a la identidad de tu aplicación. Por ejemplo, puedes otorgar permisos de lectura en un bucket de Cloud Storage a todos los Pods que usan la ServiceAccount de Kubernetes database-reader.

Para obtener una lista de los recursos que admiten políticas de permisos, consulta Tipos de recursos que aceptan políticas de permisos.

También puedes limitar el permiso del acceso si configuras condiciones en las políticas de permisos. Por ejemplo, si solo deseas otorgar acceso de lectura en un bucket a los Pods que usan la ServiceAccount database-reader en el clúster mysql, puedes establecer esa condición en tu política de permisos. Para obtener información sobre el uso de condiciones en las políticas de permisos, consulta Administra vinculaciones de roles condicionales.

Recursos de referencia de Kubernetes en las políticas de IAM

En tu política de IAM, haces referencia a un recurso de Kubernetes mediante un identificador principal de IAM para seleccionar el recurso. Este identificador tiene la siguiente sintaxis:

PREFIX://iam.googleapis.com/projects/1234567890/locations/global/workloadIdentityPools/example-project.svc.id.goog/SELECTOR

En este ejemplo, considera los siguientes campos:

  • PREFIX: Debe ser principal o principalSet, según el recurso que selecciones. principal es para un recurso específico, como una sola ServiceAccount. principalSet es para varios recursos que pertenecen al recurso especificado, como todos los Pods en un clúster específico.
  • SELECTOR: una string que selecciona un tipo de principal. Por ejemplo, kubernetes.serviceaccount.uid/SERVICEACCOUNT_UID selecciona una ServiceAccount por su UID.

En la siguiente tabla, se muestran los tipos de principales compatibles en GKE:

Tipo de identificador principal Sintaxis
Todos los pods que usan una ServiceAccount de Kubernetes específica Selecciona la ServiceAccount por nombre:
principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/SERVICEACCOUNT

Reemplaza lo siguiente:

  • PROJECT_NUMBER: el número de proyecto numérico. Para obtener el número de proyecto, consulta Identifica proyectos.
  • PROJECT_ID: tu ID del proyecto de Google Cloud.
  • NAMESPACE: El espacio de nombres de Kubernetes.
  • SERVICEACCOUNT: El nombre de la cuenta de servicio de Kubernetes.

Selecciona la ServiceAccount por UID:
principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/kubernetes.serviceaccount.uid/SERVICEACCOUNT_UID

Reemplaza lo siguiente:

  • PROJECT_NUMBER: el número de proyecto numérico. Para obtener el número de proyecto, consulta Identifica proyectos.
  • PROJECT_ID: tu ID del proyecto de Google Cloud.
  • SERVICEACCOUNT_UID: El UID del objeto ServiceAccount en el servidor de la API.
Todos los Pods en un clúster específico
principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/kubernetes.cluster/https://container.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME

Reemplaza lo siguiente:

  • PROJECT_NUMBER: el número de proyecto numérico. Para obtener el número de proyecto, consulta Identifica proyectos.
  • PROJECT_ID: tu ID del proyecto de Google Cloud.
  • CLUSTER_NAME: Es el nombre del clúster de GKE.
  • LOCATION: Es la ubicación de tu clúster.

Flujo de credenciales

Cuando una carga de trabajo envía una solicitud para acceder a una API de Google Cloud, por ejemplo, cuando se usa una biblioteca cliente de Google Cloud, se producen los siguientes pasos de autenticación:

Cómo una carga de trabajo obtiene un token de cuenta de servicio de IAM con Workload Identity.
Figura 1: Cómo una carga de trabajo obtiene un token de identidad federada con la federación de identidades para cargas de trabajo para GKE.
  1. Las credenciales predeterminadas de la aplicación (ADC) solicitan un token de acceso de Google Cloud desde el servidor de metadatos de Compute Engine que se ejecuta en la VM.
  2. El servidor de metadatos de GKE intercepta la solicitud del token y solicita al servidor de la API de Kubernetes un token de cuenta de servicio de Kubernetes que identifique la carga de trabajo solicitante. Esta credencial es un token web JSON (JWT) firmado por el servidor de la API.
  3. El servidor de metadatos de GKE usa el servicio de tokens de seguridad para intercambiar el JWT por un token de acceso federado de corta duración de Google Cloud que hace referencia a la identidad de la carga de trabajo de Kubernetes.
  4. El servidor de metadatos de GKE proporciona el token de acceso federado a la carga de trabajo.

Luego, la carga de trabajo puede acceder a cualquier API de Google Cloud a la que pueda acceder el identificador principal de IAM de la carga de trabajo.

Similitud de identidad

Si los metadatos en tu identificador principal son los mismos para las cargas de trabajo en varios clústeres que comparten un grupo de grupo de identidades para cargas de trabajo porque pertenecen al mismo proyecto de Google Cloud, IAM identifica esas cargas de trabajo como iguales. Por ejemplo, si tienes el mismo espacio de nombres en dos clústeres y otorgas acceso a ese espacio de nombres en IAM, las cargas de trabajo en ese espacio de nombres en ambos clústeres obtienen ese acceso. Puedes limitar este acceso a clústeres específicos mediante las políticas de IAM condicionales.

Por ejemplo, considera el siguiente diagrama. Los clústeres A, B y C pertenecen al mismo grupo de identidades para cargas de trabajo. Google Cloud identifica las aplicaciones que usan la ServiceAccount back-ksa en el espacio de nombres backend del Clúster A y el Clúster B como la misma identidad. IAM no distingue entre los clústeres que realizan las llamadas.

Diagrama que ilustra la similitud de identidad en un grupo de identidades para cargas de trabajo
Figura 2: Similitud de identidad con acceso a las API de Google Cloud con la federación de identidades para cargas de trabajo para GKE.

Esta similitud de identidad también significa que debes poder confiar en cada clúster de un grupo de identidades para cargas 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 ServiceAccount back-ksa 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 identificador principal común.

Comprende el servidor de metadatos de GKE

Cada nodo en un GKE con la federación de identidades para cargas de trabajo para GKE habilitada 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.

Restricciones de la federación de identidades para cargas de trabajo para GKE

  • No puedes cambiar el nombre del grupo de Workload Identity que GKE crea para tu proyecto de Google Cloud.

  • Cuando GKE habilita el servidor de metadatos de GKE en un grupo de nodos, los Pods ya no pueden acceder al servidor de metadatos de Compute Engine. En cambio, el servidor de metadatos de GKE intercepta las solicitudes realizadas de estos Pods a los extremos de metadatos, excepto los Pods que se ejecutan en la red del host.

  • El servidor de metadatos de GKE toma unos segundos en comenzar a aceptar solicitudes en un Pod recién creado. Por lo tanto, los intentos de autenticación mediante la federación de identidades para cargas de trabajo para GKE en los primeros segundos de la vida del Pod podrían fallar. Intentar la llamada resolverá el problema. Consulta Solución de problemas para obtener más detalles.

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

  • La federación de identidades para cargas de trabajo para GKE requiere una configuración manual para Knative serving a fin de continuar lanzando métricas de solicitudes.

  • La federación de identidades para cargas de trabajo para GKE establece un límite de 200 conexiones al servidor de metadatos de GKE para cada nodo a fin de evitar problemas de memoria. Es posible que experimentes tiempos de espera si los nodos exceden este límite.

  • La federación de identidades para cargas de trabajo para GKE paras nodos de Windows Server está disponible en las versiones de GKE 1.18.16-gke.1200, 1.19.8-gke.1300, 1.20.4-gke.1500 y posteriores.

  • El servidor de metadatos de GKE usa recursos de memoria de forma proporcional a la cantidad total de cuentas de servicio de Kubernetes en tu clúster. Si tu clúster tiene más de 3,000 cuentas de servicio de Kubernetes, kubelet podría finalizar los Pods del servidor de metadatos. Para conocer las mitigaciones, consulta Solución de problemas.

Alternativas a la federación de identidades para cargas de trabajo para GKE

Puedes usar una de las siguientes alternativas a la federación de identidades para cargas de trabajo para que GKE acceda a las APIs de Google Cloud desde GKE. Te recomendamos que uses la federación de identidades para cargas de trabajo para GKE, ya que estas alternativas requieren que realices compromisos de seguridad determinados.

¿Qué sigue?