Configuración de permisos de diseño

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

Aunque se recomiendan los siguientes diseños, no es obligatorio seguirlos al pie de la letra. Cada universo de GDC tiene requisitos y consideraciones únicos que deben cumplirse caso por caso.

Configurar un proveedor de identidades por organización

Un operador debe configurar uno o varios proveedores de identidades por organización. A continuación, un administrador se conecta a un proveedor de identidades para gestionar los servicios de autenticación de las aplicaciones del universo de GDC.

Puede que tu empresa tenga varios departamentos con organizaciones independientes, y que cada organización se conecte al mismo proveedor de identidades para la autenticación. En ese caso, es tu responsabilidad conocer y auditar la combinación de privilegios que tiene un usuario en las distintas 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.

También puede darse el caso de que diferentes grupos de usuarios utilicen distintos proveedores de identidades para autenticarse en una misma organización, por ejemplo, cuando varios equipos de proveedores trabajan juntos en una misma organización. Determina si es mejor consolidar las identidades de los usuarios en un único proveedor de identidades o mantener proveedores de identidades independientes en función del enfoque de gestión de identidades de tu empresa.

Configurar la autenticación multifactor para el proveedor de identidades

GDC se basa en tu plataforma de gestión de identidades y accesos para la autenticación, incluidos los ajustes de seguridad adicionales, como la autenticación multifactor. Es recomendable configurar la autenticación multifactor con una llave física para cualquier usuario que pueda acceder a recursos sensibles.

Restringir los servicios gestionados y de marketplace

Puede que prefieras bloquear el acceso a determinados servicios en algunos proyectos para limitar la superficie de ataque potencial en un proyecto o evitar el uso de servicios no aprobados. De forma predeterminada, los servicios gestionados, como la inteligencia artificial y el aprendizaje automático, se pueden usar en cualquier proyecto. A diferencia de los servicios gestionados, los servicios de marketplace deben habilitarse primero para la organización.

Para denegar el acceso a los servicios 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 método para denegar el acceso con Gatekeeper se aplica a los servicios gestionados y de marketplace.

Gestionar archivos kubeconfig de varios clústeres

Para realizar diferentes tareas operativas, es necesario conectarse a distintos clústeres. Por ejemplo, puedes realizar tareas como vincular un rol de gestión de identidades y accesos a un proyecto y tareas como desplegar un recurso Pod de Kubernetes en un clúster de Kubernetes.

Cuando usas la consola de GDC, no es necesario que sepas qué clúster subyacente realiza una tarea, ya que la consola de GDC abstrae las operaciones de bajo nivel, como conectarse a un clúster.

Sin embargo, cuando trabajas con la CLI gdcloud o la CLI de kubectl, es posible que tengas varios archivos kubeconfig para realizar tus tareas. Asegúrate de que inicies sesión con las credenciales de kubeconfig del 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 reducir el riesgo de que se produzcan problemas con los tokens de cuentas de servicio, sigue estas prácticas recomendadas:

  • Evita descargar credenciales de cuentas de servicio persistentes para usarlas fuera de GDC.
  • Ten en cuenta las rutas de escalada de Kubernetes para los usuarios o las cuentas de servicio que pueden crear y editar pods.
  • Define el campo expirationSeconds con un periodo breve para la proyección de tokens de cuentas de servicio de tus cargas de trabajo.
  • Rota periódicamente las credenciales de las cuentas de servicio.

Tener en cuenta el principio de mínimos accesos

Ten en cuenta el principio de mínimos accesos (PoLP) al conceder vinculaciones de roles a los usuarios. De acuerdo con el PoLP, considera la posibilidad de asignar solo los privilegios necesarios para completar una tarea.

Por ejemplo, puedes conceder el rol de administrador de IAM de proyecto a un usuario dentro de un único proyecto para que este usuario delegue la autoridad para conceder roles dentro de ese proyecto. A continuación, este usuario concede roles específicos a otros desarrolladores del proyecto en función de los servicios concretos que utilicen. El rol de administrador de IAM de proyecto debe restringirse a un responsable de confianza, ya que este rol podría usarse para escalar privilegios, concediéndose a sí mismo o a otros usuarios roles adicionales en el proyecto.

Auditar periódicamente los privilegios excesivos

Revisa los roles concedidos en tu organización y audítalos para detectar privilegios excesivos. Debes asegurarte de que los roles concedidos sean necesarios para que un usuario pueda completar su trabajo y de que las combinaciones de roles en los proyectos no supongan un riesgo de escalada o de exfiltración.

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