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, una función de la flota que te permite configurar de forma centralizada la autenticación de aplicaciones en las APIs de todos los proyectos. Google Cloud 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 deseen minimizar los riesgos asociados con la 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: Es una función que proporciona identidades a las cargas de trabajo de GKE en un solo proyecto de Google Cloud .
  • Federación de identidades para cargas de trabajo de flota: Es una función que extiende la federación de identidades para cargas de trabajo de GKE a las cargas de trabajo de toda la flota, incluso fuera de Google Cloudy 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 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 la federación de identidades para cargas de trabajo para 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 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 registres 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 la federación de identidades para cargas de trabajo para GKE, usas políticas de permisos de IAM para otorgar roles en recursos Google Cloudespecíficos a entidades en 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 nomenclatura 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 en el clúster. Por ejemplo, el siguiente identificador de 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 contienen información sobre el principal:

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

Las solicitudes a las APIs de Google Cloud 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 de 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 multiusuario

El identificador principal genera una identidad igual, lo que significa que IAM considera que cualquier entidad del entorno que coincida con un identificador principal específico es la misma. Con la federación de identidades para cargas de trabajo para GKE de un solo proyecto, la 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 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 ServiceAccount, el mismo espacio de nombres y el mismo grupo de identidades para cargas de trabajo obtienen el mismo identificador de 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 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, la 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 la 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 podrían ayudarte a abordar estas complejidades.

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

Considera la siguiente configuración de la flota:

  • Todos los clústeres miembros de la flota se encuentran 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 de carga de trabajo.

En esta situación, todos los clústeres miembros de la flota se encuentran 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 identidad en las flotas, usar la federación de identidades para cargas de trabajo de la flota en este caso es lo mismo que usar la federación de identidades para cargas de trabajo de 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, ambos 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, los roles que otorgues a una entidad en un clúster del proyecto se aplicarán a otras entidades del proyecto que coincidan con el identificador principal. Esto podría generar que se otorguen permisos de forma involuntaria a entidades que no forman parte de la flota. Por ejemplo, otorgar un rol 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 (versión preliminar). Esto garantiza que las entidades de los clústeres miembros de la flota tengan identificadores principales diferentes de los del clúster que no es miembro. Para obtener más detalles, consulta Autenticación en APIs de Google Cloud desde cargas de trabajo de flotas de confianza mixta.

  • Crea un proyecto host de flota dedicado y usa políticas de la organización para evitar que el proyecto host de flota dedicado ejecute clústeres. Esto separa el dominio de confianza del grupo de identidades para cargas de trabajo en 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 los clústeres en Google Cloud y los clústeres adjuntos.

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

Considera la siguiente configuración de la flota:

  • La flota contiene clústeres miembros que se ejecutan en dos proyectos Google Cloud: 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 de cargas de trabajo administrado por Google del proyecto, que también es el grupo de identidades de 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, todos los permisos que otorgues a las entidades del proyecto host de la flota también se aplican a las entidades del clúster miembro de project-2, ya que todos comparten el mismo grupo de identidades de cargas de trabajo.

Para intentar resolver esta complejidad, crea un proyecto Google Cloud dedicado para usarlo como proyecto host de la flota. Los clústeres miembros de la flota en project-1 y en project-2 luego comparten el grupo de identidades para cargas de trabajo del proyecto dedicado de forma predeterminada. Luego, puedes otorgar acceso con alcance para el proyecto a los clústeres en project-1 usando 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 cuidadosamente el control de acceso para evitar la creación intencional o no intencional 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 obtendrán el mismo acceso.

Para reducir las probabilidades 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 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"]

¿Qué sigue?