Roles de sistema¶

Un permiso de kubelatch es siempre la combinación de un sujeto, un cluster, un rol y un ámbito. Los seis roles de sistema, también llamados niveles, vienen con kubelatch: no se pueden editar, y todos menos admin y cluster-admin se pueden duplicar en un rol personalizado. Aquí ves qué permite cada nivel, dónde se puede conceder, qué exige y, sobre todo, qué no puede garantizar. Los roles que compone un administrador están en Roles.

Los seis roles de sistema¶

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é nivel cubre a cuál¶

Algunos niveles incluyen enteros a otros. En el mismo cluster y ámbito, un permiso con el de la izquierda hace sobrar un permiso con los de la derecha:

debugger y secrets-reader son complementos: nada los incluye y no incluyen nada. Un rol personalizado no declara nada en ningún sentido. Todas las listas de permisos usan esta tabla para señalar un permiso que sobra, por ejemplo viewer junto a developer para la misma cuenta en el mismo namespace (Solapamientos). No se revoca nada solo: un permiso que sobra no da nada más, y puede durar más que el que lo cubre.

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 abrir una shell en otro pod, 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 kubelatch lo advierte en la parte superior de «Permisos» y en «Avisos», la campana de la barra superior. 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 rol, de sistema ni personalizado. 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 *.
• Los demás niveles solo se conceden sobre un namespace, que debe existir en ese cluster en el momento de conceder.
• Un rol personalizado se concede sobre un namespace, y con * solo si se puede conceder a todo el cluster (Roles).

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 suplantació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. admin y cluster-admin apuntan directamente a los roles de Kubernetes del mismo nombre.

Para ampliar un nivel con un CRD, crea en el cluster un ClusterRole pequeño con esa etiqueta; kubelatch lo recoge sin ningún cambio por su parte.

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 retira en su pasada periódica los bindings de los permisos caducados. El proxy deja de enviar el grupo de un permiso caducado al instante, sin esperar a esa pasada.