Kubernetes v1.33 habilita los espacios de nombres de usuario por defecto para mejorar el aislamiento

En una publicación del blog de Kubernetes en abril de 2025, los mantenedores anunciaron que Kubernetes v1.33 habilita por defecto el soporte para espacios de nombres de usuario de Linux. Este cambio permite que los pods opten por un aislamiento más fuerte sin necesidad de flags de funcionalidad, siempre que la infraestructura subyacente cumpla con requisitos específicos del kernel y del runtime.

Qué ha ocurrido

Antes de esta versión, utilizar espacios de nombres de usuario en Kubernetes requería activar feature gates explícitos y navegar por pasos de configuración complejos. Con la versión 1.33, la funcionalidad es estable y está activa por defecto. Cuando se cumplen los requisitos de la pila tecnológica, los usuarios pueden simplemente optar por ella mediante las especificaciones de los pods. Este cambio marca un paso significativo hacia una orquestación de contenedores segura por defecto, reduciendo la fricción asociada con la implementación de modelos de seguridad de mínimo privilegio.

El anuncio aclara que esta es una funcionalidad exclusiva de Linux. Distingue entre los espacios de nombres de usuario de Linux, que aíslan los identificadores de usuario a nivel de kernel, y los namespaces de Kubernetes, que son agrupaciones lógicas de recursos. La actualización busca mitigar los riesgos asociados con los escapes de contenedor asegurando que los procesos que se ejecutan como root dentro de un contenedor no tengan privilegios de root en el nodo host.

Cómo funciona

Los espacios de nombres de usuario de Linux aíslan los IDs de usuario (UID) y los IDs de grupo (GID) de los procesos dentro de un contenedor respecto a los del sistema host. Cuando un pod utiliza un espacio de nombres de usuario, los UID y GID dentro del contenedor se mapean a identificadores diferentes y sin privilegios en el host. Por ejemplo, un proceso que se ejecuta como UID 0 (root) dentro del contenedor podría mapearse al UID 100000 en el host. Este mapeo garantiza que, incluso si un proceso del contenedor escapa de sus límites, carezca de los permisos para modificar archivos del host o interactuar con otros procesos del host como usuario privilegiado.

Este mecanismo depende en gran medida de los "idmap mounts", una característica del kernel de Linux que aplica mapeos de UID/GID al acceder a sistemas de archivos montados. Los idmap mounts permiten que cada pod utilice UID distintos en el host sin requerir cambios manuales en la propiedad de los archivos (chown) en los volúmenes. Esto simplifica la gestión de volúmenes y habilita funciones como compartir volúmenes entre pods con diferentes mapeos de usuario. Sin embargo, los sistemas de archivos utilizados para los volúmenes deben soportar idmap mounts. La mayoría de los sistemas de archivos comunes son compatibles, pero NFS destaca por su ausencia en las listas de soporte actuales.

Detalles clave

• Mecanismo de opt-in: Los usuarios habilitan la funcionalidad configurando hostUsers: false en la especificación del pod.
• Requisitos del kernel: Se recomienda una versión del kernel de Linux 6.3 o superior para soportar tmpfs para secrets y config maps. El kernel 5.19 es el mínimo para el soporte de overlayfs.
• Compatibilidad del runtime: Se requiere Containerd versión 2.0 o superior. CRI-O funciona directamente. Otros runtimes, incluido cri-dockerd, no soportan actualmente esta funcionalidad con Kubernetes.
• Beneficios de seguridad: Previene el movimiento lateral entre contenedores y asegura que las capacidades otorgadas dentro del namespace sean inválidas en el host.
• Limitaciones: Las aplicaciones que requieren privilegios directos del host, como la carga de módulos del kernel, no pueden usar espacios de nombres de usuario. Los volúmenes NFS no son compatibles con idmap mounts.

Por qué importa

Para ingenieros de software y equipos de plataforma, esta actualización aborda un dilema de seguridad de larga data: ejecutar aplicaciones como root dentro de los contenedores por compatibilidad mientras se intenta minimizar el riesgo en el host. Tradicionalmente, ejecutar como non-root requería refactorizaciones significativas de la aplicación o soluciones personalizadas complejas para gestionar permisos de archivos. Los espacios de nombres de usuario permiten a los equipos ejecutar aplicaciones como root internamente sin otorgar privilegios a nivel de host, desacoplando efectivamente la lógica de la aplicación de las restricciones de seguridad de la infraestructura.

La habilitación por defecto también fortalece la defensa contra vulnerabilidades de escape de contenedor. CVEs comunes, como CVE-2024-21626 y CVE-2022-0492, se mitigan porque los procesos escapados retienen solo identidades de host sin privilegios. Esto reduce la superficie de ataque para el movimiento lateral, donde un contenedor comprometido podría de otra manera acceder a archivos o procesos pertenecientes a otros contenedores en el mismo nodo. Al garantizar UID de host únicos para cada pod, el kubelet impone un aislamiento que previamente era difícil de lograr de manera consistente.

Qué puedes hacer

• Verifica que tus nodos cumplan los requisitos. Asegúrate de tener el kernel y el runtime adecuados.
• Actualiza tu stack tecnológico si es necesario para cumplir con los requisitos mínimos.
• Prueba la funcionalidad en entornos de desarrollo antes de implementarla en producción.
• Revisa tus especificaciones de pods para configurar hostUsers: false donde sea apropiado.
• Ten en cuenta las limitaciones con NFS y otras aplicaciones que requieren privilegios de host directos.