Al cerrar el módulo 7 dejamos la plataforma Rutas Norte completamente observable: sondas que detectan un proceso enfermo, métricas en Prometheus, cuadros de mando en Grafana, alertas encaminadas por Alertmanager y todos los logs centralizados en Elasticsearch. Vemos absolutamente todo lo que ocurre. Y sin embargo, ahora mismo, cualquiera que tenga acceso al clúster puede leer el Secret con las credenciales de postgres-reservas —la base de datos que guarda el nombre, el DNI, el teléfono y el correo de cada cliente que ha comprado un billete—, puede desplegar un contenedor privilegiado que se escape al nodo, o puede subir una imagen que nadie ha revisado. Y no sabríamos quién lo hizo.

Este módulo entero se dedica a cerrar esas puertas. Y la primera, la más importante, es esta: decidir quién puede hacer qué. En Kubernetes eso se llama RBAC (Role-Based Access Control, control de acceso basado en roles) y es el mecanismo que convierte un clúster donde todo el mundo puede todo en un clúster donde cada persona y cada proceso tiene exactamente los permisos que necesita y ni uno más.

En el módulo 3 dejamos dos hilos sueltos que ahora recogemos. Al hablar de Secrets dijimos que quién puede leer un secreto lo decide RBAC. Al hablar de ServiceAccounts dijimos que la ServiceAccount responde a quién eres y RBAC a qué puedes hacer, y vimos un 403 Forbidden que demostraba que Kubernetes deniega por defecto. Esta lección explica exactamente por qué ocurrió ese 403 y cómo se concede, con precisión quirúrgica, solo lo imprescindible.

Advertencia importante. Esta lección enseña los mecanismos de RBAC y propone un diseño de ejemplo para una empresa ficticia. El diseño real de permisos de un clúster de producción debe revisarlo un profesional de seguridad, y si el clúster trata datos personales —como es el caso de postgres-reservas— también el responsable de cumplimiento normativo de la organización. Un error de permisos no se nota hasta que alguien lo aprovecha.

1. Las tres puertas: autenticación, autorización y admisión
2. Los sujetos: usuarios, grupos y ServiceAccounts
3. Los cuatro objetos de RBAC
4. Anatomía de una regla: apiGroups, resources, verbs y resourceNames
5. Subrecursos: el poder oculto de pods/exec y pods/log
6. Los roles por defecto y los roles agregados
7. Verificar permisos con kubectl auth can-i
8. El diseño de RBAC de Rutas Norte
9. Por qué list sobre secretos equivale a leerlos
10. Escalada de privilegios y las protecciones de Kubernetes
11. Auditoría y revisión periódica de permisos
12. Errores comunes y consejos
13. Ejercicios
14. Conclusión

Todo en Kubernetes pasa por el apiserver. Cuando escribes kubectl get pods, cuando el kubelet informa del estado de un nodo, cuando el controlador de Deployments crea un ReplicaSet, cuando informes-ocupacion consulta la lista de pods: todo son peticiones HTTP a la misma API. Y toda petición atraviesa tres puertas antes de llegar a etcd.

Vamos puerta por puerta.

Responde a ¿quién eres?. El apiserver examina las credenciales que acompañan a la petición y produce una identidad: un nombre de usuario, una lista de grupos y, opcionalmente, unos atributos extra. Los mecanismos habituales son:

Si ninguno funciona, la petición se queda en system:anonymous y normalmente se rechaza con 401 Unauthorized.

Responde a ¿puedes hacer esto?. El apiserver toma la identidad de la puerta anterior y el detalle de la petición (verbo, grupo de API, recurso, namespace, nombre) y consulta a los autorizadores configurados. RBAC es el autorizador que usa prácticamente todo el mundo, aunque existen otros (Node, ABAC, Webhook, AlwaysAllow). Si ningún autorizador dice "sí", la respuesta es 403 Forbidden. No hay permiso implícito: Kubernetes deniega por defecto. Ese fue exactamente el 403 que vimos en 03-06.

