Introducción
Cada vulnerabilidad de container breakout que se publica en el ecosistema Kubernetes comparte un patrón común: el atacante escala desde un contenedor comprometido hasta obtener privilegios root en el host. Históricamente, los CVEs asociados a runtimes CRI (containerd, CRI-O) y al propio kubelet permitían comprometer el kernel, reescribir el bootloader o alterar firmware del nodo. El daño no se limitaba al workload: se extendía a toda la infraestructura del cluster.
La promoción a beta del feature gate KubeletInUserNamespace en Kubernetes v1.37 ataca ese vector de raíz. Al ejecutar todos los componentes del nodo bajo un usuario no root dentro de un Linux user namespace, un ataque exitoso queda confinado a la cuenta UID 1000 del host. El atacante no puede modificar el kernel, el bootloader ni la firmware. No elimina la vulnerabilidad, pero cambia drásticamente el radio de explosión.
Qué ocurrió
El trabajo comenzó en 2018 como experimento en el proyecto Usernetes, mantenido por Akihiro Suda. Se formalizó como KEP-2033 y se fusionó en Kubernetes v1.22 (octubre de 2021) como feature gate alpha. Durante cuatro versiones, quedó en estado experimental con advertencias explícitas de incompatibilidad.
En v1.37, el Kubernetes Steering Committee promueve KubeletInUserNamespace a beta, lo que significa que viene habilitado por defecto en clusters nuevos y que el equipo de SIG Node considera el diseño suficientemente maduro para producción controlada. La promoción no introduce cambios arquitectónicos: el feature gate en sí es minimalista. Lo que cambia es el nivel de soporte y el compromiso del proyecto con la compatibilidad de CNI y CSI drivers bajo este esquema.
Es crítico no confundir esta función con UserNamespacesSupport (GA desde v1.36), que coloca los pods en user namespaces mediante hostUsers: false pero mantiene los componentes del nodo corriendo como root. Son mecanismos complementarios. Combinarlos permite anidar Kubernetes dentro de Kubernetes sin recurrir a privileged: true.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para equipos que operan clusters multi-tenant o bare-metal, el cambio reduce una capa entera de riesgo operativo. Los CVEs de container breakout (por ejemplo, CVE-2024-21626 en runc, que permitía escape a root del host) dejan de escalar a compromiso total del nodo si los componentes del kubelet operan dentro de un user namespace. El acceso al filesystem del host queda limitado al directorio del usuario no root.
En entornos cloud gestionados (EKS, GKE, AKS), el impacto directo es menor porque el proveedor administra los nodos. Pero para equipos que autogestionan infraestructura on-prem, edge computing, o clusters con compliance estricto (SOC 2, ISO 27001, regulaciones sectoriales), rootless mode aporta un control compensatorio documentable. Reduce la superficie de ataque sin requerir hardware dedicado ni hypervisor adicional.
El riesgo operativo real recae en compatibilidad. Algunos CNI plugins que requieren CAP_NET_ADMIN para crear interfaces virtuales, o CSI drivers que montan volúmenes con CAP_SYS_ADMIN, pueden fallar dentro de un user namespace. Los equipos deben validar sus plugins específicos antes de habilitar la beta en producción.
Detalles técnicos
El mecanismo es directo: un user namespace de Linux mapea un UID no root del host (típicamente UID 1000) a un UID 0 ficticio dentro del namespace. El kubelet, containerd o CRI-O, los binarios CNI y kube-proxy heredan ese namespace y ejecutan sus operaciones de mount, cgroups y network namespaces como «root» interno. El kernel aplica las restricciones del namespace: los privilegios del UID 0 interno no se propagan al host.
El feature gate KubeletInUserNamespace en sí resuelve dos problemas concretos que rompían el kubelet en modo rootless:
# sysctl values que el kubelet intenta escribir y fallan sin root real
vm.overcommit_memory = 1
kernel.panic = 10
# kubelet también intenta leer mensajes de kernel:
tail -f /dev/kmsg # Permission denied sin CAP_SYSLOG
Con el feature gate activo, el kubelet ignora silenciosamente estos errores de permisión. El resto de la operación (gestión de cgroups v2, creación de network namespaces para pods, mounting de volúmenes locales) funciona con el UID 0 interno del namespace.
El user namespace debe crearse fuera de Kubernetes. Las herramientas soportadas son:
# Con Podman (recomendado en v1.37)
podman play kube cluster.yaml
# Con kind en rootless Docker
kind create cluster –name rootless-test \
–config <(echo "kind: Cluster\napiVersion: kind.x-k8s.io/v1alpha4\nnodes:\n- role: control-plane")# Con Usernetes (multi-node con VXLAN/Flannel)
usernetes up
La combinación con UserNamespacesSupport (GA v1.36) habilita nesting: un cluster Kubernetes rootless corre dentro de un pod con hostUsers: false, sin privileged: true.
Qué deberían hacer los administradores y equipos técnicos
Primero, auditen sus CNI y CSI drivers actuales. Identifiquen cuáles requieren capabilities que no se propagan a través de user namespaces (CAP_SYS_ADMIN, CAP_NET_RAW, CAP_SYS_MODULE). Los drivers que montan volúmenes NFS o iSCSI con permisos de root en el host son los candidatos más propensos a fallar.
Segundo, en clusters de desarrollo y staging, habiliten la beta para validar compatibilidad:
# kubelet config (KubeletConfiguration)
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
KubeletInUserNamespace: true
UserNamespacesSupport: true # para nesting, si aplica
Tercero, complementen con seccomp. Los user namespaces no mitigan vulnerabilidades del kernel. Mantengan perfiles seccomp restrictivos (RuntimeDefault o perfiles personalizados) para eliminar syscalls innecesarios. La combinación user namespace + seccomp + AppArmor/SELinux forma una defensa en profundidad real.
Cuarto, si operan k3s en edge, verifiquen que la versión desplegada soporte rootless mode nativo (sin runtime externo). Para clusters multi-nodo rootless, Usernetes con Flannel sobre VXLAN es la opción probada, aunque con soporte comunitario.
Quinto, documenten la configuración para auditorías de seguridad. La promoción a beta implica que el equipo de SIG Node soportará la feature, pero los caveats de compatibilidad siguen siendo responsabilidad del operador.
Conclusión
Rootless mode no es una panacea de seguridad. No protege contra exploits del kernel Linux, y no elimina la necesidad de parcheo regular, segmentación de red y hardening estándar. Lo que hace es transformar un compromiso de root del host en un compromiso de usuario regular, y eso cambia radicalmente el tiempo de respuesta ante incidentes y el alcance forense.
La promoción a beta en v1.37 marca un punto de inflexión: cuatro años después de KEP-2033, el proyecto Kubernetes apuesta a que este modelo es viable para producción. La graduación a GA dependerá del volumen de despliegues reales y del feedback sobre compatibilidad de drivers. Para equipos que hoy operan clusters bare-metal o edge, es el momento de evaluar la transición en entornos no críticos.
Fuentes
- https://kubernetes.io/blog/2026/09/04/kubernetes-v1-37-rootless-beta/