RBAC en Kubernetes: el control de acceso basado en roles explicado

Si ejecutas cualquier cosa en Kubernetes, el RBAC en Kubernetes es el control que decide quién puede leer tus Secrets, borrar tus pods o, en silencio, concederse a sí mismo las llaves de todo el cluster. El Role-Based Access Control (control de acceso basado en roles) es el sistema de autorización de Kubernetes que asigna subjects — usuarios, grupos y ServiceAccounts — a las acciones específicas que tienen permitido realizar sobre resources específicos. Acértalo y un workload comprometido queda encerrado en su namespace. Fállalo y un único token filtrado se convierte en una brecha en todo el cluster. Este análisis a fondo recorre cómo funciona realmente el RBAC, dónde se queman los equipos y cómo aplicar el control de acceso basado en roles en Kubernetes con el mínimo privilegio como opción por defecto. Forma parte de nuestra guía más amplia de seguridad en Kubernetes.

Qué es el RBAC y por qué importa en Kubernetes

Cada solicitud que llega al API server de Kubernetes — ya venga de una persona ejecutando kubectl, de un controller o de un pod que habla con la API — pasa por tres puertas: autenticación (¿quién eres?), autorización (¿tienes permiso para esto?) y admission control (¿debe aceptarse este objeto en concreto?). El RBAC es el mecanismo de autorización más utilizado para la puerta del medio.

Lo que hace que el RBAC importe tanto es el radio de impacto que hay detrás. La API de Kubernetes es el control plane de todo: workloads, Secrets, política de red, configuración de node. Un subject con suficiente poder de API puede leer todas las credenciales del cluster, lanzar pods privilegiados o alcanzar los nodes subyacentes. El RBAC es la frontera que mantiene acotado un trabajo acotado. Cuando es demasiado permisivo, se convierte en la ruta más corta desde un punto de apoyo hasta el compromiso total, que es exactamente por lo que los atacantes lo enumeran temprano.

El RBAC ha sido el modo de autorización por defecto en Kubernetes durante años, y está habilitado en prácticamente toda distribución gestionada o self-hosted que vayas a encontrar. La pregunta casi nunca es si lo usas, sino con cuánto cuidado.

Objetos centrales: Roles, bindings, ServiceAccounts y subjects

El RBAC se construye a partir de cuatro objetos de la API, más las identidades a las que se aplican. El modelo mental es simple una vez que encaja: dos objetos dicen qué está permitido, dos objetos dicen quién lo recibe.

Los Roles y ClusterRoles definen un conjunto de permisos. Son puramente aditivos: un Role es solo una lista de cosas permitidas, sin ningún concepto de denegación.

• Un Role está acotado a un namespace. Sus permisos se aplican solo dentro del único namespace en el que vive.
• Un ClusterRole tiene alcance de cluster. Puede conceder acceso a resources de todo el cluster (nodes, PersistentVolumes), a endpoints que no son resources (como /healthz) o a resources con namespace en todos los namespaces.

Aquí tienes un Role mínimo que permite leer pods en un solo namespace:

apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

  namespace: team-payments

  name: pod-reader

rules:

- apiGroups: [""] # "" is the core API group

  resources: ["pods"]

  verbs: ["get", "list", "watch"]

Los RoleBindings y ClusterRoleBindings vinculan un Role o ClusterRole a un conjunto de subjects.

• Un RoleBinding concede permisos dentro de un namespace específico. Puede referenciar un Role de ese namespace o —de manera útil— un ClusterRole, en cuyo caso las reglas del ClusterRole se aplican solo dentro del namespace del binding.
• Un ClusterRoleBinding concede permisos en todo el cluster. Este es el objeto que hay que tratar con mayor desconfianza, porque elimina por completo las fronteras de namespace.

apiVersion: rbac.authorization.k8s.io/v1

kind: RoleBinding

metadata:

  name: read-pods

  namespace: team-payments