Un detalle esencial: RBAC solo concede, nunca deniega. No existen reglas de denegación. El permiso efectivo de un sujeto es la unión de todo lo que le conceden todos sus bindings. Por eso quitar un permiso significa quitar el binding que lo otorga, no añadir una regla que lo prohíba.

Responde a ¿este objeto es aceptable tal y como viene?. Aquí actúan los controladores de admisión mutantes (que pueden modificar el objeto, como el que inyecta la ServiceAccount por defecto) y los validantes (que solo aceptan o rechazan). Es donde viven las ResourceQuota del módulo 3, el Pod Security Admission y las políticas de Kyverno.

Esta tercera puerta es el tema de 08-03; aquí solo la nombramos para que veas dónde encaja RBAC. Recuerda la diferencia clave:

RBAC decide si tienes derecho a hacer la operación. La admisión decide si el objeto que envías cumple las normas. Puedes tener permiso para crear pods (RBAC dice sí) y aun así ver rechazado un pod privilegiado (la admisión dice no).

RBAC concede permisos a sujetos. Hay exactamente tres tipos.

Aquí viene la sorpresa que confunde a casi todo el mundo al empezar:

Kubernetes no almacena usuarios. No existe un objeto User. No puedes hacer kubectl create user ana. No hay ninguna base de datos de personas dentro del clúster.

Un usuario es simplemente una cadena de texto que produce el autenticador. Si te autenticas con un certificado cuyo CN=ana.garcia, para RBAC eres el usuario ana.garcia. Si te autenticas con OIDC y el proveedor devuelve el email [email protected], ese será tu nombre de usuario. El clúster confía en el autenticador y punto.

La consecuencia práctica es importante: dar de alta y de baja a personas es responsabilidad del proveedor de identidad, no de Kubernetes. Si Ana deja la empresa y solo borras su RoleBinding, pero su certificado sigue siendo válido y le quedaban permisos por otro binding de grupo, sigue entrando.

Igual que los usuarios: son cadenas que produce el autenticador. Con un certificado X.509, cada campo O (organización) se convierte en un grupo. Con OIDC, suele configurarse un claim como groups.

Casi siempre debes conceder permisos a grupos, no a usuarios. Si Rutas Norte contrata a alguien nuevo en el equipo de plataforma, lo añades al grupo plataforma en el proveedor de identidad y ya tiene los permisos. No hay que tocar un solo YAML del clúster.

Kubernetes reserva algunos grupos con significado propio:

Cuidado extremo con system:masters. El apiserver le concede permiso total antes de consultar RBAC, así que no se puede limitar ni revocar con un manifiesto. Es la identidad del kubeconfig de administrador que genera kubeadm. Ese fichero debe custodiarse como una llave maestra: guardado fuera del portátil de nadie, con acceso registrado, y usado solo para recuperar el clúster cuando RBAC está roto.

Son las identidades de los procesos que corren en el clúster, y sí son objetos reales de Kubernetes (los creamos en 03-06). En RBAC se referencian de dos maneras equivalentes:

Resumen comparativo:

RBAC tiene solo cuatro tipos de objeto, y todos viven en el grupo de API rbac.authorization.k8s.io/v1. La idea es de una simetría muy limpia:

• Role y ClusterRole describen qué se puede hacer. Son listas de permisos, y no mencionan a nadie.
• RoleBinding y ClusterRoleBinding describen quién lo puede hacer. Unen a unos sujetos con un rol.

Fíjate bien porque aquí está el 90 % de la confusión con RBAC:

La segunda fila es la que sorprende y a la vez la más útil. Un ClusterRole no concede nada por sí solo: es solo una plantilla de permisos. Cuando lo referencias desde un RoleBinding, sus reglas se aplican únicamente dentro del namespace de ese binding. Esto permite escribir el rol una vez y reutilizarlo en muchos namespaces.

Con esos dos manifiestos, el grupo soporte puede listar pods en rutas-norte-pro y en ningún otro sitio. Si mañana quisiéramos darle también lectura en rutas-norte-pre, bastaría con otro RoleBinding idéntico cambiando el namespace: el ClusterRole no se toca.

