Autorizar acciones en clústeres mediante el control de acceso basado en roles

En esta página se explica cómo autorizar acciones en los recursos de tus clústeres de Google Kubernetes Engine (GKE) mediante el mecanismo de control de acceso basado en roles (RBAC) integrado en Kubernetes. El control de acceso basado en roles de Kubernetes está habilitado de forma predeterminada, lo que te permite controlar el acceso al clúster de forma pormenorizada.

Aprenderás a definir y asignar permisos precisos, crear roles y enlaces de roles para gestionar el acceso de los usuarios, verificar el acceso a la API para comprobar el nivel de acceso, solucionar problemas habituales y comprender las limitaciones al trabajar con RBAC en GKE.

Esta página está dirigida a especialistas en seguridad y operadores que quieran usar RBAC para mejorar la seguridad de sus clústeres de GKE. 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

Antes de leer esta página, asegúrese de que conoce los siguientes conceptos:

Antes de empezar

Antes de empezar, asegúrate de haber realizado las siguientes tareas:

  • Habilita la API de Google Kubernetes Engine.
    • Habilitar la API de Google Kubernetes Engine
  • Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la gcloud CLI, obtén la versión más reciente ejecutando gcloud components update.

Interactuar con la gestión de identidades y accesos

Puedes usar tanto Gestión de Identidades y Accesos (IAM) como el control de acceso basado en roles (RBAC) de Kubernetes para controlar el acceso a tu clúster de GKE:

  • Gestión de identidades y accesos no es específico de Kubernetes, sino que proporciona gestión de identidades para varios Google Cloud productos y opera principalmente a nivel de Google Cloud proyecto.

  • El control de acceso basado en roles de Kubernetes es un componente principal de Kubernetes que te permite crear y asignar roles (conjuntos de permisos) a cualquier objeto o tipo de objeto dentro del clúster.

  • Para autorizar una acción, GKE comprueba primero si hay una política de RBAC. Si no hay una política de RBAC, GKE comprueba los permisos de gestión de identidades y accesos.

En GKE, IAM y RBAC de Kubernetes están integrados para autorizar a los usuarios a realizar acciones si tienen permisos suficientes según cualquiera de las dos herramientas. Se trata de una parte importante del proceso de arranque de un clúster de GKE, ya que, de forma predeterminada, Google Cloud los usuarios no tienen ningún RoleBinding de RBAC de Kubernetes.

Para autorizar a los usuarios con cuentas de Google Cloud , el cliente debe configurarse correctamente para autenticarse con esas cuentas. Por ejemplo, si usas kubectl, debes configurar el comando kubectl para autenticarte en Google Cloud antes de ejecutar cualquier comando que requiera autorización.

En casi todos los casos, se puede usar el control de acceso basado en roles de Kubernetes en lugar de IAM. Los usuarios de GKE necesitan, como mínimo, el permiso container.clusters.get de gestión de identidades y accesos en el proyecto que contiene el clúster. Este permiso se incluye en el rol container.clusterViewer y en otros roles con mayores privilegios. El permiso container.clusters.get es necesario para que los usuarios se autentiquen en los clústeres del proyecto, pero no les autoriza a realizar ninguna acción en esos clústeres. La autorización se puede proporcionar mediante la gestión de identidades y accesos o el control de acceso basado en roles de Kubernetes.

Definir y asignar permisos

Puedes definir reglas de control de acceso basado en roles en objetos ClusterRole y Role, y luego asignar esas reglas con objetos ClusterRoleBinding y RoleBinding de la siguiente manera:

  • ClusterRole una agrupación de recursos y operaciones permitidas a nivel de clúster que puedes asignar a un usuario o a un grupo mediante un RoleBinding o un ClusterRoleBinding.
  • Rol: una agrupación de recursos y operaciones permitidas en un espacio de nombres que puedes asignar a un usuario o a un grupo de usuarios mediante un RoleBinding.
  • ClusterRoleBinding asigna un ClusterRole a un usuario o a un grupo en todos los espacios de nombres del clúster.
  • RoleBinding asigna un Role o un ClusterRole a un usuario o un grupo dentro de un espacio de nombres específico.

Cuando usas un RoleBinding para asignar un ClusterRole a un usuario o un grupo, esos usuarios y grupos solo pueden acceder a los recursos del espacio de nombres que especifiques en el RoleBinding. Si quieres que los usuarios o grupos accedan a los recursos de todos los espacios de nombres, usa un ClusterRoleBinding.

Definir permisos con Roles o ClusterRoles