subjects:

- kind: ServiceAccount

  name: reporting

  namespace: team-payments

roleRef:

  kind: Role

  name: pod-reader

  apiGroup: rbac.authorization.k8s.io

Los subjects son las identidades en el extremo receptor. Kubernetes reconoce tres tipos:

• Users y Groups — identidades humanas o externas. Kubernetes no tiene una base de datos de usuarios propia; estas identidades provienen de tu capa de autenticación (certificados, OIDC, etc.), y el RBAC simplemente las referencia por su nombre.
• ServiceAccounts — identidades internas del cluster pensadas para los workloads. Todo pod se ejecuta como un ServiceAccount, y esa cuenta es la forma en que el pod se autentica ante el API server. Los ServiceAccounts son las identidades que acotarás con más frecuencia, porque representan tu código en ejecución.

Un patrón común y potente es definir conjuntos de permisos amplios y reutilizables como ClusterRoles, y luego repartirlos de forma acotada con RoleBindings por namespace. Eso mantiene la definición DRY sin dejar de mantener la concesión ajustada.

Verbs y resources: la gramática de una regla

Cada regla de un Role o ClusterRole responde tres preguntas: qué API group, qué resources y qué verbs.

Los resources son los tipos de objeto: pods, deployments, secrets, configmaps, etc. Puedes acotar aún más a subresources como pods/log o pods/exec, e incluso a nombres de objeto específicos con resourceNames.

Los verbs son las acciones. Los comunes son get, list, watch, create, update, patch y delete (además de deletecollection). Vale la pena interiorizar que no todos son iguales:

• list y watch devuelven el contenido de los objetos, no solo los nombres. Conceder list sobre Secrets otorga en la práctica acceso de lectura a todos los Secrets dentro del alcance, una sorpresa frecuente.
• create sobre pods, combinado con el namespace adecuado, puede bastar para ejecutar código arbitrario en el cluster.
• pods/exec y pods/attach permiten que un subject abra una shell dentro de contenedores en ejecución.

Los comodines (*) se aceptan para apiGroups, resources y verbs, y son la mayor fuente individual de exceso accidental de permisos. verbs: ["*"] sobre resources: ["*"] es cluster-admin en todo salvo en el nombre.

Cómo se evalúa la autorización: aditiva y deny-by-default

Dos reglas rigen cómo Kubernetes convierte tus bindings en una decisión de sí o no, y ambas importan para razonar sobre la seguridad.

Primero, el RBAC es deny-by-default. Si ninguna regla permite explícitamente una solicitud, se deniega. Un ServiceAccount recién creado no puede hacer esencialmente nada hasta que le vinculas un role.

Segundo, el RBAC es puramente aditivo: no hay reglas de denegación. Cuando llega una solicitud, el autorizador comprueba si algún Role o ClusterRole vinculado al subject la permite. Si alguno lo hace, la solicitud se permite; los demás son irrelevantes. No puedes escribir una regla que diga "permitir todo excepto borrar Secrets". La única forma de retener un permiso es no concederlo nunca de entrada.

La consecuencia práctica: no puedes parchear una concesión demasiado amplia con una denegación puntual. Si un subject termina con demasiado poder, tienes que encontrar y corregir el binding que se lo dio. Por eso los bindings dispersos y superpuestos son peligrosos: los permisos efectivos de un subject son la unión de todo lo que tiene vinculado, y es fácil perder de vista esa unión.

El mínimo privilegio en la práctica

El mínimo privilegio es toda la razón de ser del RBAC, y en Kubernetes se reduce a unos pocos hábitos concretos.

Acota a namespaces por defecto. Prefiere Roles y RoleBindings antes que sus primos con alcance de cluster. La mayoría de los workloads y de los equipos operan dentro de un solo namespace; rara vez hay motivo para conceder alcance en todo el cluster. Reserva los ClusterRoleBindings para cuestiones genuinamente de todo el cluster (un agente de monitoreo que deba leer todos los nodes, por ejemplo) y revisa cada uno deliberadamente.

