Acerca de la federación de identidades de cargas de trabajo de flotas

En esta página se describe la federación de identidades de cargas de trabajo de flotas, que es un mecanismo para autenticar solicitudes de cargas de trabajo de flotas a las Google Cloud APIs. En esta página, se explica qué es la identidad de cargas de trabajo, cómo funciona la federación de identidades de cargas de trabajo de flotas y las prácticas recomendadas para gestionarla a gran escala.

Esta página está dirigida a administradores y operadores de plataformas, así como a ingenieros de seguridad que quieran gestionar de forma más eficiente la autorización de cargas de trabajo a gran escala. Para obtener más información sobre los roles de usuario y las tareas de ejemplo que mencionamos en la documentación, consulta Roles y tareas comunes de usuario de GKE. Google Cloud

Antes de leer esta página, asegúrate de que conoces los siguientes conceptos:

Acerca de las identidades de cargas de trabajo federadas en Google Cloud

Workload Identity Federation es una Google Cloud función que permite que las cargas de trabajo de tus clústeres se autentiquen en Google Cloud sin que tengas que descargar, rotar manualmente y gestionar las credenciales. En su lugar, las cargas de trabajo se autentican mediante tokens de corta duración generados por Google Cloud.

Workload Identity Federation para GKE es una implementación específica de GKE de Workload Identity Federation que proporciona un grupo de identidades de carga de trabajo gestionado por Google en todo el proyecto, desde el que las aplicaciones que se ejecutan en clústeres de GKE obtienen identidades. La federación de identidades de cargas de trabajo de flotas amplía la federación de identidades de cargas de trabajo de GKE a todos los clústeres miembros de la flota, independientemente de si los clústeres están en proyectos diferentes o fuera de Google Cloud. Con la federación de identidades de cargas de trabajo de flotas, los clústeres registrados que tienen habilitada la federación de identidades de cargas de trabajo en su pertenencia a la flota obtienen identidades mediante un grupo de identidades de cargas de trabajo gestionado por Google en toda la flota. Este grupo compartido te permite configurar la autenticación en las APIs y en otros servicios de toda tu flota, incluso en varios proyectos. Google Cloud

Fleet Workload Identity Federation también puede utilizarse por el agente de Connect en algunos tipos de clústeres para autenticarse en Google Cloud como parte de la pertenencia a la flota. Además, es necesario para usar algunas funciones de GKE que funcionan en varios proyectos, como Cloud Service Mesh.

Acerca de los grupos de identidades de carga de trabajo

Un grupo de identidades de carga de trabajo es una entidad que gestiona de forma centralizada las identidades de tus aplicaciones. Cuando habilitas Workload Identity Federation para GKE en tus clústeres, el proyecto del clúster obtiene un grupo de identidades de carga de trabajo gestionado por Google que tiene un nombre fijo específico del proyecto. Las aplicaciones de tus clústeres obtienen identidades del grupo de identidades de carga de trabajo gestionado por Google para autenticar las llamadas a la API. Google Cloud El grupo de identidades de carga de trabajo gestionado por Google tiene la sintaxis PROJECT_ID.svc.id.goog, donde PROJECT_ID es el ID del proyecto del clúster.

Con la federación de identidades de cargas de trabajo de flotas, el grupo de identidades de cargas de trabajo gestionado por Google del proyecto host de la flota también es el grupo de identidades de cargas de trabajo de todos los clústeres que registres en la flota, independientemente de si esos clústeres están en otros proyectos o fuera de Google Cloud. Todos los clústeres de la flota usan el pool de FLEET_HOST_PROJECT_ID.svc.id.goog identidad de cargas de trabajo, donde FLEET_HOST_PROJECT_ID es el ID del proyecto de host de la flota.

Si usas ámbitos de equipo, puedes configurar opcionalmente un grupo de identidades de carga de trabajo de IAM autogestionado para que los clústeres lo usen además del grupo gestionado por Google. Este grupo autogestionado ofrece un control más explícito sobre las cargas de trabajo que obtienen identidades específicas.

