Antes de leer esta guía, debes familiarizarte con los conceptos descritos en Cómo autenticar en APIs y servicios desde cargas de trabajo de flotas.
Para conocer las prácticas recomendadas sobre la adopción de otras funciones de la flota, consulta Planifica las funciones de la flota.
Grupos de identidad de proyectos y flotas
Para comprender por qué la federación de identidades para cargas de trabajo de toda la flota requiere una adopción cuidadosa, en especial cuando se trabaja con flotas de varios proyectos, veamos en detalle cómo funciona la federación habitual de identidades para cargas de trabajo para GKE y la federación de identidades para cargas de trabajo de la flota. En ambos casos, las cargas de trabajo se autentican mediante tokens de corta duración generados por los clústeres, con cada clúster agregado como proveedor de identidad a un grupo de identidad de carga de trabajo especial. Las cargas de trabajo que se ejecutan en un espacio de nombres específico pueden compartir la misma identidad de IAM entre los clústeres.
Esto es lo que sucede con la federación normal de identidades para cargas de trabajo para GKE cuando se habilita en tus clústeres. Ten en cuenta que la federación de identidades para cargas de trabajo para GKE está habilitada para los clústeres de Autopilot de forma predeterminada.
- GKE crea un grupo de identidades de carga de trabajo administrado por Google en el proyecto del clúster:
PROJECT_ID.svc.goog.id. - GKE agrega los clústeres como proveedores de identidad al grupo.
- Como resultado, las cargas de trabajo que se ejecutan en un espacio de nombres específico comparten la misma identidad de IAM en todos los clústeres de un proyecto. La identidad tiene el siguiente formato:
serviceAccount:PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME].
La federación de identidades para cargas de trabajo de toda la flota se habilita de forma automática cuando agregas un clúster con la federación de identidades para cargas de trabajo para GKE habilitada a una flota, incluidos los clústeres de Autopilot, los clústeres estándar con la función habilitada de forma explícita y los clústeres de GKE fuera de Google Cloud.
Esto es lo que sucede cuando un usuario registra un clúster con la federación de identidades para cargas de trabajo para GKE habilitada en una flota:
- Se crea el grupo de identidades de cargas de trabajo de toda la flota administrado por Google
FLEET_PROJECT_ID.svc.goog.iden el proyecto host de la flota, si el grupo aún no existe. Esto es lo mismo que el grupo de identidades de cargas de trabajo del proyecto host de la flota. - El clúster se agrega como un proveedor de identidad al grupo.
- Como resultado, las cargas de trabajo que se ejecutan en un espacio de nombres específico comparten la misma identidad de IAM en los clústeres de la flota. Nos referimos a esto como similitud implícita de identidades de carga de trabajo de flota. La identidad tiene el siguiente formato:
serviceAccount:FLEET_PROJECT_ID.svc.id.goog[K8S_NAMESPACE/KSA_NAME]. Luego, las cargas de trabajo de la flota en proyectos diferentes pueden llamar a las APIs de Google con la misma identidad para la autenticación.
Como se sugiere, si la flota solo incluye clústeres de un proyecto y todos están registrados en la flota, el resultado es el mismo que si solo usaras la federación de identidades para cargas de trabajo para GKE sin flotas: todos los clústeres son proveedores de identidad en el grupo de identidad de la carga de trabajo del proyecto, y las cargas de trabajo usan las mismas identidades que usarían con la federación de identidades para cargas de trabajo para GKE. Sin embargo, cuando la flota tiene clústeres de miembros en varios proyectos, la federación de identidades para cargas de trabajo de la flota combina los grupos de identidad por proyecto en un solo grupo de identidad para toda la flota, alojado en el proyecto host de la flota.
Como verás en los siguientes ejemplos, pueden ocurrir algunas complejidades cuando solo hay una superposición parcial entre el conjunto de clústeres de un proyecto y el conjunto de clústeres de ese proyecto que son miembros de un flota.
Situación 1: Flota de un solo proyecto con todos los clústeres registrados
En esta situación, todos los clústeres miembros de la flota están en el proyecto host de la flota y todos los clústeres de ese proyecto son miembros de la flota.
Como se describe en la sección anterior, usar la federación de identidades para cargas de trabajo de toda la flota en esta situación es lo mismo que usar la federación de identidades para cargas de trabajo normal para GKE, y no hay riesgos adicionales.
Situación 2: Flota de un solo proyecto con algunos clústeres registrados
En esta situación, una flota contiene dos clústeres, ambos en el proyecto host de la flota en el Proyecto 1. El proyecto host de la flota también contiene un tercer clúster que no es miembro de la flota, que tiene habilitada la federación de identidades para cargas de trabajo para GKE.
Esto significa lo siguiente:
- GKE agrega los clústeres 1, 2 y 3 al grupo de identidades de la carga de trabajo del proyecto
project-1.svc.goog.id. - La flota agrega los clústeres 1 y 2 al grupo de identidades de cargas de trabajo de la flota, que (ya que este es el proyecto host de la flota) también es el grupo de identidades de cargas de trabajo del proyecto
project-1.svc.goog.id.
El administrador desea otorgar permisos a las cargas de trabajo que se ejecutan en un espacio de nombres en todos los clústeres de la flota. Usan serviceAccount:project-1.svc.goog.id[namespace/ksa] como la identidad para otorgar acceso. Sin embargo, las cargas de trabajo en ese espacio de nombres en el Clúster 3, que no forma parte de la flota, ahora comparten el mismo acceso. Esto se debe a que el Clúster 3 está en el grupo de identidades de cargas de trabajo del proyecto, que (porque este es el proyecto host de la flota) es el mismo que el grupo de identidades de cargas de trabajo de la flota. En otras palabras, el administrador podría tener la intención de otorgar permisos solo a los clústeres de una flota, pero, debido a la implementación de la federación de identidades para cargas de trabajo de flota, los clústeres que no pertenecen a la flota también podrían obtener acceso.
Posible mitigación
Una solución posible es crear un proyecto dedicado para alojar la flota sin clústeres, aplicado por la política de la organización personalizada en la API del contenedor. Esto proporciona una separación clara del dominio de confianza del grupo de identidades de la carga de trabajo de la flota de los dominios de confianza a nivel del proyecto de GKE.
Luego, el administrador puede elegir el dominio de confianza adecuado cuando otorga permisos a las cargas de trabajo. Por ejemplo, pueden usar serviceAccount:project-0.svc.goog.id[namespace/ksa] para otorgar permisos a una carga de trabajo con espacio de nombres de toda la flota. El Clúster 3 que no es miembro de la flota no forma parte de ese grupo de identidades de cargas de trabajo en esta configuración, por lo que no obtiene acceso.
Esta solución funciona para clústeres en Google Cloud y clústeres adjuntos.
Situación 3: Flota de varios proyectos con algunos clústeres registrados
En esta situación, una flota tiene miembros de dos proyectos, el Proyecto 1 y el Proyecto 2.
El administrador desea otorgar permisos a las cargas de trabajo que se ejecutan en un espacio de nombres en todos los clústeres del Proyecto 1 mediante la federación normal de identidades para cargas de trabajo para GKE. Sin embargo, como el Clúster 4 está registrado en la flota y el Proyecto 1 es el proyecto host de la flota, las cargas de trabajo del Clúster 4 en el Proyecto 2 también obtendrán los mismos permisos.
Posible mitigación
Al igual que en la situación anterior, una posible mitigación aquí es crear un proyecto host de flota dedicado sin clústeres. Una vez más, esto permite que el administrador distinga entre las identidades del grupo de identidades de la flota y el grupo de identidades del proyecto de cada clúster cuando configura el control de acceso.
Situación 4: Considera la similitud de espacio de nombres
Los grupos de identidades de cargas de trabajo no son el único área potencial de confusión cuando se usa la federación de identidades para cargas de trabajo. Como sabes en Planifica las funciones de la flota, muchas funciones de la flota, incluida la federación de identidades para cargas de trabajo de la flota, usan la suposición de la similitud de espacios de nombres para simplificar la configuración y la administración de toda la flota. Esto significa que la función trata los espacios de nombres con el mismo nombre en varios clústeres de miembros de la flota como si fueran el mismo espacio de nombres. En este ejemplo, un administrador otorgó permisos a las cargas de trabajo en el espacio de nombres NS1 que se ejecutan en los clústeres miembros de la flota, el Clúster 1 y el Clúster 2.
Sin embargo, un usuario creó (de forma accidental o maliciosa) un espacio de nombres con el mismo nombre en otro clúster miembro de la flota. Debido a la suposición de similitud de espacio de nombres, las cargas de trabajo en ese espacio de nombres obtienen automáticamente los mismos privilegios que las cargas de trabajo legítimas de NS1 en el Clúster 1 y el Clúster 2.
Posible mitigación
Establece permisos para que solo un grupo pequeño de roles de confianza pueda crear espacios de nombres en clústeres.