Evita los comodines. Nombra los resources y verbs específicos que necesitas. ["get", "list", "watch"] sobre ["configmaps"] le dice a un revisor —y a un scanner— exactamente qué hace un role. ["*"] no les dice nada y oculta la expansión futura del alcance.

Nunca repartas `cluster-admin` a la ligera. El ClusterRole incorporado cluster-admin es acceso irrestricto a todo. Vincularlo a una persona "para desbloquearla", o a un workload "para hacer que el error desaparezca", es la forma más común en que los clusters terminan de par en par. Si alguien realmente lo necesita, concédelo de forma acotada y temporal en lugar de mediante un ClusterRoleBinding permanente.

Ajusta el tamaño, no reutilices a ciegas. Los ClusterRoles incorporados admin, edit y view son cómodos, pero edit y admin son más amplios de lo que muchos equipos suponen: incluyen acceso a los Secrets de su namespace. Lee qué estás vinculando antes de vincularlo.

Para el lado del mínimo privilegio orientado al workload —descartar capabilities, ejecutar como non-root e imponer Pod Security Standards— consulta nuestra guía complementaria de seguridad de pods en Kubernetes.

Higiene de ServiceAccount

Los ServiceAccounts son donde el RBAC se encuentra con tus workloads en ejecución, y unos cuantos valores por defecto merecen atención.

No te apoyes en el ServiceAccount `default`. Todo namespace incluye uno llamado default, y cualquier pod que no especifique un ServiceAccount se ejecuta como él. Como es compartido, cualquier permiso que concedas a default se filtra a todos los workloads sin etiquetar de ese namespace. Déjalo sin bindings y dale a cada workload su propia cuenta.

Dale a cada workload su propio ServiceAccount. Las cuentas por workload te permiten acotar los permisos exactamente a lo que ese único servicio necesita, y hacen que los registros de auditoría sean significativos: puedes saber qué workload hizo qué llamada a la API.

apiVersion: v1

kind: ServiceAccount

metadata:

  name: reporting

  namespace: team-payments

automountServiceAccountToken: false

Desactiva el automontaje de tokens donde no haga falta. Por defecto, Kubernetes monta un token de ServiceAccount en cada pod, en una ruta bien conocida. Si el workload nunca habla con el API server, ese token es pura superficie de ataque: quien comprometa el contenedor obtiene gratis una credencial válida del cluster. Configura automountServiceAccountToken: false en el ServiceAccount o en el pod spec, a menos que el workload realmente necesite acceso a la API. Gestionar los tokens y otras credenciales que esos workloads sí necesitan es un tema aparte: consulta gestión de secrets en Kubernetes.

Errores de configuración comunes y rutas de escalamiento

Los atacantes no necesitan un cluster de par en par; necesitan un subject con permisos excesivos al que puedan llegar. Estos son los patrones que vale la pena buscar.

Bindings a `cluster-admin` u otros ClusterRoles amplios. Cualquier ClusterRoleBinding a cluster-admin es un punto único de compromiso total. Enuméralos y justifica cada uno.

Los verbs `escalate` y `bind`. Normalmente Kubernetes te impide crear un role con más permisos de los que ya posees; de lo contrario el RBAC sería trivial de eludir. El verb escalate elimina esa protección para Roles/ClusterRoles, y bind la elimina para los bindings. Un subject que puede hacer bind y referenciar cluster-admin puede promoverse a admin, aunque haya empezado casi sin nada. Trata cualquier concesión de estos verbs como equivalente a conceder aquello que desbloquean.

El verb `impersonate`. Permite que un subject actúe como otro usuario, grupo o ServiceAccount. Un subject que puede suplantar a system:masters o a un cluster-admin es un cluster-admin. La suplantación tiene usos legítimos, pero debe ser poco frecuente y estar rigurosamente acotada.

