Kubernetes 1.37 lleva el Kubelet rootless a beta

Kubernetes 1.37 asciende a beta la función KubeletInUserNamespace, conocida comúnmente como modo rootless. Cuando esta característica se utiliza, kubelet, los runtimes de contenedores, los componentes de CNI y kube-proxy pueden ejecutarse como un usuario sin privilegios de root en el host, dentro de un user namespace de Linux. El beneficio práctico reside en reducir el radio de impacto cuando una vulnerabilidad en un componente del nodo o un escape de contenedor alcanza privilegios que tradicionalmente equivaldrían a root en el host.

Revisé el anuncio oficial de Kubernetes 1.37 y la documentación técnica de administración antes de escribir esto. Hay un detalle que se malinterpreta con frecuencia: el feature gate viene activado por defecto en 1.37, pero los clústeres existentes no se convierten de repente en rootless. Los administradores todavía deben crear el user namespace y cumplir los requisitos del host.

¿Qué cambió en el modo rootless de Kubernetes 1.37?

Kubernetes 1.37 pasó KubeletInUserNamespace de alpha a beta y activó el feature gate por defecto. Kubelet ahora puede tolerar las diferencias de permisos que surgen cuando los componentes del nodo se ejecutan dentro de un user namespace, y Kubernetes informa de si un nodo funciona de este modo mediante la propiedad runningInUserNamespace.

Este reporte resulta muy útil en las operaciones diarias, ya que los administradores del clúster pueden identificar nodos rootless y aplicarles etiquetas (labels) o taints para que las cargas de trabajo que requieran privilegios reales de root en el host no se programen en nodos incompatibles.

El proyecto Kubernetes también indica que sus pruebas integrales (end-to-end) de conformidad de nodos ahora se ejecutan en un clúster rootless dentro de CI. Es una señal valiosa de madurez, dado que la funcionalidad se valida de forma continua frente a la propia batería de pruebas del proyecto.

El estado beta implica que la función entra en una fase donde se espera una adopción y unas pruebas más amplias. Los detalles de compatibilidad siguen mereciendo atención, por lo que no conviene activarla de golpe en todos los entornos.

¿Qué significa realmente «rootless» en Kubernetes?

Kubernetes rootless significa que los componentes del nodo se ejecutan como un usuario normal desde la perspectiva del host, mientras que dentro de un user namespace de Linux perciben una identidad root mapeada. El UID 0 dentro de ese espacio no equivale al UID 0 en el host físico, y de ese mapeo proviene precisamente el valor de seguridad.

Los nodos convencionales de Kubernetes ejecutan componentes con altos privilegios directamente como root porque necesitan montar sistemas de archivos, crear cgroups, configurar namespaces y gestionar la red. Un fallo en cualquiera de esos componentes puede convertirse, por tanto, en una ejecución como root en el host.

Un user namespace establece un límite de privilegios diferente. El proceso puede llevar a cabo numerosas operaciones de tipo root dentro del namespace sin recibir autoridad irrestricta sobre la máquina anfitriona.

El nodo sigue manteniendo privilegios; lo que cambia es cuáles de ellos sobreviven al cruzar la frontera del namespace.

¿Por qué un kubelet rootless mejora la seguridad?

El kubelet rootless constituye una mejora de seguridad porque varias clases de errores de escape en contenedores y componentes del nodo resultan menos dañinas cuando el proceso comprometido no es root en el host. El anuncio de Kubernetes enumera vulnerabilidades históricas en CRI-O, runc, kubelet y containerd como ejemplos de fallos donde los privilegios de root a nivel de host incrementaron la gravedad.

El proyecto señala expresamente que el funcionamiento rootless puede impedir que un atacante utilice un componente de nodo comprometido para modificar áreas como el kernel, el cargador de arranque o el firmware mediante la autoridad habitual de root.

Se trata de defensa en profundidad: asume que otro control puede fallar y limita lo que el atacante obtiene después. Resulta de especial utilidad en clústeres que procesan entradas no confiables, entornos multinquilino, portátiles de desarrollo, sandboxes de IA y arquitecturas anidadas de Kubernetes.

El ejemplo de los entornos aislados para IA es muy actual. Los agentes de programación y las herramientas autónomas ejecutan comandos, instalan paquetes y procesan contenidos de Internet de forma creciente. Ejecutar el clúster de desarrollo bajo un usuario de host sin privilegios puede limitar los daños si engañan a un agente para que ejecute instrucciones maliciosas.

¿Protege Kubernetes rootless contra cualquier escape de contenedor?

No. El proyecto Kubernetes indica explícitamente que los user namespaces no mitigan las vulnerabilidades del propio kernel. Si el exploit ataca un fallo del kernel accesible desde el namespace, sigues necesitando un kernel parcheado y mecanismos de contención de llamadas al sistema (syscalls).

Esa limitación es fundamental porque el término «rootless» puede sonar a barrera de seguridad absoluta cuando solo es una capa más. Conviene combinarlo con seccomp, AppArmor o SELinux según proceda, kernels al día con sus parches, capacidades restringidas, controles de red, políticas de admisión, identidad de cargas de trabajo y el blindaje habitual del nodo.

