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

En esta página, se describe la federación de identidades para cargas de trabajo de la flota, que es un mecanismo para autenticar solicitudes de cargas de trabajo de la flota a las APIs de Google Cloud . En esta página, obtendrás información sobre la identidad de las cargas de trabajo, cómo funciona la federación de identidades para cargas de trabajo de la flota y las prácticas recomendadas para administrarla a gran escala.

Esta página está destinada a los administradores y operadores de la plataforma, y a los ingenieros de seguridad que desean administrar de manera 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 a los que hacemos referencia en la documentación de Google Cloud, consulta Roles de usuario y tareas comunes de GKE.

Antes de leer este documento, asegúrate de estar familiarizado con los siguientes conceptos:

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

La federación de identidades para cargas de trabajo 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 de forma manual y, en general, administrar las credenciales. En su lugar, las cargas de trabajo se autentican con tokens de corta duración generados por Google Cloud.

La federación de identidades para cargas de trabajo para GKE es una implementación específica de GKE de la federación de identidades para cargas de trabajo que proporciona un grupo de identidades para cargas de trabajo administrado 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 para cargas de trabajo de flota extiende la federación de identidades para 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 para cargas de trabajo de la flota, los clústeres registrados que tienen habilitada la federación de identidades para cargas de trabajo en su membresía de flota obtienen identidades a través de un grupo de identidades para cargas de trabajo administrado por Google en toda la flota. Este grupo compartido te permite configurar la autenticación en las APIs de Google Cloud y en otros servicios en toda tu flota, incluso en varios proyectos.

El agente de Connect también puede usar la federación de identidades para cargas de trabajo de flota en algunos tipos de clústeres para autenticarse en Google Cloud como parte de la membresía de la flota. Además, es necesario usar algunas funciones de GKE que funcionan en varios proyectos, como Cloud Service Mesh.

Acerca de los grupos de identidades para cargas de trabajo

Un grupo de identidades para cargas de trabajo es una entidad que administra de forma centralizada las identidades de tus aplicaciones. Cuando habilitas la federación de identidades para cargas de trabajo para GKE en tus clústeres, el proyecto del clúster obtiene un grupo de identidades para cargas de trabajo administrado por Google que tiene un nombre fijo y específico del proyecto. Las aplicaciones de tus clústeres obtienen identidades del grupo de identidades para cargas de trabajo administrado por Google para autenticar las llamadas a la API Google Cloud . El grupo de identidades de cargas de trabajo administrado por Google tiene la sintaxis PROJECT_ID.svc.id.goog, en la que PROJECT_ID es el ID del proyecto del clúster.

Con la federación de identidades para cargas de trabajo de flota, el grupo de identidades para cargas de trabajo administrado por Google del proyecto host de la flota también es el grupo de identidades para 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. Cada clúster de la flota usa el grupo de identidades de cargas de trabajo FLEET_HOST_PROJECT_ID.svc.id.goog, en el que FLEET_HOST_PROJECT_ID es el ID del proyecto host de la flota.

Si usas alcances de equipo, puedes configurar de forma opcional un grupo de identidades para cargas de trabajo de IAM autoadministrado para que los clústeres lo usen además del grupo administrado por Google. Este grupo autoadministrado proporciona un control más explícito sobre qué cargas de trabajo obtienen identidades específicas.

Cada aplicación de tu flota obtiene una identidad federada distinta del grupo de identidades para 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 usa 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, según el tipo de recurso de Kubernetes que selecciones en el campo SELECTOR.
  • FLEET_PROJECT_NUMBER: Es el número del proyecto host de la flota.

  • WORKLOAD_IDENTITY_POOL_NAME: Es el grupo de identidades para cargas de trabajo de tu flota. Este valor depende del grupo de identidades para cargas de trabajo que configures en cada clúster, de la siguiente manera:

    • Grupo de identidades para cargas de trabajo administrado por Google: FLEET_HOST_PROJECT_ID.svc.id.goog

    • Grupo de identidades para cargas de trabajo autoadministrado (vista previa): POOL_NAME.global.POOL_HOST_PROJECT_NUMBER.workload.id.goog, donde POOL_HOST_PROJECT_NUMBER es el número del proyecto en el que creaste el grupo de identidades para cargas de trabajo autoadministrado.

  • SELECTOR: Es el selector de recursos. Para obtener una lista de los selectores compatibles, consulta la sección Identificadores de principal compatibles. Por ejemplo, subject/ns/NAMESPACE/sa/SERVICEACCOUNT selecciona una ServiceAccount de Kubernetes específica en un espacio de nombres específico.

