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 indica. Cada universo de GDC tiene requisitos y consideraciones únicos que se deben satisfacer 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 universo de GDC.

Es posible que tu empresa tenga varios departamentos con organizaciones separadas y que 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 las organizaciones. Asegúrate de que un usuario con privilegios en varias organizaciones no infrinja 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 usen 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 la consolidación de las identidades de los usuarios en un solo proveedor de identidad o el mantenimiento de proveedores de identidad separados funciona mejor con el enfoque de administración de identidades de tu empresa.

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

GDC se basa en tu plataforma de IAM para la autenticación, incluida la configuración de seguridad adicional, como la autenticación de varios factores. Es una práctica recomendada 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 denegar el acceso al servicio desde los proyectos, aplica restricciones de Gatekeeper a la definición de recursos personalizados 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 de cuentas de servicio persistentes 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 breve para la proyección de tokens de cuentas de servicio de tus cargas de trabajo.
  • Rota las credenciales de las cuentas 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 de proyecto a un usuario dentro de un solo proyecto, de modo que este usuario delega la autoridad para otorgar roles dentro de ese proyecto. Luego, este usuario otorga roles detallados a otros desarrolladores del proyecto en función de los servicios específicos que usan. El rol de administrador de IAM de proyecto debe restringirse a un líder de confianza, ya que este rol se podría usar para escalar privilegios, 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 que las combinaciones de roles en los proyectos no generen un riesgo de escalamiento o exfiltración.

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