Kubernetes 1.37 pasa el modo rootless a beta

Kubernetes v1.37 pasa a beta el feature gate KubeletInUserNamespace. Con él activado, cada componente del nodo puede ejecutarse como un usuario corriente en lugar de root. Akihiro Suda, de NTT, anunció el cambio en el blog de Kubernetes el 4 de septiembre de 2026. La versión v1.37.0 salió el 26 de agosto de 2026.

La idea es limitar el daño. Si alguien se escapa de un contenedor, cae en una cuenta sin privilegios y no como root en la máquina.

Qué se ejecuta realmente sin root

Suda enumera cuatro tipos de componente de nodo que cubre la función:

• el kubelet
• los runtimes de contenedores CRI y OCI
• los plugins de red CNI
• kube-proxy

Todos ellos "can run as a non-root user on the host, using a Linux user namespace", escribe. "This technique is also known as rootless mode."

Un espacio de nombres de usuario es una función del núcleo de Linux. Un proceso se cree root dentro de su propio mundo, mientras el anfitrión lo sigue tratando como usuario corriente. Los privilegios son reales dentro y no existen fuera.

Ese es todo el argumento de seguridad. Suda expone el motivo sin rodeos: los componentes del nodo han "historically had container-breakout vulnerabilities that could compromise full root privileges on the host." Su entrada cita cinco.

• CVE-2022-0811
• CVE-2023-27561
• CVE-2024-10220
• CVE-2025-31133
• CVE-2026-53488

En modo rootless, una fuga por cualquiera de ellas alcanza una cuenta de usuario normal. No alcanza el root del anfitrión.

La distinción que mucha gente confundirá

Hay dos funciones distintas de espacios de nombres de usuario en Kubernetes, y se confunden con facilidad.

Suda traza la línea él mismo. El modo rootless "should not be confused with user namespaces for pods", escribe. Esa otra función se activa con hostUsers: false y el feature gate UserNamespacesSupport. Está disponible de forma general desde la v1.36. Esa función "puts pods in user namespaces but still runs the node components as root."

Así que una mete tus cargas de trabajo en un espacio de nombres. La otra mete la maquinaria. Resuelven mitades distintas del mismo problema, y la entrada dice que pueden combinarse.

Siete años del experimento a la beta

Esta función ha avanzado despacio, y las fechas dicen algo sobre su dificultad.

Etapa	Cuándo
Primer experimento	2018
Alfa, como KEP-2033	v1.22, en 2021
Beta	v1.37, en 2026

Entre la alfa y la beta pasaron cinco años. Ejecutar el kubelet sin root toca a la vez los runtimes de contenedores, los plugins de red y la gestión de cgroups, y cada uno tuvo que desarrollar su propio soporte.

Un KEP es una Kubernetes Enhancement Proposal, el documento de diseño escrito por el que debe pasar un cambio así. Es la misma forma de proceso que GNOME está redactando para sí mismo.

Qué significa esto para los desarrolladores

Comprueba primero quién ejecuta tu kubelet. Si usas un servicio gestionado como EKS, GKE o AKS, ese proceso no lo controlas tú y esta función no está a tu alcance. Importa sobre todo a quien administra sus propios nodos, monta un clúster de pruebas o despliega en el borde.

Lee el anuncio y sus requisitos antes de probar. El modo rootless se apoya en comportamientos concretos del núcleo, versiones concretas de runtime y delegación de cgroups, y la entrada de Suda es donde están esos detalles. No des por hecho que tu imagen de nodo actual sirve.

Trata la beta como una beta. En Kubernetes eso significa que la forma de la API está bastante asentada pero los bordes operativos no, y que los feature gates aún pueden cambiar sus valores por defecto entre versiones. Ejecútalo donde puedas permitirte perderlo.

La conclusión útil vale aunque nunca lo actives. Pregúntate qué alcanza hoy una fuga de contenedor en tus nodos. Para la mayoría de clústeres la respuesta honesta es el root del anfitrión, y esa respuesta pasa a ser una decisión en lugar de algo dado.