Ten en cuenta también que ciertas cargas de trabajo necesitan privilegios de host de forma legítima. Los plugins de almacenamiento y de red pueden requerir accesos que un nodo rootless no puede conceder. Por tanto, esta característica puede plantear compromisos de compatibilidad que debes probar con tu CNI, CSI, plugins de dispositivos y agentes de observabilidad.

La página de Kubernetes en Mr.PlanB sirve como punto de referencia útil para los cambios de seguridad que se están incorporando en las versiones recientes de Kubernetes. El modo rootless encaja en una tendencia general hacia menores privilegios por defecto y un aislamiento más estricto.

¿En qué se diferencia esto de los pods rootless?

KubeletInUserNamespace es diferente de los user namespaces en pods. Kubernetes dispone de una capacidad independiente, UserNamespacesSupport, capaz de ejecutar pods en user namespaces mediante hostUsers: false. Esa función alcanzó la disponibilidad general (GA) en Kubernetes 1.36.

Los user namespaces para pods aíslan la identidad de las cargas de trabajo, mientras que KubeletInUserNamespace aísla los propios componentes del nodo frente al root del host. Ambas ideas pueden combinarse; el proyecto Kubernetes cita la ejecución de Kubernetes dentro de Kubernetes como ejemplo. Un nodo rootless puede ejecutarse dentro de un pod con user namespace, proporcionando mayor aislamiento al clúster anidado sin exigir que el pod principal se ejecute con privilegios totales.

Vale la pena explicar esta diferencia, ya que los equipos suelen oír «user namespace» y asumir que un único ajuste resuelve tanto los privilegios de los pods como los del nodo, cuando en realidad son dos fronteras de seguridad conectadas pero distintas.

¿Cuáles son los requisitos de host para Kubernetes rootless?

La documentación oficial exige cgroup v2, una sesión de usuario de systemd, mapeos adecuados de UID y GID subordinados en /etc/subuid y /etc/subgid, además de varios parámetros del host que varían según la distribución de Linux. El user namespace rootless se crea fuera de Kubernetes, motivo por el cual habilitar el feature gate no transforma un clúster existente de forma automática.

Existen herramientas que simplifican el despliegue. El proyecto Kubernetes documenta configuraciones rootless mediante kind, minikube, Docker o Podman rootless, Usernetes y k3s. Un despliegue en producción requiere una validación más rigurosa, ya que la red, el almacenamiento y la gestión de servicios deben soportar condiciones operativas reales.

Si comienzas montando un entorno de pruebas, es una buena decisión. El funcionamiento del nodo rootless debe validarse con tus flujos reales de CNI, CSI, monitoreo, backup y actualización antes de adoptarlo como estándar para la capacidad productiva.

El centro de comparativas de Mr.PlanB resulta de ayuda al evaluar si una plataforma basada en Kubernetes debería absorber también cargas de trabajo basadas en máquinas virtuales. El modo rootless fortalece la postura de seguridad de Kubernetes, aunque determinar si Kubernetes representa el modelo operativo adecuado para cada carga de trabajo es una cuestión aparte.

¿Pueden los nodos rootless romper plugins de CNI o CSI?

Pueden hacerlo. Kubernetes advierte de que algunos controladores CNI y CSI dependen de privilegios de host que no se trasladan con limpieza a un user namespace. Esa es una de las razones principales para considerar el paso a beta como una ocasión de prueba y no como un mero visto bueno.

Los plugins de red pueden necesitar interactuar con interfaces del host, iptables, tablas de rutas, programas eBPF o namespaces. Los plugins de almacenamiento pueden requerir operaciones de montaje, acceso a dispositivos o rutas del sistema de archivos del host. Los user namespaces pueden modificar el comportamiento de esas operaciones.

Que un nodo alcance el estado Ready es solo la primera comprobación. Comprueba si tu plataforma completa sigue respondiendo ante la red de pods, volúmenes persistentes, reinicios de nodo, actualizaciones, monitoreo, copias de seguridad y recuperación ante caídas; un clúster rootless que supere una prueba rápida de cinco minutos pero falle en la recuperación del almacenamiento no está listo para producción.

¿Deberías habilitar kubelet rootless en producción ahora?

Yo comenzaría con un piloto representativo de producción en Kubernetes 1.37 antes de activarlo en toda la flota existente. La ganancia en seguridad es auténtica y el estado beta ofrece un motivo sólido para empezar a probarlo, pero la compatibilidad depende en gran medida de las cargas de trabajo y de los plugins utilizados.

Elige primero nodos con cargas de trabajo de menor riesgo. Verifica el comportamiento de CNI y CSI, el monitoreo, las copias de seguridad, el mantenimiento de nodos, las actualizaciones y cualquier DaemonSet con privilegios. Apóyate en la propiedad reportada del nodo rootless para controlar la programación de pods, asegurando que las cargas incompatibles se ubiquen en otra parte.

La opción contraria es la acertada cuando un componente esencial de red, almacenamiento, GPU u observabilidad todavía necesita privilegios reales de root en el host. En tal caso, conserva los nodos tradicionales, documenta el impedimento y revisa la función a medida que el ecosistema se ponga al día.

Kubernetes 1.37 mantiene los privilegios de root donde son imprescindibles, pero los hace mucho más delimitables, lo que supone un avance relevante de seguridad para una plataforma que históricamente ha confiado en componentes de nodo sumamente privilegiados.