Hay recursos que no pertenecen a ningún namespace: Node, PersistentVolume, StorageClass, Namespace, ClusterRole, CustomResourceDefinition... Para conceder permisos sobre ellos es obligatorio un ClusterRole referenciado desde un ClusterRoleBinding. Un RoleBinding nunca puede dar acceso a un recurso global, por mucho que el ClusterRole lo mencione.

Un detalle de roleRef que conviene saber: es inmutable. No puedes cambiar a qué rol apunta un binding ya creado; hay que borrarlo y volver a crearlo. La lista de subjects, en cambio, sí se puede modificar.

Una regla de RBAC es la intersección de cuatro dimensiones. Todas deben coincidir para que el permiso aplique.

Cada recurso de Kubernetes pertenece a un grupo de API. El grupo del núcleo (core, también llamado legacy) es histórico y se representa con la cadena vacía "", no con core. Ahí viven Pods, Services, ConfigMaps, Secrets, ServiceAccounts, Nodes, PersistentVolumeClaims y Namespaces.

Escribir apiGroups: ["core"] es un error silencioso muy frecuente: no falla al aplicar el manifiesto, simplemente no concede nada porque no existe ningún grupo llamado core.

Para averiguar el grupo y el nombre plural exacto de cualquier recurso:

Cuando APIVERSION es solo v1 (sin barra), el grupo es el vacío "". Cuando es apps/v1, el grupo es apps. La columna NAMESPACED te dice si necesitas Role o forzosamente ClusterRole.

En una regla se usa siempre el nombre plural en minúsculas de la columna NAME, nunca el KIND ni el nombre corto. resources: ["Pod"] o resources: ["po"] no conceden nada.

Y tres verbos especiales que no corresponden a una operación normal:

Los tres son, en la práctica, vías de escalada de privilegios. Volveremos a ellos en el apartado 10.

Un aviso importante sobre deletecollection: mucha gente lo pasa por alto al construir un rol de "poder borrar cosas concretas". Si concedes delete con resourceNames pero también deletecollection sin restricción, has abierto la puerta a borrarlo todo, porque resourceNames no aplica a las operaciones de colección.

Permite acotar una regla a objetos con nombres concretos:

Con este rol se puede hacer kubectl get configmap tienda-web-config pero no kubectl get configmap otro-cualquiera.

La limitación fundamental de resourceNames. No funciona con list, watch, create ni deletecollection. La razón es sencilla: cuando pides una lista, aún no sabes qué objetos hay, así que el autorizador no puede filtrar por nombre —solo puede permitir o denegar la petición entera—. RBAC no es un filtro de contenido.

Consecuencia práctica: resourceNames restringe la lectura individual, pero no impide un listado si has concedido list. Si tu intención es "que solo pueda ver este ConfigMap", tienes que conceder get con resourceNames y no conceder list. La contrapartida es que kubectl get configmaps (sin nombre) fallará con un 403, lo cual desconcierta a los usuarios; hay que documentarlo.

Aun con esa limitación, resourceNames es muy valioso en un caso concreto: dar a un proceso permiso para actualizar exactamente un objeto. Lo usaremos con ci-rutasnorte.

Algunos recursos tienen subrecursos: rutas hijas de la API con su propio control de acceso. Se escriben con una barra en el campo resources.

El punto clave que se olvida constantemente:

get pods y get pods/log son permisos distintos. Poder ver que un pod existe no da derecho a leer sus logs. Y pods/exec no lo concede el verbo get sobre pods: hay que nombrarlo explícitamente. Esto es una buena noticia, porque permite dar visibilidad sin dar acceso.

Ejemplo directamente aplicable a Rutas Norte: el equipo de soporte necesita ver si un pod está caído y leer sus logs para responder a un cliente que dice que no le llega el correo de confirmación. No necesita entrar en el contenedor.

