Esta página está dirigida a administradores y operadores de plataformas, así como a ingenieros de seguridad que quieran minimizar los riesgos asociados a la igualdad de identidades en las flotas.
Antes de leer esta página, asegúrate de que conoces los conceptos de Acerca de la federación de identidades de cargas de trabajo de flotas.
Terminología
En esta página se utiliza la siguiente terminología:
- Workload Identity Federation for GKE: una función que proporciona identidades a las cargas de trabajo de GKE en un solo Google Cloud proyecto.
- Federación de identidades de cargas de trabajo de flotas: una función que amplía la federación de identidades de cargas de trabajo de GKE a las cargas de trabajo de toda la flota, incluidas las que están fuera de Google Cloudy las que se encuentran en varios proyectos.
- Grupo de identidades de carga de trabajo: entidad que proporciona identidades a las cargas de trabajo en un formato compatible con Identity and Access Management (IAM). Cada clúster es un proveedor de identidades de un grupo de identidades de carga de trabajo.
Identidad de flotas
Los grupos de identidades de carga de trabajo son entidades que proporcionan identidades a las cargas de trabajo en un formato que IAM puede usar al autenticar y autorizar solicitudes. Con Workload Identity Federation para GKE, cada proyecto tiene de forma predeterminada un grupo de identidades de carga de trabajo fijo y gestionado por Google que es único para ese proyecto.
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 es el grupo de identidades de cargas de trabajo predeterminado de todos los clústeres que registres en la flota, independientemente de si los clústeres están en otros proyectos u otras nubes. También puedes configurar un grupo de identidades de carga de trabajo autogestionado para que lo usen clústeres específicos en lugar del grupo predeterminado.
Tanto en Workload Identity Federation de flotas como en Workload Identity Federation para GKE, se usan políticas de permiso de gestión de identidades y accesos (IAM) para asignar roles en recursos Google Cloudespecíficos a entidades de los clústeres, como cuentas de servicio de Kubernetes o pods. En tus políticas de permiso, haces referencia a estas entidades mediante un identificador principal, que es una sintaxis de nomenclatura que IAM puede leer. El identificador principal incluye el nombre del grupo de identidades de carga de trabajo que usa el clúster y otra información que selecciona las entidades específicas del clúster. Por ejemplo, el siguiente identificador de cuenta principal selecciona una cuenta de servicio de Kubernetes en un espacio de nombres:
principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_IDENTITY_POOL_NAME/subject/ns/NAMESPACE/sa/SERVICEACCOUNT
En este ejemplo, los siguientes campos contienen información sobre la entidad principal:
PROJECT_NUMBER: número de proyecto del proyecto host de la flota.WORKLOAD_IDENTITY_POOL_NAME: el nombre del grupo de identidades de carga de trabajo.NAMESPACE: el nombre del espacio de nombres.SERVICEACCOUNT: el nombre de la cuenta de servicio de Kubernetes.
Las solicitudes a las APIs de Google Cloud se autentican mediante tokens de acceso de OAuth 2.0 de corta duración que generan los clústeres. Estos tokens de acceso incluyen el identificador principal de la entidad que creó la solicitud. IAM usa el identificador principal para asegurarse de que una política de permiso autoriza a la entidad a realizar la operación solicitada.
Implicaciones de la igualdad de identidades en flotas con varios clientes
El identificador principal da como resultado la identidad idéntica, lo que significa que cualquier entidad del entorno que coincida con un identificador principal específico se considera lo mismo en IAM. Con la federación de identidades de carga de trabajo 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 cargas de trabajo de flotas, esta identidad se aplica a todas las entidades que comparten un identificador principal en toda la flota, independientemente del proyecto del clúster.
Por ejemplo, con el identificador de principal de la sección anterior, las solicitudes de los pods que usan la misma cuenta de servicio, el mismo espacio de nombres y el mismo grupo de identidades de carga de trabajo obtienen el mismo identificador de principal, independientemente del clúster o del proyecto.
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, la identidad será la misma en todos los clústeres registrados de la flota.
Ejemplos de complejidades de la igualdad de identidades de flotas
En los siguientes ejemplos se describen las posibles complejidades de la identidad que pueden surgir al implementar la federación de identidades de cargas de trabajo de flotas. En cada escenario se ofrecen posibles medidas de mitigación que pueden ayudarte a gestionar estas complejidades.
Flota de un solo proyecto con todos los clústeres registrados y el mismo grupo de identidades de carga de trabajo
Considera la siguiente configuración de flota:
- Todos los clústeres miembros de la flota están en el proyecto de host de la flota.
- Todos los clústeres del proyecto son miembros de la flota.
- Todos los clústeres usan el mismo grupo de identidades de carga de trabajo.
En este caso, todos los clústeres miembros de la flota están en el proyecto de host de la flota y todos los clústeres de ese proyecto son miembros de la flota.
Tal como se describe en la sección Implicaciones de la identidad en las flotas, usar Workload Identity Federation de la flota en este caso es lo mismo que usar Workload Identity Federation para GKE, y no hay ningún riesgo adicional.
Flota de un solo proyecto con algunos clústeres registrados y el mismo grupo de identidades de carga de trabajo
Considera la siguiente configuración de flota:
- La flota contiene dos clústeres, ambos en el proyecto de host de la flota.
- El proyecto de host de la flota contiene un tercer clúster que no es miembro de la flota.
- El clúster que no es miembro de la flota también tiene habilitada la federación de identidades de carga de trabajo para GKE.
- Todos los clústeres del proyecto usan el mismo grupo de identidades de carga de trabajo
Con esta configuración, los roles que concedas a una entidad de un clúster del proyecto se aplicarán a otras entidades del proyecto que coincidan con el identificador principal. Esto puede provocar que se concedan permisos por error a entidades que no forman parte de la flota. Por ejemplo, si se asigna un rol a un identificador principal que selecciona una cuenta de servicio específica en un espacio de nombres, se producen las siguientes implicaciones:
- Las cargas de trabajo que se ejecutan en el espacio de nombres especificado y usan la cuenta de servicio especificada en los clústeres miembros de la flota comparten el acceso.
- Las cargas de trabajo que se ejecutan en el tercer clúster no miembro que usan el mismo espacio de nombres y el mismo nombre de cuenta de servicio también obtienen el mismo acceso.
Las siguientes sugerencias pueden ayudarte a resolver esta complejidad:
- Configura los clústeres miembros de la flota para que usen un grupo de identidades de cargas de trabajo autogestionado (vista previa). De esta forma, las entidades de los clústeres miembros de la flota tienen identificadores principales diferentes a los del clúster no miembro. Para obtener más información, consulta Autenticar APIs de Google Cloud cargas de trabajo de flotas de confianza mixta.
Crea un proyecto de host de flota específico y usa políticas de la organización para evitar que el proyecto de host de flota específico ejecute clústeres. De esta forma, se separa el dominio de confianza del grupo de identidades de carga de trabajo de toda la flota de los dominios de confianza a nivel de proyecto de GKE. Solo los clústeres registrados comparten el grupo de identidades de carga de trabajo de toda la flota.
Estas sugerencias funcionan en clústeres de Google Cloud y en clústeres adjuntos.
Flota de varios proyectos con algunos clústeres registrados y el mismo grupo de identidades de carga de trabajo
Considera la siguiente configuración de flota:
- La flota contiene clústeres miembros que se ejecutan en dos proyectos: Google Cloud,
project-1yproject-2. project-1es el proyecto del host de la flota. Todos los clústeres deproject-1son miembros de la flota.project-2contiene un clúster miembro de la flota y un clúster no registrado.- Todos los clústeres de
project-1usan el grupo de Workload Identity gestionado por Google del proyecto, que también es el grupo de Workload Identity predeterminado de toda la flota. - El clúster miembro de la flota de
project-2usa el grupo de identidades de cargas de trabajo de toda la flota.
En este caso, los permisos que concedas a las entidades del proyecto de host de la flota también se aplicarán a las entidades del clúster miembro de project-2, ya que todas comparten el mismo grupo de identidades de carga de trabajo.
Para intentar resolver esta complejidad, crea un Google Cloud proyecto
específico que se usará como proyecto host de la flota. Los clústeres miembros de la flota de project-1 y project-2 comparten de forma predeterminada el grupo de identidades de cargas de trabajo del proyecto dedicado. A continuación, puedes conceder acceso a nivel de proyecto a los clústeres de project-1 mediante el grupo de identidades de carga de trabajo de project-1 en el identificador principal.
Impedir la creación de identidades similares
Para que las identidades sean iguales en las flotas, debes implementar cuidadosamente el control de acceso para evitar la creación intencionada o no intencionada de identidades similares. Por ejemplo, supongamos que quieres conceder acceso a todos los pods que usan un ServiceAccount específico en un espacio de nombres. Si alguien crea ese espacio de nombres y esa cuenta de servicio en otro clúster miembro de la flota, los pods de ese clúster obtendrán el mismo acceso.
Para reducir las probabilidades de que se produzca este problema, utiliza un mecanismo de autorización para permitir que solo un conjunto de usuarios de confianza cree, actualice o elimine espacios de nombres y cuentas de servicio de Kubernetes.
En el caso de IAM, los siguientes permisos proporcionan este acceso:
container.namespaces.*container.serviceAccounts.*
En el caso del control de acceso basado en roles (RBAC) de Kubernetes, los siguientes ClusterRoles de ejemplo configuran un acceso especial para interactuar con estos recursos de Kubernetes:
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: namespace-admin rules: - apiGroups: [""] resources: ["namespaces"] verbs: ["create","delete","update","patch"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: serviceaccount-admin rules: - apiGroups: [""] resources: ["serviceaccounts"] verbs: ["create","delete","update","patch","impersonate"]