Esta página proporciona una descripción general del sistema de control de acceso basado en funciones (RBAC) proporcionado por Kubernetes y cómo puedes usar Kubernetes RBAC en Google Kubernetes Engine.
Descripción general
Kubernetes incluye un mecanismo integrado de control de acceso basado en funciones (RBAC) que te permite configurar conjuntos de permisos precisos que definen cómo un usuario de GCP o grupo de usuarios determinados, pueden interactuar con cualquier objeto de Kubernetes en el clúster o en un espacio de nombres específico del clúster.
Kubernetes RBAC está habilitado de forma predeterminada.
Antes de comenzar
Sigue estos pasos a fin de prepararte para esta tarea:
- Asegúrate de que habilitaste la API de Google Kubernetes Engine. Habilitar la API de Google Kubernetes Engine
- Asegúrate de que instalaste el SDK de Cloud.
- Establece tu ID del proyecto predeterminado:
gcloud config set project [PROJECT_ID]
- Si trabajas con clústeres zonales, establece tu zona de procesamiento predeterminada:
gcloud config set compute/zone [COMPUTE_ZONE]
- Si trabajas con clústeres regionales, establece tu región de procesamiento predeterminada:
gcloud config set compute/region [COMPUTE_REGION]
- Actualiza
gclouda la versión más reciente:gcloud components update
Interacción con administración de identidades y accesos
Puedes usar Cloud Identity and Access Management y Kubernetes RBAC para controlar el acceso al clúster de GKE:
Cloud IAM no es específico de Kubernetes; proporciona administración de identidades para varios productos de Google Cloud Platform y funciona, en primer lugar, al nivel del proyecto de GCP.
Kubernetes RBAC es un componente central de Kubernetes y te permite crear y otorgar funciones (conjuntos de permisos) para cualquier objeto o tipo de objeto dentro del clúster.
En GKE, Cloud IAM y Kubernetes RBAC están integrados para autorizar a los usuarios a realizar acciones si tienen permisos suficientes de acuerdo con cualquiera de las dos herramientas. Esta es una parte importante de la inicialización de un clúster de GKE, ya que, de forma predeterminada, los usuarios de GCP no tienen ningún RoleBinding de Kubernetes RBAC.
A fin de autorizar a los usuarios que usan cuentas de GCP, el cliente debe estar configurado de forma correcta para autenticarse con esas cuentas. Por ejemplo, si usas kubectl, debes configurar el comandokubectl para autenticarte en Google Cloud Platform antes de ejecutar cualquier comando que requiera autorización.
Requisitos previos para usar Kubernetes RBAC en el clúster de GKE v1.11.x y versiones anteriores
En los clústeres de GKE que usan GKE v1.11.x y versiones anteriores, existe una limitación de que Cloud IAM no puede otorgar la capacidad de crear un Role o ClusterRole de Kubernetes RBAC. Sin embargo, la función de administrador de Kubernetes Engine de Cloud IAM otorga a los usuarios la capacidad de crear un RoleBinding o ClusterRoleBinding de Kubernetes RBAC para cualquier usuario, incluidos ellos mismos, que se puede usar a fin de vincular a los usuarios de GCP con las funciones predefinidas de RBAC.
En particular, la función cluster-admin predefinida de RBAC otorga a los usuarios permisos completos en el clúster. Por lo tanto, para iniciar un usuario y permitirle crear Roles y ClusterRoles de RBAC, emite el siguiente comando y reemplaza
kubectl create clusterrolebinding cluster-admin-binding \ --clusterrole cluster-admin \ --user[USER_ACCOUNT]
Grupos de Google para GKE
Antes, solo se podían otorgar funciones a cuentas de usuario de GCP o cuentas de servicio de Cloud IAM. Con Grupos de Google para GKE (Beta) puedes otorgar funciones a los miembros de un Grupo de Google de G Suite. Con este mecanismo, los administradores de G Suite mantienen los usuarios y grupos, fuera de Kubernetes o GCP Console en su totalidad por lo que los administradores del clúster no necesitan información detallada sobre tus usuarios. Otro beneficio es la integración con las prácticas de administración de cuentas de usuario existentes, como revocar el acceso cuando alguien abandona la organización.
Para usar esta función, configura tus Grupos de Google de G Suite, crea un clúster con la función habilitada y, luego, asocia esos Grupos de Google con conjuntos de permisos de clúster.
Configura Grupos de Google para usar con RBAC
La configuración de tu clúster a fin de usar esta función y la sintaxis para hacer referencia a un Grupo de Google de G Suite en Kubernetes RBAC se analizan más adelante en este tema. Primero, debes seguir los pasos a continuación para configurar tus Grupos de Google:
- Crea un Grupo de Google de G Suite en tu dominio, llamado
gke-security-groups@[yourdomain.com]. El nombre del grupo debe llamarsegke-security-groups. - Crea grupos, si aún no existen, que representen grupos de usuarios o grupos que deberían tener permisos diferentes en los clústeres.
- Agrega estos grupos (no usuarios) a la membresía de
gke-security-groups@[yourdomain.com].
A fin de verificar si un usuario tiene permiso para crear, modificar o ver un recurso en el clúster según la membresía del grupo, GKE verifica si es miembro de un grupo con acceso y si es miembro del grupo gke-security-groups del dominio.
La información sobre la membresía de Grupos de Google de G Suite se almacena en caché por un corto tiempo. Los cambios en las membresías de grupo pueden demorar unos minutos en propagarse a todos tus clústeres.
Configura tu clúster a fin de usar Grupos de Google para GKE
Después de que tu administrador de Grupos de Google de G Suite configure los grupos, crea un clúster nuevo con el comando gcloud y agrega la siguiente opción, que sustituye tu propio nombre de dominio: --security-group="gke-security-groups@[yourdomain.com]". El siguiente es un ejemplo de un comando de creación de clústeres:
gcloud beta container clusters create my-cluster \
--security-group="gke-security-groups@[yourdomain.com]"
Ahora estás listo para crear Roles, ClusterRoles, RoleBindings y ClusterRoleBindings que hagan referencia a tus Grupos de Google de G Suite.
Define y asigna permisos
Crea los siguientes tipos de objetos de Kubernetes para definir tus permisos RBAC:
- ClusterRole o Role: define un conjunto de tipos de recursos y operaciones que pueden asignarse a un usuario o grupo de usuarios en un clúster (ClusterRole) o un espacio de nombres (Role), pero no especifica el usuario o grupo de usuarios.
- ClusterRoleBinding o RoleBinding: asigna un ClusterRole o Role a un usuario o grupo de usuarios. Un ClusterRoleBinding funciona con un ClusterRole y un RoleBinding funciona con un ClusterRole o un Role.
Las funciones de RBAC son aditivas en su totalidad: no hay reglas de “denegación”. Cuando estructuras tus funciones de RBAC, debes pensar en términos de “otorgar” a los usuarios acceso a los recursos del clúster.
Define permisos con Roles o ClusterRoles
Debes definir permisos dentro de un objeto Role o ClusterRole. Un Role define el acceso a los recursos dentro de un único espacio de nombres, mientras que un ClusterRole define el acceso a los recursos en todo el clúster.
Los Roles y ClusterRoles tienen la misma sintaxis. Cada una tiene una sección rules, en la que se definen el espacio de nombres, el tipo de recurso y las operaciones permitidas relevantes para el Role. Por ejemplo, el siguiente Role otorga acceso de lectura (get, watch y list) para todos los pods en el espacio de nombres accounting:
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: accounting
name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods"]
verbs: ["get", "watch", "list"]
Role vs. ClusterRole
Debido a que los permisos otorgados por un ClusterRole se aplican a todo el clúster, puedes usar ClusterRoles para controlar el acceso a diferentes tipos de recursos de los que puedes con Roles. Estos incluyen los siguientes:
- Recursos de alcance de clúster, como los nodos
- Extremos que no son de recursos, como
/healthz - Recursos con espacio de nombres en todos los espacios de nombres (por ejemplo, todos los pods en todo el clúster, sin importar el espacio de nombres)
Asigna Roles mediante RoleBindings o ClusterRoleBindings
Después de crear un Role o ClusterRole, se lo asigna a un usuario o grupo de usuarios mediante un RoleBinding o ClusterRoleBinding. Los usuarios y los grupos se llaman subjects y pueden ser cualquiera de los siguientes:
| Tipo de asunto | Valor de kind |
Valor de name |
|---|---|---|
| Cuenta de usuario de GCP | User |
Dirección de correo electrónico de GCP registrada |
| Cuenta de servicio de Kubernetes | ServiceAccount |
El nombre de un objeto ServiceAccount de Kubernetes en el clúster |
| Cuenta de servicio de Cloud IAM | User |
Dirección de correo electrónico de la cuenta de servicio de Cloud IAM generada de forma automática |
| Dirección del Grupo de Google de G Suite (Beta) en un dominio verificado | Group |
Dirección de correo electrónico de un Grupo de Google que es miembro del Grupo de Google gke-security-groups@[yourdomain.com] |
El siguiente RoleBinding otorga el Role pod-reader a un usuario, una cuenta de servicio de Kubernetes, una cuenta de servicio de Cloud IAM y un Grupo de Google:
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: pod-reader-binding
namespace: accounting
subjects:
# GCP user account
- kind: User
name: janedoe@example.com
# Kubernetes service account
- kind: ServiceAccount
name: johndoe
# Cloud IAM service account
- kind: User
name: test-account@test-project-123456.google.com.iam.gserviceaccount.com
# G Suite Google Group
- kind: Group
name: accounting-group@example.com
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
Uso de API y ejemplos
Para obtener información completa sobre cómo usar la API de Kubernetes a fin de crear los objetos Role, ClusterRole, RoleBinding, y ClusterRoleBinding necesarios para RBAC, consulta la página sobre cómo usar la autorización con control de acceso basado en funciones en la documentación de Kubernetes.
Advertencias
En las siguientes secciones, se describen interacciones que pueden no parecer obvias cuando se trabaja con Kubernetes RBAC.
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 corresponden a system:unauthenticated.
Antes de la versión 1.14 de Kubernetes, tanto system:authenticated como system:unauthenticated otorgan los ClusterRoles system:basic-user y system:discovery de manera predeterminada.
El ClusterRole system:basic-user permite a los usuarios hacer SelfSubjectAccessReviews para probar sus permisos en el clúster. La función system:discovery permite a los usuarios leer las API de detección, que pueden revelar información sobre CustomResourceDefinitions agregada al clúster.
A partir de Kubernetes 1.14, los usuarios anónimos (system:unauthenticated) recibirán el ClusterRole system:basic-info-viewer, que otorga acceso de solo lectura a las API de /healthz y /version.
Para ver los extremos de API permitidos por el ClusterRole system:discovery, ejecuta el siguiente comando:
kubectl get clusterroles system:discovery -o yaml
Error prohibido para cuentas de servicio en instancias de VM de GCP
Este error puede ocurrir cuando la instancia de VM no tiene el alcance userinfo-email. Por ejemplo, supongamos que la VM tiene el alcance cloud-platform, pero no tiene el alcance userinfo-email. Cuando la VM obtiene un token de acceso, Google Cloud Platform asocia ese token con el alcance cloud-platform. Cuando el servidor de la API de Kubernetes solicita a GCP la identidad asociada con el token de acceso, recibe el ID único de la cuenta de servicio, no el correo electrónico de la cuenta de servicio.
Para autenticarte de forma correcta, crea una VM nueva con el alcance userinfo-email o crea una nueva vinculación de función que use el ID único.
Para crear una VM nueva con el alcance userinfo-email, ejecuta el siguiente comando:
gcloud compute instances create [INSTANCE_NAME] \
--service-account [SERVICE_ACCOUNT_EMAIL] \
--scopes userinfo-email
A fin de crear una nueva vinculación de función que use el ID único de la cuenta de servicio para una VM existente, realiza los siguientes pasos:
Identifica el ID único de la cuenta de servicio:
gcloud iam service-accounts describe [SERVICE_ACCOUNT_EMAIL]
Crea una vinculación de función con el ID único:
kubectl create clusterrolebinding [CLUSTERROLEBINDING_NAME] \ --clusterrole cluster-admin \ --user [UNIQUE_ID]