Fíjate en lo que no está. Un rol de seguridad se juzga tanto por lo que omite como por lo que incluye. Si soporte tuviera pods/exec sobre api-reservas, podría abrir una shell, leer las variables de entorno del proceso y obtener la cadena de conexión a la base de datos de clientes. El límite entre "ver el estado" y "leer datos personales" es exactamente esa línea del YAML.

Y ojo con pods/log incluso así: en 07-05 prohibimos explícitamente registrar datos personales en los logs precisamente porque un permiso de lectura de logs es mucho más fácil de conceder que uno de lectura de base de datos. Las dos decisiones se refuerzan.

Todo clúster viene con decenas de ClusterRole predefinidos. Muchos son internos (system:kube-scheduler, system:node...), pero cuatro están pensados para personas:

Dos matices que deciden diseños enteros:

1. edit puede leer Secrets. Mucha gente concede edit en producción pensando "es que solo edita, no administra", y con eso ha entregado las credenciales de la base de datos de clientes. Si esto te importa —y en Rutas Norte nos importa mucho—, no puedes usar edit tal cual en rutas-norte-pro.
2. view no ve Secrets (fue una decisión explícita del proyecto), pero sí ve ConfigMaps. Esto refuerza lo que dijimos en 03-01 y 03-02: los datos sensibles van en Secrets, nunca en ConfigMaps, aunque "solo sea una cadena de conexión sin contraseña".

Comprobar qué hace exactamente un rol antes de usarlo es un hábito obligatorio:

Algunos roles por defecto no tienen reglas propias: se componen automáticamente con las reglas de todos los ClusterRole que llevan ciertas etiquetas. Eso es la aggregationRule.

El controlador de agregación vigila los ClusterRole con esa etiqueta y copia sus reglas dentro de view. Esto es enormemente útil cuando instalas CRDs: puedes hacer que quien tiene view vea también tus recursos personalizados sin editar el rol view (que se sobrescribiría en cada actualización del clúster).

Ejemplo real para Rutas Norte: en el módulo 7 instalamos el operador de Prometheus, que aporta ServiceMonitor y PrometheusRule. Queremos que soporte y desarrollo puedan verlos.

Al aplicarlo, cualquiera que tenga view en cualquier namespace pasa a ver los ServiceMonitor de ese namespace, sin tocar ni un binding. Nota la jerarquía: admin agrega lo de edit, y edit agrega lo de view, así que si solo pones aggregate-to-view, los tres lo heredan igualmente. Ponerlas las tres es explícito y no hace daño.

Escribir RBAC sin verificarlo es como escribir tests sin ejecutarlos. kubectl auth can-i responde a la pregunta exacta que el apiserver se hace.

Lo verdaderamente potente es --as y --as-group, que preguntan en nombre de otra identidad (esto usa el mecanismo de impersonation, así que necesitas el verbo impersonate o ser administrador):

También se pueden verificar ServiceAccounts, que es como se auditan los permisos de los procesos:

Y una vista completa de todo lo que puede hacer un sujeto en un namespace:

Esa salida es exactamente la "hoja de permisos" que hay que revisar en cada auditoría. Si aparece algo que no esperabas, tienes un binding de más.

Estable desde 1.28, responde a "¿quién cree el clúster que soy?". Es la herramienta para diagnosticar problemas de autenticación, que se confunden constantemente con problemas de autorización.

Un patrón de diagnóstico útil:

Un guion de verificación que merece la pena guardar en el repositorio junto a los manifiestos, para ejecutarlo tras cada cambio de RBAC:

Ejecutar este guion en cada cambio convierte el RBAC en algo verificable. Sin él, un roleRef mal copiado puede pasar meses inadvertido.

Ahora aplicamos todo a los cuatro colectivos de la empresa y a las ServiceAccounts de los procesos. El principio rector es el de mínimo privilegio: cada sujeto recibe lo justo para su trabajo.

Resumen del diseño:

En rutas-norte-dev necesitan trabajar con libertad. Usamos el ClusterRole edit acotado con un RoleBinding:

