Configuración de permisos de diseño

En este documento, se describen las prácticas recomendadas para el diseño de permisos en un universo aislado de Google Distributed Cloud (GDC). Se tratan los siguientes temas:

Si bien se recomiendan los siguientes diseños, no es necesario seguirlos exactamente como se indican. Cada universo de GDC tiene requisitos y consideraciones únicos que deben satisfacerse caso por caso.

Configura un proveedor de identidad por organización

Un operador debe configurar uno o más proveedores de identidad por organización. Luego, un administrador se conecta a un proveedor de identidad para administrar los servicios de autenticación de las aplicaciones en el ecosistema de GDC.

Es posible que tu empresa tenga varios departamentos con organizaciones independientes, y cada organización se conecte al mismo proveedor de identidad para la autenticación. En ese caso, es tu responsabilidad comprender y auditar la combinación de privilegios que tiene un usuario en todas las organizaciones. Asegúrate de que un usuario con privilegios en varias organizaciones no incumpla los requisitos para separar las cargas de trabajo en organizaciones distintas.

Como alternativa, es posible que tengas una situación en la que diferentes conjuntos de usuarios utilicen diferentes proveedores de identidad para autenticarse dentro de una sola organización, como cuando varios equipos de proveedores trabajan juntos en una sola organización. Considera si consolidar las identidades de los usuarios en un solo proveedor de identidad o mantener proveedores de identidad separados funciona mejor con el enfoque de tu empresa para la administración de identidades.

Configura la autenticación de varios factores para tu proveedor de identidad

GDC depende de tu plataforma de IAM para la autenticación, incluidos los parámetros de configuración de seguridad adicionales, como la autenticación de varios factores. Es una buena práctica configurar la autenticación de varios factores con una llave física para cualquier usuario que pueda acceder a recursos sensibles.

Restringe los servicios administrados y los servicios de Marketplace

Es posible que prefieras bloquear algunos proyectos de ciertos servicios para limitar la posible superficie de ataque en un proyecto o evitar el uso de servicios no aprobados. De forma predeterminada, los servicios administrados, como la Inteligencia Artificial y el aprendizaje automático, están disponibles para usarse en cualquier proyecto. En comparación con los servicios administrados, los servicios de Marketplace primero deben habilitarse para la organización.

Para rechazar el acceso al servicio desde los proyectos, aplica restricciones de Gatekeeper a la definición de recurso personalizado de un servicio y a una lista de espacios de nombres. El enfoque para denegar el acceso con Gatekeeper se aplica a los servicios administrados y de Marketplace.

Administra archivos kubeconfig para varios clústeres

Las diferentes tareas operativas requieren una conexión a diferentes clústeres. Por ejemplo, realizas tareas como vincular un rol de IAM a un proyecto y tareas como implementar un recurso Pod de Kubernetes en un clúster de Kubernetes.

Cuando usas la consola de GDC, no necesitas saber qué clúster subyacente realiza una tarea, ya que la consola de GDC abstrae las operaciones de bajo nivel, como la conexión a un clúster.

Sin embargo, cuando trabajas con la CLI de gdcloud o la CLI de kubectl, es posible que tengas varios archivos kubeconfig para realizar tus tareas. Asegúrate de acceder con las credenciales de kubeconfig para el clúster adecuado para tu tarea.

Prácticas recomendadas para las cuentas de servicio de Kubernetes

En el caso de las cuentas de servicio de Kubernetes, la autorización se basa en un token secreto. Para mitigar el riesgo de los tokens de cuentas de servicio, considera las siguientes prácticas recomendadas:

  • Evita descargar credenciales persistentes de cuentas de servicio para usarlas fuera de GDC.
  • Ten en cuenta las rutas de escalamiento de Kubernetes para los usuarios o las cuentas de servicio que tienen la capacidad de crear y editar pods.
  • Establece el campo expirationSeconds en un período corto para la proyección del token de la cuenta de servicio de tus cargas de trabajo.
  • Rota las credenciales de la cuenta de servicio con regularidad.

Considera el principio de privilegio mínimo

Considera el principio de privilegio mínimo (PoLP) cuando otorgues vinculaciones de roles a los usuarios. De acuerdo con el PoLP, considera asignar solo los privilegios necesarios para completar una tarea.

Por ejemplo, le otorgas el rol de administrador de IAM del proyecto a un usuario dentro de un solo proyecto para que este delegue la autoridad para otorgar roles dentro de ese proyecto. Luego, este usuario otorga roles detallados a otros desarrolladores del proyecto según los servicios específicos que usan. El rol de administrador de IAM del proyecto debe restringirse a un líder de confianza, ya que se podría usar para aumentar los privilegios y otorgarse a sí mismo o a otros roles adicionales en el proyecto.

Realiza auditorías periódicas para detectar privilegios excesivos

Asegúrate de revisar los roles otorgados dentro de tu organización y auditar los privilegios excesivos. Debes asegurarte de que los roles otorgados sean necesarios para que un usuario individual complete su trabajo y de que las combinaciones de roles en los proyectos no generen un riesgo de escalamiento o exfiltración.

Si tu empresa utiliza varias organizaciones, no recomendamos que un usuario individual tenga roles con privilegios altos en varias organizaciones, ya que esto podría incumplir el motivo por el que se separaron las organizaciones en primer lugar.