Control de acceso según la función

Esta página proporciona una descripción general del control de acceso basado en funciones en Google Kubernetes Engine.

Descripción general

El sistema de control de acceso basado en funciones (RBAC) de Kubernetes te permite ejercer un control preciso sobre cómo los usuarios acceden a los recursos API que se ejecutan en tu clúster. Puedes usar el RBAC para configurar de manera dinámica los permisos de los usuarios de tu clúster y definir los tipos de recursos con los que pueden interactuar.

Puedes crear permisos de RBAC que se apliquen a todo tu clúster o solo a espacios de nombres específicos dentro de tu clúster. Los permisos de todo el clúster son útiles para limitar el acceso de ciertos usuarios a recursos específicos de la API (como políticas de seguridad o secretos). Los permisos específicos del espacio de nombres son útiles si, por ejemplo, tienes varios grupos de usuarios que operan dentro de sus propios espacios de nombres respectivos. El RBAC puede ayudarte a garantizar que los usuarios solo tengan acceso a los recursos del clúster dentro de su propio espacio de nombres.

Antes de comenzar

Sigue estos pasos a fin de prepararte para esta tarea:

  • Asegúrate de habilitar la API de Google Kubernetes Engine.
  • Habilitar la API de Google Kubernetes Engine
  • Asegúrate de instalar el SDK de Cloud.
  • Configura el ID del proyecto predeterminado:
    gcloud config set project [PROJECT_ID]
  • Si trabajas con clústeres zonales, configura tu zona de procesamiento predeterminada:
    gcloud config set compute/zone [COMPUTE_ZONE]
  • Si trabajas con clústeres regionales, configura tu región de procesamiento predeterminada:
    gcloud config set compute/region [COMPUTE_REGION]
  • Actualiza gcloud a la versión más reciente:
    gcloud components update

Interacción con administración de identidades y accesos

GKE también usa la Administración de identidades y accesos (IAM) de Cloud para controlar el acceso a tu clúster. Sin embargo, Cloud IAM funciona por proyecto, es decir, los usuarios requieren permisos a nivel de proyecto para acceder a cualquier clúster en un proyecto de GCP determinado.

Los permisos de RBAC proporcionan un control más preciso sobre el acceso a los recursos dentro de cada clúster. Como tal, Cloud IAM y el RBAC pueden trabajar en conjunto, y un usuario debe tener permisos suficientes en cualquier nivel para trabajar con recursos en tu clúster.

Requisitos previos para usar el control de acceso basado en funciones

Debes otorgar a tu usuario la capacidad de crear funciones en Kubernetes ejecutando el siguiente comando. [USER_ACCOUNT] es la dirección de correo electrónico del usuario:

kubectl create clusterrolebinding cluster-admin-binding \
--clusterrole cluster-admin --user [USER_ACCOUNT]

Cómo configurar el control de acceso basado en funciones

Tú defines tus permisos de RBAC creando objetos del grupo de API rbac.authorization.k8s.io en tu clúster. Puedes crear los objetos con la interfaz de línea de comandos de kubectl o de manera programática.

Tendrás que crear dos tipos de objetos:

  1. Un objeto Role o ClusterRole que define qué tipos de recursos y operaciones se permiten para un conjunto de usuarios.
  2. Un RoleBinding o ClusterRoleBinding que asocia el Role (o ClusterRole) con uno o más usuarios específicos.

Los permisos de RBAC son puramente aditivos, no hay reglas de "denegación". Cuando estructures tus permisos de RBAC, debes pensar en términos de "otorgar" acceso a los usuarios a los recursos del clúster.

Definición de permisos en un Role

Tú defines los permisos dentro de un objeto de la API Role o ClusterRole de Kubernetes. Un Role otorga acceso a los recursos dentro de un solo espacio de nombres, mientras que un ClusterRole otorga acceso a los recursos en todo el clúster.

Dentro de tu objeto Role (o ClusterRole), tú defines los permisos como un conjunto de rules. Las rules determinan el espacio de nombres, el tipo de recurso y las operaciones permitidas para esa función. Por ejemplo, puedes crear un Role que otorga acceso de lectura (operaciones como get, watch y list) para todos los recursos pod en un espacio de nombres dado.

Role frente a ClusterRole

Debido a que los permisos de ClusterRole aplican en todo el clúster, puedes usarlos para controlar el acceso a diferentes tipos de recursos que con una Role, como los siguientes:

  • Recursos de alcance de clúster como los nodos
  • Extremos sin recurso, como /healthz
  • Recursos con espacio de nombres en todos los espacios de nombres (por ejemplo, todos los pods en todo el clúster, independientemente del espacio de nombres)

Cómo asignar permisos a usuarios con RoleBinding

Una vez que hayas creado el Role (o ClusterRole), debes crear un objeto RoleBinding (o ClusterRoleBinding) para otorgar los permisos en el Role (o ClusterRole) a un conjunto de usuarios. Los usuarios pueden ser usuarios individuales o cuentas de servicio de Kubernetes.

El RoleBinding (o ClusterRoleBinding) contiene una lista de los usuarios y una referencia de Role (o ClusterRole) que se otorga a esos usuarios.

Uso de API y ejemplos

Para obtener información completa sobre el uso de la API de Kubernetes a fin de crear los objetos Role, ClusterRole, RoleBinding y ClusterRoleBinding necesarios para el RBAC, consulta Autorización con el uso del control de acceso basado en funciones en la documentación de Kubernetes.

Advertencias:

Las siguientes secciones describen advertencias relacionadas con la asistencia de RBAC de Kubernetes.

Funciones de descubrimiento predeterminadas

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 todas las demás solicitudes entran en el system:unauthenticated. De manera predeterminada, system:authenticated y system:unauthenticated conceden los ClusterRoles system:basic-user y system:discovery. El system:basic-user ClusterRole permite a los usuarios realizar SelfSubjectAccessReviews para probar sus permisos en el clúster. La función system:discovery permite a los usuarios leer las API de descubrimiento, las cuales pueden revelar información acerca de las CustomResourceDefinitions agregadas al clúster.

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

kubectl get clusterroles system:discovery -o yaml

¿Qué sigue?

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...