Es aceptable porque en rutas-norte-dev no hay datos reales de clientes: solo datos sintéticos generados para pruebas. Esa afirmación es una decisión de diseño que debe estar documentada y verificada, no una suposición. Si algún día alguien copiase un volcado de producción a desarrollo, este binding pasaría a ser un incidente grave. Es exactamente el tipo de regla que el responsable de cumplimiento debe conocer.

En rutas-norte-pro el planteamiento cambia por completo. Los desarrolladores necesitan investigar —ver el estado, leer logs, consultar eventos— pero no tocar nada ni leer credenciales.

Y el mismo ClusterRole, más el permiso de logs, se reutiliza en rutas-norte-pre sin escribir reglas nuevas. Esa es la ventaja de la combinación RoleBinding → ClusterRole.

Administra los tres namespaces. Podríamos darles cluster-admin, pero es excesivo y hace imposible distinguir en el registro de auditoría (08-06) una operación rutinaria de una anómala. Preferimos admin por namespace más un ClusterRole de lectura de infraestructura:

cluster-admin queda reservado para un procedimiento de emergencia con acceso registrado y aprobación previa. En muchas organizaciones esto se implementa con acceso temporal (just-in-time): un sistema externo crea el ClusterRoleBinding, avisa por un canal público y lo borra automáticamente a las dos horas.

Ya escribimos su ClusterRole en el apartado 5. Solo falta el binding, exclusivamente en producción:

Este es el caso más interesante, porque la CI es un objetivo muy goloso: si alguien compromete el sistema de CI y este tiene cluster-admin, tiene el clúster. Le damos exactamente lo que necesita para desplegar: actualizar la imagen de los Deployments y StatefulSets existentes. Nada más.

Analicemos las decisiones:

• Sin create: los objetos nuevos los crea una persona de plataforma tras revisión. La CI solo actualiza lo que ya existe y ha sido revisado.
• Sin delete ni deletecollection: una CI comprometida no puede borrar la plataforma.
• Sin secrets: la CI no lee credenciales del clúster. Las suyas están en el gestor de secretos de la canalización.
• Sin pods/exec: no hay manera de que la CI abra una shell en producción.

Si quisiéramos ser todavía más estrictos, podríamos acotar con resourceNames a los nombres exactos de las cargas:

Ese es el patrón correcto cuando hace falta el listado: dos reglas, una restrictiva para las operaciones por nombre y otra con solo list.

El CronJob informes-ocupacion genera un informe nocturno de ocupación de plazas. No necesita hablar con la API de Kubernetes en absoluto, así que lo correcto es que ni siquiera monte el token:

Que un proceso no tenga ningún binding es la situación ideal y más frecuente de lo que la gente cree. tienda-web, worker-notificaciones y redis-cache están en el mismo caso.

api-reservas sí necesita leer un ConfigMap concreto para recargar su configuración de rutas en caliente:

Y el operador de PostgreSQL del módulo 6, que sí necesita permisos amplios porque su trabajo es gestionar StatefulSets, Services y PVCs. Recuerda lo que dijimos en 06-07: antes de adoptar un operador hay que leer qué RBAC pide. Este es el mínimo razonable, acotado a un namespace:

Si el operador que estás evaluando exige un ClusterRole con secrets en todo el clúster y su documentación no explica por qué, esa es una razón legítima para rechazarlo o para desplegarlo con el alcance restringido a un namespace, si lo soporta.

Este es uno de los puntos que más gente entiende mal, y tiene consecuencias directas sobre los datos de clientes de Rutas Norte.

Cuando ejecutas kubectl get secrets, kubectl hace un GET /api/v1/namespaces/<ns>/secrets. El apiserver devuelve una SecretList con los objetos completos, incluido el campo data con todos los valores. Que kubectl te muestre una tabla resumida sin los valores es solo una decisión de presentación del cliente. Los datos ya viajaron por la red hasta tu máquina.

Como dijimos en 03-02, base64 no es cifrado: es codificación. Una sola orden lo revierte.