Cada aplicación de tu flota obtiene una identidad federada distinta del pool de identidades de cargas de trabajo de la flota, que la aplicación puede usar para autenticarse enGoogle Cloud y en otros servicios que desarrolles. Las aplicaciones obtienen un identificador principal que IAM puede reconocer. Este identificador utiliza la siguiente sintaxis:

PREFIX://iam.googleapis.com/projects/FLEET_PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_IDENTITY_POOL_NAME/SELECTOR

Esta sintaxis tiene los siguientes campos:

  • PREFIX: principal o principalSet, en función del tipo de recurso de Kubernetes que selecciones en el campo SELECTOR.
  • FLEET_PROJECT_NUMBER: el número de proyecto del proyecto host de la flota.

  • WORKLOAD_IDENTITY_POOL_NAME: el grupo de identidades de carga de trabajo de tu flota. Este valor depende del grupo de identidades de carga de trabajo que hayas configurado en cada clúster, tal como se indica a continuación:

    • Grupo de identidades de carga de trabajo gestionado por Google: FLEET_HOST_PROJECT_ID.svc.id.goog

    • Grupo de identidades de carga de trabajo autogestionado (vista previa): POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog, donde POOL_HOST_PROJECT_NUMBER es el número de proyecto del proyecto en el que has creado el grupo de identidades de carga de trabajo autogestionado.

  • SELECTOR: el selector de recursos. Para ver una lista de los selectores admitidos, consulta la sección Identificadores principales admitidos. Por ejemplo, subject/ns/NAMESPACE/sa/SERVICEACCOUNT selecciona un recurso ServiceAccount de Kubernetes específico en un espacio de nombres concreto.

Toda la flota comparte un grupo de identidades de cargas de trabajo de la flota, por lo que puedes dar acceso a las aplicaciones de cualquier parte de la flota, incluidos otros proyectos o nubes, a los mismos recursos sin tener que gestionar ese acceso para cada clúster.

Acerca de la igualdad de identidades

Al igual que otras funciones habilitadas para flotas, la federación de Workload Identity de flotas se basa en el principio de igualdad, en el que los objetos de Kubernetes que tienen el mismo nombre y espacio de nombres en diferentes clústeres se tratan como lo mismo. Para obtener más información sobre el principio general de igualdad en las flotas, consulta Igualdad.

Con Workload Identity Federation de un solo proyecto para GKE, la identidad es la misma para todas las entidades que comparten un identificador principal en ese proyecto. Sin embargo, con la federación de identidades de carga de trabajo de la flota, esta igualdad de identidades se aplica implícitamente a todas las entidades que comparten un identificador principal en toda la flota, independientemente del proyecto del clúster.

Por ejemplo, supongamos que tienes una aplicación con un backend que se ha desplegado en varios clústeres de la misma flota. Si asignas un rol a un identificador de principal que selecciona la cuenta de servicio de Kubernetes default en el espacio de nombres de Kubernetes backend, cualquier aplicación de ese espacio de nombres que use esa cuenta de servicio obtendrá el mismo acceso.

Si tu flota solo ejecuta clústeres en el proyecto host de la flota, las implicaciones de la igualdad de identidades son las mismas que en Workload Identity Federation para GKE. Sin embargo, si tu flota tiene clústeres que se ejecutan en otros proyectos o fuera deGoogle Cloud, esta igualdad de identidad implícita se extiende a todos los clústeres registrados en la flota.

Identidad idéntica en entornos de varios clientes o de confianza mixta

De forma predeterminada, tu flota usa el grupo de identidades de cargas de trabajo gestionado por Google del proyecto host de la flota para proporcionar identidades a las cargas de trabajo de toda la flota. Todos los clústeres del proyecto host de la flota, incluidos los clústeres independientes que no están registrados en la flota, usan este grupo de identidades de carga de trabajo. En un entorno de confianza mixta en el que estos clústeres independientes ejecutan cargas de trabajo que tienen un modelo de confianza diferente, esta identidad implícita puede provocar un acceso no deseado.

