En esta página se explican las diferencias entre la gestión de identidades y accesos (IAM) y el control de acceso basado en roles (RBAC) de Kubernetes en Google Kubernetes Engine para ayudarte a gestionar el acceso a los recursos de tu proyecto.
Esta página está dirigida a especialistas en seguridad que controlan el acceso a los permisos y quieren conocer las diferencias y las similitudes entre IAM y RBAC. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido, consulta Roles y tareas habituales de los usuarios de GKE. Google Cloud
Cuando creas un Google Cloud proyecto, eres el único usuario del proyecto. De forma predeterminada, ningún otro usuario tiene acceso a tu proyecto ni a sus recursos, incluidos los recursos de Google Kubernetes Engine (GKE). GKE admite varias opciones para gestionar el acceso a los recursos de tu proyecto y sus clústeres mediante el control de acceso basado en roles (RBAC).
Antes de leer esta página, asegúrese de que conoce los siguientes conceptos:
- Descripción general de IAM en GKE
- Descripción general del control de acceso basado en roles de Kubernetes
Estos mecanismos se solapan en algunas funciones, pero están dirigidos a diferentes tipos de recursos. Cada uno de ellos se explica en una sección específica de esta página, pero, en resumen:
El control de acceso basado en roles de Kubernetes está integrado en Kubernetes y otorga permisos granulares a los objetos de los clústeres de Kubernetes. Los permisos se definen como objetos ClusterRole o Role en el clúster. Los objetos RoleBinding conceden roles ausuarios de Kubernetes, Google Cloud usuarios, cuentas de servicio de IAM o grupos de Google.
Si usas principalmente GKE y necesitas permisos detallados para cada objeto y operación de tu clúster, RBAC de Kubernetes es la mejor opción.
IAM gestiona Google Cloud recursos, incluidos clústeres y tipos de objetos dentro de los clústeres. Los permisos se asignan a principales de IAM.
No hay ningún mecanismo para conceder permisos para objetos de Kubernetes específicos en la gestión de identidades y accesos. Por ejemplo, puedes conceder a un usuario permiso para crear CustomResourceDefinitions (CRDs), pero no puedes concederle permiso para crear solo un CustomResourceDefinition específico ni limitar la creación a un Namespace específico o a un clúster específico del proyecto. Un rol de gestión de identidades y accesos concede privilegios en todos los clústeres del proyecto o en todos los clústeres de todos los proyectos secundarios si el rol se aplica a nivel de carpeta.
Si usas varios componentes de Google Cloud y no necesitas gestionar permisos específicos de Kubernetes de forma granular, IAM es una buena opción.
RBAC en Kubernetes
Kubernetes tiene compatibilidad integrada con RBAC, lo que te permite crear roles detallados que se encuentran en el clúster de Kubernetes. Un rol se puede acotar a un objeto de Kubernetes específico o a un tipo de objeto de Kubernetes, y define qué acciones (llamadas verbos) concede el rol en relación con ese objeto. RoleBinding también es un objeto de Kubernetes y concede roles a los usuarios. Un usuario de GKE puede ser cualquiera de los siguientes:
- Google Cloud usuario
- Cuenta de servicio de gestión de identidades y accesos
- ServiceAccount de Kubernetes
- Usuario de Google Workspace
- Grupo de Google de Google Workspace
- Usuarios autenticados mediante certificados de cliente X509
Para obtener más información, consulta el artículo Control de acceso basado en roles.
Gestión de identidades y accesos
Gestión de identidades y accesos te permite conceder roles a principales. Un rol es un conjunto de permisos que, cuando se asigna a una entidad principal, le permite acceder a uno o varios Google Cloud recursos. Para obtener más información sobre los principales, los roles y otros términos de gestión de identidades y accesos, consulta la descripción general de IAM.
En GKE, un principal puede ser cualquiera de los siguientes:
- Cuenta de usuario
- Cuenta de servicio
- Grupo de Google de Google Workspace
- Dominio de Google Workspace
- Dominio de Cloud Identity
Para obtener más información sobre cómo usar IAM para controlar el acceso en GKE, consulta Crear políticas de permiso de IAM.
Tipos de políticas de gestión de identidades y accesos
Gestión de identidades y accesos admite los siguientes tipos de políticas:
- Permitir políticas: concede roles a los principales. Para obtener más información, consulta Política de permitir.
- Políticas de denegación: impiden que los principales usen permisos de gestión de identidades y accesos específicos, independientemente de los roles que se les hayan concedido. Si quieres obtener más información, consulta el artículo sobre políticas de denegación.
Usa políticas de denegación para impedir que determinadas entidades realicen acciones específicas en tu proyecto, carpeta u organización, aunque una política de permiso de gestión de identidades y accesos les asigne un rol que contenga los permisos pertinentes.
Recomendaciones de gestión de identidades y accesos
Puedes usar los siguientes roles predefinidos de gestión de identidades y accesos para facilitar las situaciones habituales:
- Lector de clústeres de Kubernetes Engine (
roles/container.clusterViewer): profesionales de DevOps, ingenieros y desarrolladores de aplicaciones que solo necesitan conectarse al clúster. - Administrador de clústeres de Kubernetes Engine (
roles/container.clusterAdmin): administradores de la plataforma y operadores de clústeres que necesitan gestionar uno o varios clústeres en un proyecto Google Cloud .
Para ver una lista de los roles de IAM predefinidos disponibles, consulta Roles de GKE predefinidos.
GKE usa cuentas de servicio de gestión de identidades y accesos que están asociadas a tus nodos para ejecutar tareas del sistema, como el registro y la monitorización. Como mínimo, estas cuentas de servicio de nodo deben tener el rol Cuenta de servicio de nodo predeterminada de Kubernetes Engine (roles/container.defaultNodeServiceAccount) en tu proyecto. De forma predeterminada, GKE usa la cuenta de servicio predeterminada de Compute Engine, que se crea automáticamente en tu proyecto, como cuenta de servicio del nodo.
Interacción de gestión de identidades y accesos con el control de acceso basado en roles (RBAC) de Kubernetes
IAM y RBAC de Kubernetes trabajan conjuntamente para gestionar el acceso a tu clúster. RBAC controla el acceso a nivel de clúster y de espacio de nombres, mientras que IAM funciona a nivel de proyecto. Una entidad debe tener permisos suficientes en cualquiera de los niveles para trabajar con los recursos de tu clúster.
Siguientes pasos
- Consulta la descripción general de la seguridad de GKE.
- Consulta cómo usar el control de acceso basado en roles (RBAC) de Kubernetes.
- Consulta cómo crear políticas de gestión de identidades y accesos para GKE.
- Consulta cómo usar las condiciones de gestión de identidades y accesos en balanceadores de carga.