Los permisos se definen en un objeto Role o ClusterRole. Un rol define el acceso a los recursos de un solo espacio de nombres, mientras que un rol de clúster define el acceso a los recursos de todo el clúster.

Los roles y los ClusterRoles tienen la misma sintaxis. Cada uno tiene una sección rules, donde se definen los recursos a los que se aplica la regla y las operaciones permitidas para el rol. Por ejemplo, el siguiente rol concede acceso de lectura (get, watch y list) a todos los pods del espacio de nombres accounting:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: accounting
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Consulta la documentación de la API Role y ClusterRole para ver una lista completa de los campos permitidos.

Role frente a ClusterRole

Como los permisos concedidos por un ClusterRole se aplican en todo el clúster, puedes usar ClusterRoles para controlar el acceso a diferentes tipos de recursos que con Roles. Por ejemplo:

  • Recursos con permisos de clúster, como los nodos
  • Puntos finales REST que no son recursos, como /healthz
  • Recursos con permisos de espacio de nombres en todos los espacios de nombres (por ejemplo, todos los pods de todo el clúster, independientemente del espacio de nombres)

Asignar roles mediante RoleBindings o ClusterRoleBindings

Después de crear un Role o un ClusterRole, puedes asignarlo a un usuario o a un grupo de usuarios creando un RoleBinding o un ClusterRoleBinding. Los usuarios y los grupos se denominan subjects y pueden ser cualquiera de los siguientes:

Tipo de asunto Valor de kind Valor de name
Google Cloud Cuenta de usuario User Google Cloud Dirección de correo registrada
Cuenta de servicio de Kubernetes ServiceAccount Nombre de un objeto ServiceAccount de Kubernetes en el clúster
Cuenta de servicio de gestión de identidades y accesos User Dirección de correo de cuenta de servicio de gestión de identidades y accesos generada automáticamente
Dirección de grupo de Google en un dominio verificado Group Dirección de correo de un grupo de Google Workspace que sea miembro del grupo gke-security-groups. Para obtener instrucciones sobre cómo configurar Grupos de Google para el control de acceso basado en roles, consulta el artículo Configurar Grupos de Google para el control de acceso basado en roles.

El siguiente RoleBinding concede el rol pod-reader a un usuario, una cuenta de servicio de Kubernetes, una cuenta de servicio de IAM y un grupo de Google:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: pod-reader-binding
  namespace: accounting
subjects:
# Google Cloud user account
- kind: User
  name: janedoe@example.com
# Kubernetes service account
- kind: ServiceAccount
  name: johndoe
# IAM service account
- kind: User
  name: test-account@test-project.iam.gserviceaccount.com
# Google Group
- kind: Group
  name: accounting-group@example.com
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Verificar el acceso a la API mediante kubectl

kubectl proporciona el subcomando auth can-i para consultar rápidamente la capa de autorización de la API. Como administrador de la plataforma, es posible que tengas que suplantar la identidad de los usuarios para determinar qué acciones pueden realizar. Puedes usar auth can-i y pasar una marca --as adicional.

Cuando ejecutas el comando kubectl auth can-i sin la marca --as, Gestión de Identidades y Accesos (IAM) realiza la autorización. En cambio, si añades la marca --as, el control de acceso basado en roles de Kubernetes realiza la autorización. Por lo tanto, tendrás que crear los objetos Role y RoleBinding necesarios para el control de acceso basado en roles.

Para obtener más información, consulta Verificar el acceso a la API.

Uso de la API y ejemplos

Para obtener información completa sobre cómo usar la API de Kubernetes para crear los objetos Role, ClusterRole, RoleBinding y ClusterRoleBinding necesarios para el control de acceso basado en roles, consulta el artículo Using Role-Based Access Control Authorization (Usar la autorización de control de acceso basado en roles) de la documentación de Kubernetes.

Solucionar problemas de RBAC

Para depurar problemas con el control de acceso basado en roles, usa el registro de auditoría de actividad de administración, que está habilitado en todos los clústeres de forma predeterminada. Si se deniega el acceso a un recurso o a una operación por falta de permisos suficientes, el servidor de la API registra un error RBAC DENY junto con información adicional, como la pertenencia implícita y explícita del usuario a un grupo. Si usas Grupos de Google para el control de acceso basado en roles, google groups aparecerá en el mensaje de registro.

Limitaciones

En las siguientes secciones se describen interacciones que pueden no parecer obvias al trabajar con el control de acceso basado en roles (RBAC) de Kubernetes y con IAM.

Roles de Discovery predeterminados