Toda la flota comparte un grupo de identidades para cargas de trabajo de la flota, de modo que puedes darle a las aplicaciones de cualquier parte de la flota, incluidos otros proyectos o nubes, acceso a los mismos recursos sin necesidad de administrar ese acceso para cada clúster.

Acerca de la similitud de identidad

Al igual que otras funciones habilitadas para la flota, la federación de identidades para cargas de trabajo de la flota se basa en el principio de similitud, en el que los objetos de Kubernetes que tienen el mismo nombre y espacio de nombres en diferentes clústeres se tratan de la misma manera. Para obtener más información sobre el principio general de similitud en las flotas, consulta Similitud.

Con la federación de identidades para cargas de trabajo para GKE de un solo proyecto, la igualdad de identidades se aplica a todas las entidades que comparten un identificador principal en ese proyecto. Sin embargo, con la federación de identidades para cargas de trabajo de la flota, esta identidad idéntica se aplica de forma implícita a todas las entidades que comparten un identificador principal en toda la flota, independientemente del proyecto del clúster.

Por ejemplo, considera una aplicación con un backend implementado en varios clústeres de la misma flota. Si otorgas un rol a un identificador de principal que selecciona la ServiceAccount default de Kubernetes en el espacio de nombres backend de Kubernetes, cualquier aplicación de ese espacio de nombres que use esa ServiceAccount obtendrá el mismo acceso.

Si tu flota solo ejecuta clústeres en el proyecto host de la flota, las implicaciones de la identidad son las mismas que para la federación de identidades para cargas de trabajo de GKE. Sin embargo, si tu flota tiene clústeres que se ejecutan en otros proyectos o fuera deGoogle Cloud, esta identidad implícita idéntica se extiende a todos los clústeres registrados en la flota.

Similitud de identidad en entornos de múltiples usuarios o de confianza mixta

De forma predeterminada, tu flota usa el grupo de identidades de cargas de trabajo administrado por Google del proyecto host de la flota para proporcionar identidades a las cargas de trabajo en 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 cargas 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 similitud de identidad implícita podría generar acceso no deseado.

Las flotas te permiten administrar este modelo de múltiples usuarios con permisos de equipo y espacios de nombres de flota. Los permisos del 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 flotas te permiten definir espacios de nombres de Kubernetes dentro de permisos de equipo específicos, de modo que ciertos equipos solo puedan ejecutar cargas de trabajo en los espacios de nombres de su permiso de equipo. Para obtener más información, consulta la descripción general de la administración de equipos de flota.

Si usas permisos de equipo, puedes mitigar las complejidades de la identidad en flotas de múltiples arrendatarios configurando tu propio grupo de identidades para cargas de trabajo para que lo usen clústeres específicos de tu flota en lugar del grupo de identidades para cargas de trabajo administrado por Google. Como resultado, los identificadores principales de esas cargas de trabajo son explícitamente diferentes de los identificadores principales de los clústeres independientes en el proyecto. Esta similitud de identidad explícita brinda a los administradores más control sobre los límites dentro de los cuales se aplica la similitud de identidad.

El modelo de identidad idéntica en tu flota cambia de la siguiente manera, según si usas solo el grupo de identidades para cargas de trabajo administrado por Google o si configuras un grupo de identidades para cargas de trabajo autoadministrado:

  • Identidad implícita: Todas las cargas de trabajo de una flota usan el grupo de identidades para cargas de trabajo administrado por Google. Como resultado, cada carga de trabajo que comparte el mismo identificador principal también comparte implícitamente el mismo acceso.

  • Similitud de identidad explícita (vista previa): Configuras un grupo de identidades para cargas de trabajo autoadministrado para los permisos del equipo en la flota. El grupo autoadministrado solo proporciona identidades a las cargas de trabajo si configuras un clúster para que use el grupo autoadministrado para 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 autoadministrado.

    Como resultado, la identidad de las cargas de trabajo que usan el grupo autoadministrado es diferente de la identidad de las cargas de trabajo que solo pueden usar el grupo de identidades para cargas de trabajo administrado por Google.