Regla que no admite excepciones: conceder list sobre secrets es conceder lectura de todos los secretos de ese ámbito. No existe forma de listar secretos "sin ver su contenido". Si un rol tiene list sobre secrets en rutas-norte-pro, quien lo tenga puede leer las credenciales de la base de datos de clientes. Trátalo con la misma seriedad que entregar la contraseña.

Lo mismo vale para watch, que entrega los objetos completos en cada cambio.

Eso es cluster-admin. Pero incluso los comodines "pequeños" son peligrosos:

La última fila es especialmente traicionera: un comodín en verbs sobre pods no incluye los subrecursos (hay que nombrarlos), pero resources: ["pods/*"] sí incluye exec, attach y portforward. Merece la pena memorizar la diferencia.

Y hay un problema temporal: un comodín concede permisos sobre recursos que todavía no existen. Si instalas un CRD nuevo el mes que viene, cualquiera con resources: ["*"] lo controlará desde el primer día, sin que nadie haya decidido nada.

La alternativa correcta es siempre enumerar. Es más largo de escribir y muchísimo más fácil de auditar.

Kubernetes impide, por defecto, que crees o modifiques un rol con permisos que tú no tienes. Si pudieras, cualquiera con permiso sobre roles sería cluster-admin de facto: se escribiría un rol con * y se lo asignaría.

La regla exacta es: para crear o modificar un rol, debes poseer ya todos los permisos que ese rol concede (en el ámbito correspondiente). Hay dos excepciones deliberadas:

bind, acotado con resourceNames, es el mecanismo elegante para delegar. En Rutas Norte podríamos permitir que los jefes de equipo concedan el rol de soporte sin ser administradores:

Quien tenga este rol puede crear bindings al rol rutasnorte-soporte y a ningún otro. No puede vincular admin, ni cluster-admin. Es una delegación segura.

Esta es probablemente la implicación más subestimada de todo RBAC:

Si puedes crear pods en un namespace, puedes ejecutar código con la identidad de cualquier ServiceAccount de ese namespace, simplemente poniendo su nombre en spec.serviceAccountName.

Crear pods no está protegido por la regla de "no puedes conceder lo que no tienes", porque técnicamente no estás creando un rol: estás creando un pod. Pero el efecto práctico es idéntico a heredar los permisos de esa ServiceAccount.

Consecuencias concretas para nuestro diseño:

1. create pods en rutas-norte-pro es un permiso de alto privilegio. Por eso ci-rutasnorte no lo tiene y desarrollo tampoco lo tiene en producción.
2. Nunca metas en el mismo namespace una ServiceAccount muy privilegiada y cargas de trabajo normales. El operador de PostgreSQL, que puede leer secretos, comparte namespace con tienda-web. Quien pueda crear un pod ahí, hereda los permisos del operador. Lo correcto es aislar los operadores en su propio namespace.
3. Los verbos que crean pods indirectamente cuentan igual: crear Deployments, StatefulSets, DaemonSets, Jobs o CronJobs es crear pods por delegación. edit incluye todos ellos.

Otras rutas de escalada que conviene conocer para poder cerrarlas:

Auditar estos permisos concretos es una tarea rutinaria muy rentable:

Esa lista debe caber en una pantalla y cada línea debe tener una justificación conocida. El día que no quepa, empieza el problema.

RBAC se degrada con el tiempo. Un permiso temporal que nadie retiró, un binding para depurar una incidencia que se quedó, un grupo que creció. La única defensa es la revisión sistemática.

La segunda línea es exactamente lo que hay que cazar: un acceso de emergencia que debía durar dos horas y sigue ahí. La convención de poner la fecha en el nombre del binding hace que salte a la vista.

Solo plataforma. Es el resultado que buscábamos y hay que poder demostrarlo en cualquier momento: esta salida, guardada con fecha, es una evidencia válida para una auditoría de cumplimiento.

Cuando una persona deja la empresa, su binding se queda. Cuando una ServiceAccount se borra, sus bindings también. Un chequeo sencillo:

Existen utilidades específicas que hacen este trabajo mucho más cómodo:

Una cadencia razonable para una plataforma como Rutas Norte:

