Reduce los riesgos de similitud de identidad en flotas de múltiples usuarios

En esta página, se proporcionan prácticas recomendadas para configurar y usar la federación de identidades para cargas de trabajo de la flota, que es una función de la flota que te permite configurar de forma centralizada la autenticación de aplicaciones en las Google Cloud APIs en todos los proyectos. Para conocer las prácticas recomendadas sobre la adopción de otras funciones de la flota, consulta Planifica las funciones de la flota.

Esta página está destinada a los administradores y operadores de la plataforma, y a los ingenieros de seguridad que desean minimizar los riesgos asociados con la similitud de identidad en las flotas.

Antes de leer esta página, asegúrate de estar familiarizado con los conceptos de Acerca de la federación de identidades para cargas de trabajo de la flota.

Terminología

En esta página, se usa 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 para cargas de trabajo de la flota: Es una función que extiende Workload Identity Federation for GKE a las cargas de trabajo en toda la flota, incluso fuera de ella Google Cloud y en varios proyectos.
  • Grupo de identidades para cargas de trabajo: Es una 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 identidad en un grupo de identidades para cargas de trabajo.

Similitud de identidad en las flotas

Los grupos de identidades para cargas de trabajo son entidades que proporcionan identidades a las cargas de trabajo en un formato que IAM puede usar cuando autentica y autoriza solicitudes. Con Workload Identity Federation for GKE, cada proyecto tiene un grupo de identidades para cargas de trabajo fijo y administrado por Google de forma predeterminada que es único para ese proyecto.

Con la federación de identidades para cargas de trabajo de la flota, el grupo de identidades para cargas de trabajo administrado por Google para el proyecto host de la flota es el grupo de identidades para cargas de trabajo predeterminado para todos los clústeres que registras en la flota, independientemente de si los clústeres están en otros proyectos o en otras nubes. De manera opcional, puedes configurar un grupo de identidades para cargas de trabajo autoadministrado para que lo usen clústeres específicos en lugar del grupo predeterminado.

Tanto en la federación de identidades para cargas de trabajo de la flota como en Workload Identity Federation for GKE, usas políticas de permisos de IAM para otorgar funciones en recursos específicos Google Cloud a entidades de tus clústeres, como ServiceAccounts o Pods de Kubernetes. En tus políticas de permisos, haces referencia a estas entidades con un identificador principal, que es una sintaxis de nombres que IAM puede leer. El identificador principal incluye el nombre del grupo de identidades para cargas 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 principal selecciona una ServiceAccount 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 tienen información sobre la principal:

  • PROJECT_NUMBER: el número del proyecto host de la flota.
  • WORKLOAD_IDENTITY_POOL_NAME: el nombre del grupo de identidades para cargas de trabajo.
  • NAMESPACE: Es el nombre del espacio de nombres.
  • SERVICEACCOUNT: el nombre de la ServiceAccount de Kubernetes.

Las solicitudes a las Google Cloud APIs se autentican con 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 garantizar que una política de permisos autorice a la entidad a realizar la operación solicitada.

Implicaciones de la similitud de identidad para las flotas de varios usuarios

El identificador principal da como resultado la similitud de identidad, lo que significa que IAM considera que cualquier entidad del entorno que coincida con un identificador principal específico es lo mismo. Con Workload Identity Federation para GKE de un solo proyecto, la similitud de identidad 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 similitud de 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 principal de la sección anterior, las solicitudes de los Pods que usan la misma ServiceAccount, el mismo espacio de nombres y el mismo grupo de identidades para cargas de trabajo obtienen el mismo identificador principal, independientemente del clúster o el proyecto.

Si tu flota solo ejecuta clústeres en el proyecto host de la flota, las implicaciones de la similitud de identidad son las mismas que para Workload Identity Federation para GKE. Sin embargo, si tu flota tiene clústeres que se ejecutan en otros proyectos, la similitud de identidad se extiende a todos los clústeres registrados en la flota.

Ejemplos de complejidades para la similitud de identidad de la flota

En los siguientes ejemplos, se describen posibles complejidades de similitud de identidad que pueden ocurrir cuando implementas la federación de identidades para cargas de trabajo de la flota. Cada situación te proporciona posibles mitigaciones que pueden ayudarte a abordar estas complejidades.

Flota de un solo proyecto con todos los clústeres registrados y el mismo grupo de identidades para cargas de trabajo