Las flotas te permiten gestionar este modelo multicliente mediante permisos de equipo y espacios de nombres de flota. Los permisos de equipo te permiten designar subconjuntos de recursos de flota, como clústeres, para que los usen equipos específicos de tu organización. Los espacios de nombres de flota te permiten definir espacios de nombres de Kubernetes en ámbitos de equipos específicos, de forma que determinados equipos solo puedan ejecutar cargas de trabajo en los espacios de nombres de su ámbito de equipo. Para obtener más información, consulta el artículo Información general sobre la gestión de equipos de flotas.

Si usas ámbitos de equipo, puedes mitigar las complejidades de la igualdad de identidades en flotas multiempresa configurando tu propio grupo de identidades de cargas de trabajo para que lo usen clústeres específicos de tu flota en lugar del grupo de identidades de cargas de trabajo gestionado por Google. Por lo tanto, los identificadores principales de esas cargas de trabajo son explícitamente diferentes de los identificadores principales de los clústeres independientes del proyecto. Esta identidad explícita ofrece a los administradores más control sobre los límites en los que se aplica la identidad.

El modelo de igualdad de identidades de tu flota cambia de la siguiente manera, en función de si usas solo el grupo de identidades de cargas de trabajo gestionado por Google o si configuras un grupo de identidades de cargas de trabajo autogestionado:

  • Identidad implícita: todas las cargas de trabajo de una flota usan el grupo de identidades de carga de trabajo gestionado por Google. Por lo tanto, todas las cargas de trabajo que comparten el mismo identificador principal también comparten el mismo acceso.

  • Identidad explícita (vista previa): configura un grupo de identidades de carga de trabajo autogestionado para los ámbitos de equipo de la flota. El grupo autogestionado solo proporciona identidades a las cargas de trabajo si configuras un clúster para que use el grupo autogestionado en un espacio de nombres de flota específico. Las cargas de trabajo que se ejecutan en otros espacios de nombres y clústeres de Kubernetes no pueden usar el grupo autogestionado.

    Por lo tanto, la identidad de las cargas de trabajo que usan el grupo autogestionado es diferente de la de las cargas de trabajo que solo pueden usar el grupo de identidades de carga de trabajo gestionado por Google.

Cuándo usar grupos de identidades de carga de trabajo autogestionados

Usa el grupo de identidades de carga de trabajo gestionado por Google si todos los clústeres tienen un nivel de confianza similar en el que las mismas entidades implementan las mismas aplicaciones. Por ejemplo, una flota específica de un equipo con un clúster en cada región que implemente una aplicación replicada en cada clúster.

Te recomendamos que configures un grupo de identidades de cargas de trabajo autogestionado para tu flota en situaciones como las siguientes:

  • Varios niveles de confianza en la flota: ejecutas clústeres que tienen varios niveles de confianza. Por ejemplo, supongamos que los equipos de finanzas y los de frontend tienen clústeres en la misma flota. Un pool de identidades de carga de trabajo autogestionado te ayuda a separar las concesiones de acceso de cada equipo por espacio de nombres de flota. Esto significa que ni siquiera el administrador del clúster de frontend puede obtener una identidad en el espacio de nombres de la flota a menos que tenga permisos explícitos.
  • Varios niveles de confianza en el proyecto: tu proyecto de host de flota ejecuta clústeres independientes que pueden no tener el mismo nivel de confianza que los clústeres de tu flota. De forma predeterminada, estos clústeres independientes usan el grupo de identidades de carga de trabajo gestionado por Google del proyecto host de la flota. Tus clústeres de la flota también usan este grupo de identidades de cargas de trabajo, independientemente del proyecto del clúster de la flota. Configurar un grupo de identidades de carga de trabajo autogestionado para la flota asegura que las concesiones de acceso del grupo autogestionado no concedan acceso por error a los clústeres independientes.
  • Prácticas recomendadas para los ámbitos de equipo: ya usas las funciones de gestión de equipos de la flota y quieres implementar las prácticas recomendadas para conceder acceso a las cargas de trabajo. Si configuras un grupo de identidades de cargas de trabajo autogestionado, podrás conceder acceso a las cargas de trabajo de un espacio de nombres de flota específico en un ámbito de equipo sin conceder ese acceso a otros ámbitos de equipo que ejecuten cargas de trabajo en los mismos clústeres.

