Configuración de permisos de diseño

En este documento se describen las prácticas recomendadas para diseñar permisos en un universo con air gap 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 autenticarse. En ese caso, es tu responsabilidad conocer 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 incumpla los requisitos para separar las cargas de trabajo en organizaciones distintas.

También puede darse el caso de que diferentes conjuntos de usuarios utilicen distintos proveedores de identidades para autenticarse en una misma organización, como cuando varios equipos de proveedores trabajan juntos en una misma organización. Valora si es mejor consolidar las identidades de los usuarios en un único proveedor de identidades o mantener proveedores de identidades independientes según el enfoque de tu empresa en cuanto a la gestión de identidades.

Configurar la autenticación multifactor para tu 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 una práctica recomendada configurar la autenticación multifactor con una llave física para cualquier usuario que pueda acceder a recursos sensibles.

Restringir los servicios gestionados y los servicios del mercado

Puede que prefieras bloquear algunos proyectos de determinados servicios para limitar la superficie de ataque potencial de 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 en 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 del mercado.

Gestionar archivos kubeconfig de varios clústeres

Las distintas tareas operativas requieren una conexión a diferentes clústeres. Por ejemplo, puedes vincular un rol de gestión de identidades y accesos a un proyecto o desplegar un recurso Pod de Kubernetes en un clúster de Kubernetes.

Cuando usas la consola de GDC, no tienes que 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, al trabajar con la CLI de gdcloud o la CLI de kubectl, es posible que tengas varios archivos kubeconfig para llevar a cabo tus tareas. Asegúrate de iniciar 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 los tokens de cuentas de servicio, sigue estas prácticas recomendadas:

  • No descargues 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 puedan crear y editar pods.
  • Define el campo expirationSeconds en un periodo breve para la proyección del token de la cuenta 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 enlaces de roles a los usuarios. De acuerdo con el principio de mínimos accesos, asigna solo los privilegios necesarios para completar una tarea.

Por ejemplo, puedes asignar el rol Administrador de IAM de proyecto a un usuario en un solo proyecto para que pueda delegar la autoridad para asignar roles en ese proyecto. A continuación, este usuario asigna roles específicos a otros desarrolladores del proyecto en función de los servicios concretos que utilicen. El rol de administrador de gestión de identidades y accesos del proyecto debe asignarse solo a un responsable de confianza, ya que se podría usar para aumentar los privilegios y concederse a sí mismo o a otros usuarios roles adicionales en el proyecto.

Realiza auditorías periódicas para detectar privilegios excesivos

Revisa los roles concedidos en tu organización y audita los 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 exfiltración.

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