Control de acceso

En este documento, se describen las diferencias entre Identity and Access Management (IAM) y el control de acceso basado en roles (RBAC) de Kubernetes en Google Kubernetes Engine para ayudarte a administrar el acceso a los recursos de tu proyecto. En este documento, se supone que conoces los siguientes temas:

Este documento está dirigido a los especialistas en seguridad que controlan el acceso a los permisos y desean comprender las diferencias y la superposición entre IAM y RBAC. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido deGoogle Cloud , consulta Roles y tareas comunes de los usuarios de GKE.

Administra el acceso a los recursos de GKE

Cuando creas un proyecto Google Cloud , eres el único usuario en el 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 administrar el acceso a los recursos de tu proyecto y sus clústeres mediante el control de acceso según el rol (RBAC).

Estos mecanismos se superponen en cuanto a sus funciones en cierto punto, pero están dirigidos a diferentes tipos de recursos. Cada uno se explica de forma breve en una sección dedicada de esta página:

  • El RBAC de Kubernetes está incorporado en Kubernetes y otorga permisos detallados a los objetos dentro de los clústeres de Kubernetes. Los permisos existen como objetos Role o ClusterRole dentro del clúster. Los objetos RoleBinding otorgan roles a usuarios de Kubernetes, Google Cloud usuarios, cuentas de servicio de IAM o Grupos de Google.

    Si usas GKE y necesitas permisos específicos para cada objeto y operación dentro de tu clúster, el RBAC de Kubernetes es la mejor opción.

  • IAM administra Google Cloud recursos, incluidos los clústeres y los tipos de objetos dentro de los clústeres. Los permisos se asignan a las principales de IAM.

    No existe un mecanismo con el que se otorguen permisos para objetos de Kubernetes específicos dentro de IAM. Por ejemplo, puedes otorgar a un usuario permiso para crear CustomResourceDefinitions (CRD), pero no puedes otorgarle permiso a fin de crear solo una CustomResourceDefinition específica, ni limitar la creación a un espacio de nombres específico o a un clúster específico en el proyecto. Una función de IAM otorga privilegios en todos los clústeres del proyecto o en todos los clústeres de todos los proyectos secundarios si la función se aplica a nivel de carpeta.

    Si usas varios componentes de Google Cloud y no necesitas administrar permisos específicos detallados de Kubernetes, IAM es una buena opción.

RBAC de Kubernetes

Kubernetes cuenta con compatibilidad integrada para RBAC. Esto te permite crear roles detallados, que existen dentro del clúster de Kubernetes. Una función puede aplicarse a un objeto de Kubernetes específico o a un tipo de objeto de Kubernetes, y define qué acciones (llamadas verbos) otorga la función en relación con ese objeto. Un RoleBinding también es un objeto de Kubernetes y otorga funciones a los usuarios. Un usuario de GKE puede ser cualquiera de las siguientes opciones:

  • Google Cloud user
  • Cuenta de servicio de IAM
  • Cuenta de servicio 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 Control de acceso según la función.

IAM

IAM te permite otorgar roles a principales. Un rol es una colección de permisos y, cuando se le otorga a una principal, le permite acceder a uno o más Google Cloud recursos. Para obtener más información sobre los principales, los roles y otros términos de IAM, consulta la Descripción general de IAM.

En GKE, una principal puede ser cualquiera de las siguientes opciones:

  • 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 Crea políticas de permiso de IAM.

Tipos de políticas de IAM

IAM admite los siguientes tipos de políticas:

  • Políticas de permisos: Otorga roles a las principales. Para obtener más información, consulta Política de permisos.
  • Políticas de denegación: Evita que las principales usen permisos de IAM específicos, sin importar las funciones que se les otorguen. Para obtener más detalles, consulta Políticas de denegación.

Usa políticas de denegación para evitar que principales específicas realicen acciones específicas en tu proyecto, organización o carpeta, incluso si una política de permisos de IAM otorga a esas principales un rol que contenga los permisos relevantes.

Recomendaciones de IAM

Considera usar las siguientes funciones predefinidas de IAM para facilitar situaciones comunes:

Para obtener una lista de los roles predefinidos de IAM disponibles, consulta Roles predefinidos de GKE.

GKE usa cuentas de servicio de IAM que se adjuntan a tus nodos para ejecutar tareas del sistema, como el registro y la supervisión. Como mínimo, estas cuentas de servicio de nodo deben tener el rol de cuenta de servicio de nodo predeterminado 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 la cuenta de servicio del nodo.

Interacción de IAM con RBAC de Kubernetes

IAM y RBAC de Kubernetes trabajan juntos para ayudar a administrar el acceso a tu clúster. RBAC controla el acceso en el nivel de clúster y espacio de nombres, mientras que IAM funciona en el nivel de proyecto. Una entidad debe tener permisos suficientes en cualquier nivel para trabajar con recursos en tu clúster.

¿Qué sigue?