Cómo funciona la federación de identidades de cargas de trabajo de flotas

En las siguientes secciones se describe cómo funciona la federación de identidades de carga de trabajo de la flota, incluido el flujo de credenciales de autenticación y los identificadores principales de gestión de identidades y accesos admitidos.

Flujo de credenciales

Para permitir que las aplicaciones de un espacio de nombres específico se autentiquen mediante la federación de identidades de carga de trabajo de la flota, haz lo siguiente:

  1. Implementa un ConfigMap en ese espacio de nombres que tenga la siguiente información:

    • El grupo de identidades de carga de trabajo y el proveedor de identidades de tu clúster.
    • Ruta de cada pod en la que Kubernetes monta un token de ServiceAccount. Este token es un JSON Web Token (JWT) firmado.

    Este ConfigMap funciona como el archivo de credenciales predeterminadas de la aplicación (ADC) para las cargas de trabajo.

  2. Crea una política de permiso de gestión de identidades y accesos que conceda acceso aGoogle Cloud recursos específicos al identificador principal de la cuenta principal de tus clústeres, como una cuenta de servicio en el espacio de nombres.

  3. Asegúrate de que tu carga de trabajo en el espacio de nombres tenga las siguientes configuraciones en la especificación del pod:

    • La variable de entorno GOOGLE_APPLICATION_CREDENTIALS definida en la ruta de montaje del ConfigMap en el pod.
    • Un volumen proyectado que contiene el token de ServiceAccount y el ConfigMap que has creado, montado en la misma ruta que especifiques en la variable de entorno GOOGLE_APPLICATION_CREDENTIALS.
    • Un montaje de volumen en el contenedor que hace referencia al volumen proyectado.

Cuando la carga de trabajo hace una llamada a la API Google Cloud , se siguen estos pasos:

  1. Las bibliotecas de autenticación de Google Cloud usan las credenciales de aplicación predeterminadas (ADC) para encontrar las credenciales. ADC comprueba la ruta que has especificado en la variable de entorno GOOGLE_APPLICATION_CREDENTIALS para buscar un token de autenticación.
  2. La biblioteca de autenticación de ADC usa los datos de ConfigMap para intercambiar el JWT de ServiceAccount que has montado en el pod por un token de acceso federado de corta duración del servicio de token de seguridad que hace referencia al identificador principal de la carga de trabajo.
  3. ADC incluye el token de acceso federado en la solicitud de la API.
  4. La política de permiso de gestión de identidades y accesos autoriza al identificador de la entidad principal a realizar la operación solicitada en el recurso Google Cloud .

Identificadores de principales admitidos para la federación de identidades de cargas de trabajo de flotas

En la siguiente tabla se describen los selectores que puedes usar en las políticas de permiso de gestión de identidades y accesos para hacer referencia a los principales de las flotas:

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

Haz los cambios siguientes:

  • PROJECT_NUMBER: tu número de proyecto. Para obtener el número de proyecto, consulta el artículo sobre cómo identificar proyectos.
  • PROJECT_ID: tu ID de proyecto Google Cloud .
  • NAMESPACE: el espacio de nombres de Kubernetes.
  • SERVICEACCOUNT: el nombre de la cuenta de servicio de Kubernetes.
Selecciona la cuenta de servicio por UID: 
principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/kubernetes.serviceaccount.uid/SERVICEACCOUNT_UID

Haz los cambios siguientes:

  • PROJECT_NUMBER: tu número de proyecto. Para obtener el número de proyecto, consulta el artículo sobre cómo identificar proyectos.
  • PROJECT_ID: tu ID de proyecto de Fleet.
  • SERVICEACCOUNT_UID: el UID del objeto ServiceAccount en el servidor de la API.

Siguientes pasos