Todos los manifiestos de RBAC deben vivir en el repositorio, en k8s/base/rbac/, y aplicarse solo desde ahí. Un binding creado a mano con kubectl create rolebinding es invisible para la revisión de código y es exactamente por donde entran los problemas. En el módulo 10 veremos con GitOps cómo hacer que el clúster rechace de facto cualquier cosa que no esté en Git.

Escribir apiGroups: ["core"]. No existe. El grupo del núcleo es la cadena vacía "". El manifiesto se aplica sin error y no concede nada; luego pasas una hora buscando por qué hay un 403.

Usar el Kind o el nombre corto en resources. Hay que usar el plural en minúsculas: pods, no Pod ni po; deployments, no Deployment. Consúltalo con kubectl api-resources.

Creer que un RoleBinding a un ClusterRole da permisos globales. No: los acota al namespace del binding. Es justo lo contrario de lo que sugiere el nombre y es la combinación más útil de las cuatro.

Intentar cambiar el roleRef de un binding existente. Es inmutable. Hay que borrar y recrear. Un kubectl apply que cambia el roleRef falla con un error poco descriptivo.

Conceder edit en producción "porque solo edita". edit lee y crea Secrets, y crea pods (con lo que puede suplantar cualquier ServiceAccount del namespace). En un namespace con datos personales es un permiso de administración disfrazado.

Suponer que resourceNames protege el listado. No aplica a list, watch, create ni deletecollection. Si concedes list sin nombres, se ve todo.

Olvidar que list sobre Secrets es leerlos. No hay forma de listarlos sin ver el contenido.

Añadir comodines "para salir del paso". El permiso temporal se queda, y encima concede acceso a recursos que todavía no existen. Si necesitas desbloquear a alguien rápido, concede el permiso exacto que le falta y ábrele una tarea para revisarlo.

Conceder permisos a usuarios en vez de a grupos. Cada alta y cada baja se convierte en un cambio de manifiesto, y las bajas se olvidan siempre.

Confundir 401 con 403. 401 es autenticación (no sé quién eres), 403 es autorización (sé quién eres y no puedes). kubectl auth whoami distingue los dos casos en un segundo.

No verificar. Escribe siempre las comprobaciones negativas: no basta con confirmar que soporte puede leer logs, hay que confirmar que no puede hacer exec ni leer Secrets. Los fallos de seguridad están en los permisos de más, no en los de menos.

Poner un operador privilegiado en el mismo namespace que las aplicaciones. Quien pueda crear un pod ahí hereda los permisos del operador. Namespace aparte.

Consejo de oro: empieza siempre por cero permisos y añade solo lo que falla. Es más lento el primer día y muchísimo más seguro todos los demás. Con kubectl auth can-i --list sabrás en cada momento exactamente dónde estás.

Rutas Norte incorpora un becario en el equipo de soporte. Necesitas un ClusterRole llamado rutasnorte-soporte-junior y un binding que lo aplique solo a rutas-norte-pre. Debe poder:

• Listar y ver pods, servicios y deployments.
• Leer los logs de los pods.

Y no debe poder:

• Leer Secrets.
• Ejecutar kubectl exec ni kubectl port-forward.
• Modificar nada.

Escribe los manifiestos y las órdenes de verificación que demuestren las tres prohibiciones.

Un nuevo agente de métricas, agente-inventario, corre como Deployment en rutas-norte-pro con su propia ServiceAccount. Necesita listar pods y nodos de todo el clúster para elaborar un inventario de recursos, y nada más. Escribe la ServiceAccount, el ClusterRole, el ClusterRoleBinding y una comprobación que demuestre que no puede leer Secrets ni crear nada.

Pregunta adicional: ¿por qué aquí sí hace falta un ClusterRoleBinding y no basta con un RoleBinding?

Encuentras este Role aplicado en rutas-norte-pro:

Está vinculado al grupo analitica, cuyo único cometido es consultar las métricas de ocupación mediante los ServiceMonitor y ver el estado de los pods.