Cuándo usar grupos de identidades para cargas de trabajo autoadministrados

Usa el grupo de identidades de cargas de trabajo administrado por Google si cada clúster tiene un nivel de confianza similar en el que las mismas entidades implementan las mismas aplicaciones. Por ejemplo, una flota específica del equipo con un clúster en cada región que implementa una aplicación replicada en cada clúster.

Te recomendamos que configures un grupo de identidades para cargas de trabajo autoadministrado 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, considera una situación en la que los equipos de finanzas y los equipos de frontend tienen clústeres en la misma flota. Un grupo de identidades de carga de trabajo autoadministrado te ayuda a separar las concesiones de acceso para cada equipo por espacio de nombres de la 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 host de flota ejecuta clústeres independientes que podrían 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 identidad de la carga de trabajo administrado por Google del proyecto host de la flota. Tus clústeres de flota también usan este grupo de identidades para cargas de trabajo, independientemente del proyecto del clúster de flota. Configurar un grupo de identidades para cargas de trabajo autoadministrado para la flota garantiza que los permisos de acceso en el grupo autoadministrado no otorguen acceso de forma involuntaria a los clústeres independientes.
  • Prácticas recomendadas para los permisos de equipo: Ya usas las funciones de administración de equipos de la flota y deseas implementar las prácticas recomendadas para otorgar acceso a las cargas de trabajo. Configurar un grupo de identidades para cargas de trabajo autoadministrado te permite otorgar acceso a cargas de trabajo en un espacio de nombres de flota específico en un alcance de equipo sin otorgar ese acceso a otros alcances de equipo que ejecutan cargas de trabajo en los mismos clústeres.

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

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

Flujo de credenciales

Para permitir que las aplicaciones de un espacio de nombres específico se autentiquen con la federación de identidades para cargas 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 para cargas de trabajo y el proveedor de identidad de tu clúster
    • Es la ruta en cada Pod en la que Kubernetes activa un token de ServiceAccount. Este token es un token web JSON (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 permisos de IAM que otorgue acceso en recursosGoogle Cloud específicos al identificador principal de la principal en tus clústeres, como una ServiceAccount en el espacio de nombres.

  3. Asegúrate de que tu carga de trabajo en el espacio de nombres tenga la siguiente configuración en la especificación del Pod:

    • La variable de entorno GOOGLE_APPLICATION_CREDENTIALS establecida en la ruta de activación del ConfigMap en el Pod
    • Un volumen proyectado que contiene el token de la cuenta de servicio y el ConfigMap que creaste, activado en la misma ruta que especificas en la variable de entorno GOOGLE_APPLICATION_CREDENTIALS
    • Una activación de volumen en el contenedor que hace referencia al volumen proyectado.

Cuando la carga de trabajo realiza una llamada a la API de Google Cloud , se realizan los siguientes pasos:

  1. Las bibliotecas de autenticación de Google Cloud usan credenciales predeterminadas de la aplicación (ADC) para encontrar credenciales. ADC verifica la ruta que especificaste 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 del ConfigMap para intercambiar el JWT de la cuenta de servicio que activaste en el Pod por un token de acceso federado de corta duración del servicio de tokens de seguridad que hace referencia al identificador principal de la carga de trabajo.
  3. ADC incluye el token de acceso federado con la solicitud a la API.
  4. La política de permisos de IAM autoriza al identificador principal a realizar la operación solicitada en el recurso Google Cloud .

Identificadores principales compatibles para la federación de identidades para cargas de trabajo de la flota

En la siguiente tabla, se describen los selectores que puedes usar en las políticas de IAM para permitir que hagan referencia a principales en flotas:

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: El ID de tu 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: El ID de tu proyecto de flota
  • SERVICEACCOUNT_UID: El UID del objeto ServiceAccount en el servidor de la API.

¿Qué sigue?