Los clústeres se crean con un conjunto de ClusterRoles y ClusterRoleBindings predeterminados. Las solicitudes realizadas con credenciales válidas se colocan en el grupo system:authenticated, mientras que el resto se incluyen en system:unauthenticated.

El system:basic-user ClusterRole permite a los usuarios hacer SelfSubjectAccessReviews para probar sus permisos en el clúster. El rol system:discovery permite a los usuarios leer APIs de descubrimiento, que pueden revelar información sobre CustomResourceDefinitions añadidos al clúster.

Los usuarios anónimos (system:unauthenticated) reciben el ClusterRole system:public-info-viewer, que otorga acceso de solo lectura a las APIs /healthz y /version.

Para ver los endpoints de API permitidos por el ClusterRole system:discovery, ejecuta el siguiente comando:

kubectl get clusterroles system:discovery -o yaml

Error Forbidden en cuentas de servicio de instancias de máquina virtual de Google Cloud

Se puede producir el siguiente error cuando la instancia de VM no tiene el ámbito userinfo-email:

Error from server (Forbidden): error when creating ... "role-name" is forbidden: attempt to grant extra privileges:...

Por ejemplo, supongamos que la VM tiene el ámbito cloud-platform, pero no el ámbito userinfo-email. Cuando la VM obtiene un token de acceso, Google Cloud asocia ese token con el ámbito cloud-platform. Cuando el servidor de la API de Kubernetes pide Google Cloud la identidad asociada al token de acceso, recibe el ID único de la cuenta de servicio, no su correo.

Para autenticarte correctamente, crea una máquina virtual con el userinfo-email ámbito o crea un nuevo enlace de rol que use el ID único.

Para crear una instancia de VM con el ámbito userinfo-email, ejecuta el siguiente comando:

gcloud compute instances create INSTANCE_NAME \
    --service-account SERVICE_ACCOUNT_EMAIL \
    --scopes userinfo-email

Para crear un enlace de rol que use el ID único de la cuenta de servicio en una VM, sigue estos pasos:

  1. Identifica el ID único de la cuenta de servicio:

    gcloud iam service-accounts describe SERVICE_ACCOUNT_EMAIL

    Por ejemplo, el siguiente resultado muestra el uniqueId de la cuenta de servicio my-iam-account@somedomain.com:

    displayName: Some Domain IAM service account
email: my-iam-account@somedomain.com
etag: BwWWja0YfJA
name: projects/project-name/serviceAccounts/my-iam-account@somedomain.com
oauth2ClientId: '123456789012345678901'
projectId: project-name
uniqueId: '123456789012345678901'

  2. Crea un enlace de rol con el uniqueId de la cuenta de servicio:

    kubectl create clusterrolebinding CLUSTERROLEBINDING_NAME \
    --clusterrole cluster-admin \
    --user UNIQUE_ID

Permiso para crear o actualizar roles y enlaces de roles

En Kubernetes, solo puedes crear o actualizar un rol o un enlace de rol con permisos específicos si cumples las siguientes condiciones:

  • Crear o actualizar un rol: debes tener los mismos permisos que quieras conceder al rol. También puedes tener autorización para realizar el verbo escalate en el rol.
  • Crear o actualizar una vinculación de rol: debes tener los mismos permisos que se conceden en el rol que se va a vincular, con el mismo ámbito que la vinculación de rol. También debes tener autorización para realizar el verbo bind en el rol al que se hace referencia.

Si los permisos que estás concediendo en el rol se te concedieron originalmente mediante una política de permiso de gestión de identidades y accesos en lugar de mediante el control de acceso basado en roles, es posible que tu solicitud de rol o de enlace de rol falle. Por ejemplo, considera la siguiente solicitud de creación de un rol, realizada por un usuario al que se le han concedido los permisos de gestión de identidades y accesos container.pods.* y container.roles.create:

kubectl create role allowed-to-view-pods --resource pods --verb list,get

Si solo se han concedido los permisos al usuario mediante IAM, puede producirse el siguiente error:

Error from server (Forbidden): clusterroles.rbac.authorization.k8s.io "allowed-to-view-pods" is forbidden:
user "caller@example.com" (groups=["system:authenticated"]) is attempting to grant RBAC permissions not currently held:
{APIGroups:[""], Resources:["pods"], Verbs:["list" "get"]}

Para mitigar esta limitación, concede al llamador los permisos del rol mediante el control de acceso basado en roles en lugar de la gestión de identidades y accesos.

También puedes usar RBAC o IAM para conceder al llamante el verbo escalate, el verbo bind o ambos. Sin embargo, GKE no recomienda este enfoque, ya que el llamante puede conceder cualquier permiso a cualquier rol.

Siguientes pasos