Considera la siguiente configuración de la flota:

  • Todos los clústeres miembros de la flota están en el proyecto 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 para cargas de trabajo.

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.

Diagrama que muestra un proyecto con todos los clústeres en la misma flota

Como se describe en la sección Implicaciones de la similitud de identidad para las flotas, usar la federación de identidades para cargas de trabajo de la flota en esta situación es lo mismo que usar Workload Identity Federation for GKE, y no hay riesgos adicionales.

Flota de un solo proyecto con algunos clústeres registrados y el mismo grupo de identidades para cargas de trabajo

Considera la siguiente configuración de la flota:

  • La flota contiene dos clústeres, que se ejecutan en el proyecto host de la flota.
  • El proyecto 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 para cargas de trabajo para GKE.
  • Todos los clústeres del proyecto usan el mismo grupo de identidades para cargas de trabajo.

Diagrama que muestra un proyecto con algunos clústeres en la misma flota.

Con esta configuración, cualquier función que otorgues a una entidad en un clúster del proyecto se aplica a otras entidades del proyecto que coincidan con el identificador principal. Esto puede dar como resultado el otorgamiento involuntario de permisos a entidades que no forman parte de la flota. Por ejemplo, otorgar una función a un identificador principal que selecciona una cuenta de servicio específica en un espacio de nombres tiene 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 que no es miembro y que usan el mismo espacio de nombres y 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 para cargas de trabajo autoadministrado. Esto garantiza que las entidades de los clústeres miembros de la flota tengan identificadores principales diferentes del clúster que no es miembro. Para obtener más detalles, consulta Autenticación en Google Cloud APIs desde cargas de trabajo de flotas de confianza mixta.

  • Crea un proyecto host de la flota dedicado y usa políticas de la organización para evitar que el proyecto host de la flota dedicado ejecute clústeres. Esto separa el dominio de confianza del grupo de identidades para cargas de trabajo de toda la flota de los dominios de confianza a nivel del proyecto de GKE. Solo los clústeres registrados comparten el grupo de identidades para cargas de trabajo de toda la flota.

    Estas sugerencias funcionan para clústeres en Google Cloud y clústeres conectados.

Flota de varios proyectos con algunos clústeres registrados y el mismo grupo de identidades para cargas de trabajo

Considera la siguiente configuración de la flota:

  • La flota contiene clústeres miembros que se ejecutan en dos Google Cloud proyectos: project-1 y project-2.
  • project-1 es el proyecto host de la flota. Todos los clústeres de project-1 son miembros de la flota.
  • project-2 contiene un clúster miembro de la flota y un clúster no registrado.
  • Todos los clústeres de project-1 usan el grupo de identidades para cargas de trabajo administrado por Google del proyecto, que también es el grupo de identidades para cargas de trabajo predeterminado de toda la flota.
  • El clúster miembro de la flota en project-2 usa el grupo de identidades para cargas de trabajo de toda la flota.

Diagrama que muestra una flota con clústeres de dos proyectos.

En esta situación, cualquier permiso que otorgues a las entidades del proyecto host de la flota también se aplica a las entidades del clúster miembro de project-2, ya que todas comparten el mismo grupo de identidades para cargas de trabajo.

Para intentar resolver esta complejidad, crea un proyecto dedicado Google Cloud para usarlo como proyecto host de la flota. Los clústeres miembros de la flota en project-1 y en project-2 comparten el grupo de identidades para cargas de trabajo del proyecto dedicado de forma predeterminada. Luego, puedes otorgar acceso con alcance del proyecto a los clústeres en project-1 con el grupo de identidades para cargas de trabajo de project-1 en el identificador principal.

Evita la creación de identidades similares

La similitud de identidad en las flotas requiere que implementes con cuidado el control de acceso para evitar la creación intencional o involuntaria de identidades similares. Por ejemplo, considera una situación en la que otorgas acceso a todos los Pods que usan una ServiceAccount específica en un espacio de nombres. Si alguien crea ese espacio de nombres y ServiceAccount en un clúster miembro de la flota diferente, los Pods de ese clúster obtienen el mismo acceso.

Para reducir las posibilidades de que se produzca este problema, usa un mecanismo de autorización para permitir que solo un conjunto de usuarios de confianza cree, actualice o borre 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 funciones (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"]

¿Qué sigue?