Niveles de permiso¶

Un permiso de kubelatch es siempre la combinación de un sujeto, un cluster, un nivel y un ámbito. Aquí ves qué permite cada nivel, dónde se puede conceder, qué exige y, sobre todo, qué no puede garantizar.

Los seis niveles¶

Un sujeto puede tener varios permisos en el mismo cluster. Lo normal es combinarlos: developer en apps más debugger en apps para quien necesita entrar en sus pods.

Qué deja fuera developer, y por qué¶

developer no es el rol edit de Kubernetes. edit incluye secrets, pods/exec y serviceaccounts/token, que son justo lo que un permiso de trabajo diario no debería dar sin pensarlo. developer no tiene:

• secrets, serviceaccounts ni serviceaccounts/token;
• los subrecursos exec, attach, portforward, proxy y ephemeralcontainers de los pods;
• roles, rolebindings, resourcequotas ni limitranges.

Esas capacidades quedan repartidas en niveles aparte (debugger, secrets-reader, admin) para que concederlas sea una decisión explícita y auditada.

El namespace es la frontera¶

Kubernetes lo dice en su propia documentación: las fronteras dentro de un namespace son débiles. kubelatch no puede cambiar eso, y conviene entenderlo antes de conceder nada.

Quien puede crear pods en un namespace puede montar cualquier Secret de ese namespace y usar cualquier ServiceAccount de ese namespace, con sus permisos. Por tanto:

• Quien tiene developer en un namespace alcanza sus Secrets y sus ServiceAccounts, aunque el nivel no incluya secrets. Le basta con desplegar un pod que los monte.
• secrets-reader y debugger son comodidades, no fronteras. Ahorran desplegar un pod para leer un Secret o para inspeccionar otro, pero no protegen nada que developer no alcance ya.
• Los tokens de ServiceAccount obtenidos desde un pod no pasan por kubelatch. Lo que se haga con ellos queda en la auditoría nativa del cluster, no en la de kubelatch. Por eso conviene mantenerla activa en el proveedor.

La consecuencia práctica: concede developer, debugger y admin solo en namespaces cuyo contenido pueda ver y tocar esa persona. Lo que quieras separar entre equipos, sepáralo en namespaces distintos.

Pod Security Admission¶

Sin Pod Security Admission, quien crea pods puede crear uno privilegiado que monte el disco del nodo, y desde el nodo alcanza el cluster entero. Un contenedor efímero añadido con debugger puede hacer lo mismo.

Por eso developer, debugger y admin exigen que el namespace tenga la etiqueta pod-security.kubernetes.io/enforce con valor baseline o restricted. kubelatch lo comprueba al conceder el permiso, leyendo el namespace en el cluster.

KUBELATCH_REQUIRE_PSA=false desactiva la comprobación, y «Permisos» lo avisa en la cabecera. Solo tiene sentido si otra herramienta (OPA, Kyverno) impone lo mismo.

Namespaces protegidos¶

kube-system, kube-public, kube-node-lease y kubelatch-system no admiten permisos de ningún nivel. KUBELATCH_PROTECTED_NAMESPACES añade otros a la lista. Lo que haya que hacer ahí se hace con el acceso nativo de administración, fuera de kubelatch.

Ámbitos permitidos¶

• * (todo el cluster) solo se admite con viewer y cluster-admin.
• cluster-admin solo se admite con *.
• El resto de niveles solo se conceden sobre un namespace, que debe existir en ese cluster en el momento de conceder.

viewer con * ve también los logs de todos los namespaces, y los logs pueden contener secretos. Concédelo sabiendo eso.

cluster-admin como acceso de emergencia auditado¶

cluster-admin da control total del cluster. kubelatch lo trata como un acceso de emergencia: exige fecha de caducidad y no admite más de 8 h. Queda registrado quién lo concedió y a quién, y cada petición hecha con él queda en la auditoría. Es la vía preferida para una intervención urgente mientras kubelatch funciona.

Cómo se materializa en el cluster¶

El reconciliador traduce los permisos activos a RBAC estándar en cada cluster:

Los bindings nunca nombran a personas: nombran grupos. El proxy usa la impersonación para actuar como cada persona con los grupos de sus permisos activos, y el API server aplica los bindings de esos grupos (ver El viaje de una petición).

viewer, developer, debugger y secrets-reader son ClusterRoles propios (kubelatch-<nivel>) agregados: sus reglas vienen de un ClusterRole base (kubelatch-<nivel>-base) y de cualquier otro ClusterRole con la etiqueta kubelatch.io/aggregate-to-<nivel>: "true". viewer recoge además todo lo etiquetado para el rol view estándar, y developer recoge todo lo de viewer. Así, añadir un CRD a un nivel es crear un ClusterRole pequeño con esa etiqueta, sin tocar kubelatch. admin y cluster-admin apuntan directamente a los roles de Kubernetes del mismo nombre.

Un binding existe mientras al menos un sujeto habilitado tenga un permiso activo con ese nivel y ese ámbito. El reconciliador lo crea al conceder, lo borra cuando sobra y recoge las caducidades en su pasada periódica. El proxy deja de enviar el grupo de un permiso caducado al instante, sin esperar a esa pasada.