¿Qué son los Linux Namespaces?

Los Linux Namespaces son una función del kernel que muestra recursos globales como si cada grupo de procesos tuviera su propia instancia. Un proceso en un namespace de red, por ejemplo, puede ver interfaces y rutas distintas de las que ve otro proceso del host. Esta separación selectiva es una de las piezas que permiten crear contenedores.

No arrancan otra máquina ni otro kernel. Los procesos siguen usando el kernel del sistema, pero este limita qué identificadores y recursos observa cada uno según sus namespaces. Una carga puede tener una red separada y compartir con el host otros ámbitos que el runtime haya dejado comunes.

Esa separación no es una certificación de seguridad. Los namespaces aíslan aspectos concretos; los permisos, el consumo de recursos y otras defensas requieren controles adicionales. Saber qué separa cada tipo ayuda a evitar suposiciones peligrosas sobre lo que sigue compartido.

Un tipo de namespace para cada ámbito

Cada tipo controla una parte distinta del sistema. El namespace de montajes presenta otra vista de los puntos de montaje; el de PID cambia los identificadores de procesos; el de red aísla interfaces, rutas y sockets; y el de IPC separa mecanismos de comunicación entre procesos, como colas y memoria compartida.

Otros tipos cambian nombres o identidades visibles. El UTS permite un hostname propio. El namespace de usuario mapea UID y GID y delimita dónde tienen efecto ciertas capacidades: un proceso puede ser UID 0 dentro de ese ámbito sin convertirse por ello en root del host. El resultado depende de los mapeos y permisos configurados.

Los namespaces de cgroup y de tiempo modifican otras vistas. El primero cambia cómo se presenta la jerarquía de cgroups; no aplica por sí solo cuotas de CPU o memoria. El segundo permite desplazar ciertos relojes monotónicos y de arranque, pero no crea un reloj de pared independiente. La disponibilidad exacta depende del kernel.

-InfraCrew dice: Antes de hablar de «un contenedor», conviene preguntar qué comparte con el host.-

Cómo se crean y se observan

El kernel ofrece llamadas para crear ámbitos nuevos o cambiar de pertenencia. clone() puede iniciar un proceso hijo dentro de namespaces nuevos; unshare() crea uno o varios para el proceso que lo invoca; y setns() permite unirse a uno existente, tras superar las comprobaciones de permisos y las restricciones del tipo correspondiente.

La pertenencia se puede inspeccionar en /proc/PID/ns/. Sus enlaces simbólicos representan los namespaces de un proceso. Herramientas como lsns ayudan a inventariar los ámbitos visibles; nsenter ejecuta una orden dentro de algunos de ellos, por lo que requiere revisar con cuidado los privilegios otorgados.

Los namespaces pueden anidarse y conservar referencias propias. En uno de PID, un proceso puede tener identificadores distintos según el nivel desde el que se observe. Además, un descriptor abierto o un montaje que retenga su referencia puede mantener vivo un namespace cuando ya no quedan procesos en él; terminar una carga no siempre elimina todas sus referencias.

-InfraCrew dice: Un PID sin su namespace de referencia cuenta solo media historia.-

Contenedores, Kubernetes y límites reales

Los motores de contenedores combinan namespaces con otras funciones del kernel. Una carga puede recibir ámbitos propios de red, montaje y PID, mientras comparte otros con el host o con procesos cercanos. Qué se crea y qué se comparte depende del runtime, su versión y sus opciones.

El objeto Namespace de Kubernetes pertenece a otra capa. Sirve para delimitar nombres y grupos de recursos de un clúster; no equivale al namespace de Linux del kernel. Los pods y el runtime sí participan en la configuración del aislamiento del sistema operativo, pero un objeto de Kubernetes no crea por sí solo una nueva frontera de kernel.

Los namespaces tampoco limitan cuánto consume una aplicación. Para controlar CPU y memoria se usan cgroups; seccomp restringe llamadas al sistema, y las capacidades y controles como SELinux o AppArmor acotan otras operaciones. El aislamiento resulta de combinar y revisar estas capas, no de activar una única opción.

Qué revisar antes de desplegar

Empieza con una matriz de recursos compartidos. Anota si cada carga necesita PID, red, espacio de montaje, hostname e identidad propios, y justifica las excepciones. Después valida el comportamiento del runtime instalado: los nombres de una opción no garantizan que todas las versiones produzcan el mismo aislamiento.

Comprueba los mapeos UID/GID y la propiedad de los archivos. En volúmenes compartidos, una configuración incorrecta puede dar acceso inesperado. UID 0 dentro de un user namespace no otorga privilegios generales en el host, pero eso no elimina el riesgo de capacidades innecesarias o montajes con permisos demasiado amplios.

En la red, documenta qué conectividad debe existir. Un namespace separado puede necesitar interfaces virtuales, rutas y reglas para comunicarse con otros ámbitos; la separación no decide por sí sola qué tráfico debe permitirse. Prueba los flujos requeridos y los que deben permanecer bloqueados.

Trata los namespaces como una capa de aislamiento, no como una garantía completa. Mantén el kernel actualizado, aplica mínimo privilegio, usa cgroups para límites y revisa montajes y políticas de acceso. Si las cargas no deben compartir el riesgo del kernel, valora una frontera más fuerte, como una máquina virtual.

-InfraCrew dice: La frontera más útil es la que puedes explicar, comprobar y volver a crear.-

Diccionario de la Crew

Kernel — Núcleo del sistema operativo que administra procesos, memoria y dispositivos.

UID/GID — Identificadores de usuario y grupo que Linux usa para representar credenciales.

Cgroup — Mecanismo del kernel para organizar y contabilizar recursos utilizados por procesos.

Fuentes

Linux man-pages project — namespaces(7) | https://man7.org/linux/man-pages/man7/namespaces.7.html
Kubernetes Documentation — Namespaces | https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/