Autorización RBAC

Introducción

En Kubernetes, la autorización se gestiona normalmente mediante RBAC (control de acceso basado en roles).

• Usuario: un empleado, como «Jane».
• Role: una tarjeta de acceso con permisos específicos, por ejemplo, «Puede entrar en la sala de servidores» o «Puede leer documentos».
• RoleBinding: la acción de entregar la tarjeta de acceso al empleado.

RBAC es importante porque el acceso al clúster no depende únicamente de la autenticación. Una vez conocida la identidad, el sistema todavía debe decidir qué acciones puede realizar esa identidad.

En este laboratorio, usted asumirá el papel de responsable de seguridad:

• Cree un «pase de visitante» (Role) que permita observar los recursos, pero no modificarlos.
• Asigne este pase a un usuario llamado jane.
• Compruebe que Jane puede consultar el clúster, pero que se rechaza cualquier intento de cambiar algo.

Definir el Role

Primero debe crear el conjunto de permisos. Creará un rol de «solo lectura». Este rol permite ejecutar list y get para leer Pods, pero no permite crearlos ni eliminarlos mediante create o delete.

RBAC es el mecanismo de autorización de Kubernetes, no el de autenticación. La autenticación responde a «¿Quién es usted?». La autorización responde a «¿Qué puede hacer?». En este laboratorio trabajará con la segunda pregunta y definirá acciones permitidas explícitas, llamadas verbos, sobre tipos de recursos concretos.

Cree un archivo llamado role.yaml:

nano role.yaml

Pegue el siguiente YAML. Esta definición crea un Role que puede realizar las acciones get, watch y list sobre los pods.

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

Guarde el archivo y salga (Ctrl+X, Y, Enter).

Ahora, aplique esta tarjeta al clúster:

kubectl apply -f role.yaml

Compruebe que existe:

kubectl get roles

Debería ver pod-reader.

Vincular el Role

Ahora tiene la tarjeta (pod-reader) y el empleado (jane). Sin embargo, Jane todavía no tiene la tarjeta. Necesita un RoleBinding para conectarlos.

Un Role no concede ningún permiso por sí solo hasta que una vinculación hace referencia a él. Esta separación es intencionada. Permite que los administradores definan una vez conjuntos de permisos reutilizables y que después los asignen, según sea necesario, a distintos usuarios, grupos o cuentas de servicio.

Cree un archivo llamado rolebinding.yaml:

nano rolebinding.yaml

Pegue el siguiente contenido. Esto indica: «Vincule el rol pod-reader al usuario jane».

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
  - kind: User
    name: jane ## The employee
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader ## The key card
  apiGroup: rbac.authorization.k8s.io

Guarde el archivo y salga (Ctrl+X, Y, Enter).

Aplique la vinculación:

kubectl apply -f rolebinding.yaml

Ahora ha concedido oficialmente a Jane acceso de solo lectura al espacio de nombres default.

Verificar el acceso

¿Cómo puede probarlo? No necesita cerrar la sesión y volver a iniciarla como Jane. Kubernetes permite «suplantar» a un usuario para probar sus permisos mediante la opción --as.

Esta es una técnica práctica de administración. Las comprobaciones de permisos son mucho más seguras cuando puede simular una identidad antes de conceder acceso a un usuario real o a una cuenta de automatización. Así puede verificar que la configuración cumple su objetivo sin provocar efectos secundarios innecesarios en el clúster.

Compruebe que Jane puede listar los Pods:

kubectl auth can-i list pods --as jane

La salida debería ser yes.

También puede comprobar si puede obtener los detalles de un Pod específico:

kubectl auth can-i get pods --as jane

La salida también debería ser yes.

Esto confirma que el RoleBinding funciona. ¡La tarjeta de acceso permite pasar por los lectores de las puertas!

Verificar las restricciones

La seguridad también consiste en determinar lo que no se puede hacer. Como Jane solo tiene el rol pod-reader, debe tener estrictamente prohibido realizar cambios.

Este es el principio de mínimo privilegio en la práctica. En lugar de conceder un acceso amplio y esperar que los usuarios actúen con cuidado, comience con los permisos mínimos necesarios para la tarea y amplíelos únicamente cuando exista una necesidad operativa real.

Compruebe si Jane puede crear un Pod:

kubectl auth can-i create pods --as jane

La salida debería ser no.

Compruebe si Jane puede eliminar un Pod:

kubectl auth can-i delete pods --as jane

La salida debería ser no.

Si Jane intentara ejecutar realmente estos comandos, el servidor de API rechazaría su solicitud con un error «Forbidden». Esto confirma que el clúster está protegido y sigue el principio de mínimo privilegio.

Resumen

En este laboratorio ha protegido el clúster mediante RBAC.

Ha completado correctamente estas tareas:

1. Creó un Role («tarjeta de acceso») con permisos limitados de solo lectura.
2. Creó un RoleBinding para entregar esa tarjeta al usuario jane.
3. Comprobó que jane puede observar los recursos, pero no modificarlos.

Esta es la base de la seguridad para varios usuarios en Kubernetes. ¡Nunca conceda acceso de administrador completo a todo el mundo!