Acceso amplio a Secrets. get, list o watch sobre Secrets es acceso de lectura a credenciales, tokens y claves TLS. Combinado con un token de ServiceAccount montado, suele ser el pivote de un workload hacia muchos. Acota el acceso a Secrets a Secrets nombrados con resourceNames siempre que puedas.

`create` sobre pods más un ServiceAccount privilegiado. Si un subject puede crear pods en un namespace y establecer el ServiceAccount del pod, puede lanzar un pod que se ejecute como una cuenta más privilegiada, convirtiendo un permiso modesto en todo el poder de esa cuenta.

Auditar y revisar el RBAC

El desvío (drift) del RBAC es inevitable: los roles se agregan bajo presión de plazos y rara vez se eliminan. La revisión periódica es el contrapeso.

Pregúntale a la API qué puede hacer un subject. kubectl auth can-i responde preguntas de autorización directamente, incluso en nombre de otra identidad:

kubectl auth can-i list secrets \

  --as=system:serviceaccount:team-payments:reporting \

  -n team-payments

Habilita y lee los audit logs. El audit log del API server registra quién hizo qué, y es la verdad de base para detectar un ServiceAccount que usa permisos que no debería necesitar: una señal fuerte de que un binding es demasiado amplio (o de que algo anda mal).

Usa herramientas de análisis de RBAC. Más allá de kubectl auth can-i y kubectl describe, la comunidad tiene herramientas open source que aplanan y visualizan los permisos efectivos, marcan verbs riesgosos y comparan bindings a lo largo del tiempo. Como el modelo aditivo del RBAC hace que los permisos efectivos sean difíciles de estimar a ojo, vale la pena adoptar herramientas que calculen la unión por ti.

Revisa con cadencia, y trata cada ClusterRoleBinding y cada uso de escalate, bind, impersonate o comodines como una partida que tiene que ganarse su lugar.

RBAC en CI/CD e infrastructure-as-code

Aquí está el punto de apalancamiento que la mayoría de los equipos pasa por alto: tu configuración de RBAC es YAML, y el YAML se puede comprobar antes de que llegue al cluster.

En lugar de descubrir un ClusterRoleBinding con permisos excesivos durante un incidente, puedes analizar los manifests de tu repositorio Git como parte del code review y del CI, del mismo modo en que harías lint a cualquier otra infrastructure-as-code. Una comprobación en el pipeline puede reprobar un merge request que introduzca un verb comodín, un binding a cluster-admin o un Role que conceda escalate, dándoles a los revisores la oportunidad de objetar mientras el cambio todavía es barato de corregir.

Este enfoque shift-left encaja de forma natural con GitOps: si el estado de RBAC del cluster se define de manera declarativa en Git, entonces analizar Git es analizar el estado previsto del cluster. Detectar un binding peligroso en la etapa de pull request es mucho menos doloroso que detectarlo cuando ya está en producción, y construye una cultura en la que los permisos amplios tienen que justificarse en la revisión.

Cómo ayuda Rainforest

La plataforma de seguridad de aplicaciones de Rainforest incluye análisis de infrastructure-as-code que examina los manifests de Kubernetes y las definiciones de IaC antes de aplicarse, exponiendo patrones de RBAC riesgosos —permisos comodín, bindings a ClusterRoles demasiado amplios, verbs peligrosos y tokens de ServiceAccount expuestos— como parte de tu pipeline existente. Como se ejecuta donde tus desarrolladores ya trabajan, los hallazgos llegan al code review con el contexto para corregirlos, y no semanas después en un informe aparte. Es una pieza de un enfoque más amplio de pruebas de seguridad de aplicaciones que abarca tu código, tus dependencias y tu configuración.

Si quieres ver cómo se ve eso frente a tus propios manifests, agenda una demo y la recorreremos con tu configuración.