1. Enumera todos los problemas de seguridad de este rol.
2. Reescríbelo con el mínimo privilegio.
3. Escribe las comprobaciones que demuestren que la versión nueva sigue sirviendo para su cometido y ya no expone datos personales.

Solución 1

Verificación:

La última comprobación es la que demuestra que el RoleBinding acota el ClusterRole: en rutas-norte-pro no tiene absolutamente nada.

Solución 2

Verificación:

Por qué hace falta un ClusterRoleBinding: por dos razones independientes.

1. nodes es un recurso sin namespace. Un RoleBinding nunca puede conceder acceso a recursos globales, ni siquiera referenciando un ClusterRole que los mencione.
2. El agente debe listar pods de todos los namespaces. Un RoleBinding acotaría la lectura al namespace del binding, y habría que replicarlo en cada namespace existente y futuro.

Si el requisito hubiera sido solo "pods de rutas-norte-pro", un RoleBinding habría sido la opción correcta y más segura.

Solución 3

1. Problemas del rol original:

2. Versión con mínimo privilegio:

Fíjate en que también hemos quitado pods/log: el cometido declarado es consultar métricas, y los logs podrían contener información de clientes (aunque en 07-05 lo prohibimos, el permiso mínimo no depende de que esa prohibición se cumpla siempre).

3. Verificación:

Como el rol viejo concedía acceso a las credenciales de la base de datos de clientes, no basta con corregir el rol: hay que revisar el registro de auditoría para saber si alguien llegó a leer ese Secret, y si es así, rotar las credenciales y notificarlo al responsable de cumplimiento. Cómo se hace esa consulta es el tema de 08-06.

RBAC es la primera y más importante línea de defensa de un clúster de Kubernetes, y ahora tienes el modelo mental completo:

• Toda petición atraviesa tres puertas: autenticación (quién eres), autorización (qué puedes hacer, aquí actúa RBAC) y control de admisión (si el objeto es aceptable).
• Los sujetos son usuarios y grupos, que Kubernetes no almacena y llegan del autenticador, y ServiceAccounts, que sí son objetos del clúster.
• Cuatro objetos: Role/ClusterRole dicen qué, RoleBinding/ClusterRoleBinding dicen quién. La combinación RoleBinding → ClusterRole es la más útil: escribe el rol una vez, acótalo donde quieras.
• Una regla es la intersección de apiGroups (con el grupo vacío "" del núcleo), resources (incluidos subrecursos como pods/log y pods/exec), verbs y opcionalmente resourceNames (que no aplica a list).
• list sobre Secrets es leerlos. Los comodines conceden más de lo que crees, incluido sobre recursos que aún no existen.
• Crear pods equivale a poder usar cualquier ServiceAccount del namespace; por eso los operadores privilegiados van en su propio namespace.
• kubectl auth can-i --as/--as-group y kubectl auth whoami convierten el RBAC en algo verificable, y esas verificaciones deben ejecutarse automáticamente en cada cambio.

En Rutas Norte hemos pasado de "cualquiera puede leer las credenciales de la base de datos de clientes" a un diseño donde solo plataforma puede hacerlo, soporte ve el estado y los logs sin poder entrar en los contenedores, desarrollo investiga producción sin tocarla, y la canalización de integración continua solo puede actualizar la imagen de las cargas que ya existen.

Pero acabamos de descubrir un límite incómodo: RBAC decide si tienes derecho a crear un pod, no cómo es ese pod. Alguien de plataforma, con permisos perfectamente legítimos, puede desplegar hoy mismo un contenedor con privileged: true, que monte / del nodo con hostPath y corra como root. RBAC dirá que sí, porque tiene permiso para crear pods. Y desde ahí, el nodo entero —y todos los pods que corran en él, incluido postgres-reservas— queda al descubierto.

La siguiente lección, 08-02, Contextos de Seguridad y Endurecimiento del Contenedor, ataca exactamente ese problema: qué aísla realmente un contenedor, por qué no es una máquina virtual, y cómo se configura el securityContext de cada componente de Rutas Norte para que, aunque alguien consiga ejecutar código dentro de un contenedor, no pueda salir de él.