- Diferencias fundamentales entre la ejecución rootful y rootless para blindar el sistema anfitrión.
- Técnicas de hardening mediante la eliminación de capacidades del kernel y el uso de sistemas de archivos de solo lectura.
- Gestión de namespaces de usuario y mapeo de IDs para aislar procesos en entornos restringidos.
- Estrategias de seguridad en la cadena de suministro y monitorización en tiempo real de los contenedores.
A estas alturas, casi cualquier equipo de desarrollo utiliza contenedores para desplegar sus aplicaciones. Sin embargo, hay una asignatura pendiente que muchos pasan por alto: la seguridad real. Lanzar un servicio con la configuración por defecto suele ser el camino más corto, pero también el más peligroso, ya que dejar los contenedores abiertos puede convertir un pequeño fallo de código en un desastre total para la infraestructura del servidor.
La clave para no dormirnos en los laureles está en entender que el aislamiento no es magia, sino una configuración precisa. Desde el uso de usuarios no privilegiados hasta el control exhaustivo de las llamadas al kernel, reducir la superficie de ataque es la única forma de garantizar que, si un atacante logra entrar en un contenedor, se encuentre con un muro infranqueable que le impida saltar al sistema anfitrión.
Podman y el dilema entre Rootful y Rootless
Cuando hablamos de Podman, nos encontramos con dos filosofías de ejecución muy distintas. Por un lado, el modo contenedor rootful es el clásico: el proceso se lanza con el usuario root del host. Esto significa que el contenedor tiene un poder absoluto sobre el sistema, lo que es una bomba de relojería si existe alguna vulnerabilidad que permita al atacante escalar privilegios.
Para evitar estos sustos, existe el modo contenedor rootless. Aquí, el motor no requiere un demonio con superpoderes para funcionar. Es fundamental entender que, aunque dentro del contenedor el usuario parezca ser root, en la realidad del host es un usuario sin privilegios. Esto crea una barrera de seguridad brutal, ya que cualquier brecha se queda encerrada en el contexto del usuario limitado.
Eso sí, no todo es color de rosa con el modo rootless, ya que vienen con algunas limitaciones técnicas que debemos gestionar. Por ejemplo, no podemos abrir puertos privilegiados (aquellos menores de 1024) y algunas funciones de red, como hacer ping a servidores externos, pueden dar guerra si no se configuran correctamente. Para solventar lo de los puertos, la solución es simple: mapear puertos altos, como el 8080, hacia el puerto interno del servicio.
El secreto de los Namespaces y el mapeo de IDs
Para que un usuario normal del host pueda actuar como root dentro de un contenedor sin romper el sistema, Linux utiliza los espacios de nombres de usuario (user namespaces). Esta tecnología permite que el kernel asigne un rango de IDs aislados, creando una correspondencia entre los UID del contenedor y los del host.
Si echamos un vistazo a los archivos /etc/subuid y /etc/subgid, veremos que cada usuario tiene asignado un rango de identificadores. Por ejemplo, un usuario con UID 1000 puede mapear miles de IDs adicionales. Esto significa que cuando ejecutamos un proceso como el usuario ‘sync’ (UID 5) dentro del contenedor, el host lo ve como un UID muy elevado y sin permisos, manteniendo el sistema totalmente a salvo.
Si necesitamos investigar qué está pasando bajo el capó sin necesidad de lanzar un contenedor entero, podemos recurrir al comando podman unshare. Esta herramienta nos permite entrar en el espacio de nombres del usuario para inspeccionar el mapa de IDs y verificar que el aislamiento está funcionando como debería.
Hardening de Docker: Blindando la ejecución
Si tu entorno es Docker, la estrategia de seguridad debe ser agresiva. El primer paso es aplicar el principio de mínimo privilegio. No permitas que el contenedor haga más de lo estrictamente necesario. Una configuración potente implica lanzar la imagen con la opción –read-only, lo que convierte el sistema de archivos en solo lectura y evita que un atacante instale malware o modifique binarios.
Además, es vital limpiar las capacidades del kernel. Usando –cap-drop ALL, le quitamos al contenedor cualquier permiso especial, y si necesita alguno concreto (como abrir un puerto específico), se lo devolvemos con –cap-add. Sumando esto a la opción –security-opt no-new-privileges, bloqueamos cualquier intento de escalada de privilegios dentro del proceso.
Para quienes gestionan despliegues más complejos, lo ideal es volcar todo esto en el archivo compose.yaml. Definir límites de procesos con pids_limit y restringir el uso de CPU y memoria evita que un contenedor mal comportado o bajo ataque consuma todos los recursos del servidor, provocando una denegación de servicio en el resto de las aplicaciones.
Seguridad en la imagen y la cadena de suministro
De nada sirve tener un entorno de ejecución blindado si la imagen que descargamos es un colador. La base de todo es utilizar imágenes oficiales y ligeras. En lugar de usar una distribución completa de Ubuntu, es mucho más sensato optar por versiones slim o Alpine Linux, que reducen drásticamente la cantidad de herramientas instaladas que un atacante podría usar.
Un error garrafal es dejar que la aplicación corra como root dentro del Dockerfile. Lo correcto es crear un usuario específico mediante la instrucción RUN adduser y luego cambiar el contexto con la directiva USER. De este modo, la aplicación nunca toca el sistema con permisos de administrador, independientemente de cómo se lance el contenedor.
Para cerrar el círculo, es imprescindible implementar un escaneo de vulnerabilidades automatizado en la pipeline de CI/CD. Herramientas que analicen las capas de la imagen antes de que lleguen al registry evitan que despliegues código con fallos críticos conocidos. La seguridad no es un paso final, sino que debe estar integrada en todo el ciclo de vida del software.
Gestión de accesos y monitorización avanzada
En entornos donde varios desarrolladores necesitan usar Docker, la tentación es darles permisos de root. Una alternativa más limpia es añadir a los usuarios al grupo docker mediante usermod -aG docker. No obstante, hay que ser conscientes de que esto otorga un poder considerable, por lo que es recomendable ajustar los permisos del socket de docker de forma quirúrgica.
Para una protección de nivel empresarial, no basta con la configuración estática. Es necesario implementar perfiles Seccomp, AppArmor o SELinux. Estos mecanismos actúan como un portero que filtra las llamadas al sistema que el contenedor intenta hacer al kernel de Linux, bloqueando cualquier petición sospechosa o no autorizada.
La última pieza del puzle es la visibilidad en tiempo real. Dado que los contenedores son efímeros, los logs tradicionales se quedan cortos. Es fundamental centralizar los registros y utilizar herramientas de monitorización que detecten comportamientos anómalos, como procesos extraños que aparecen de la nada o intentos de conexión a redes externas no permitidas.
La seguridad en la virtualización a nivel de sistema operativo depende de una combinación de higiene en las imágenes, restricciones estrictas en la ejecución y una vigilancia constante. Al combinar el uso de usuarios no privilegiados, el mapeo inteligente de IDs y la eliminación de capacidades innecesarias del kernel, logramos que la infraestructura sea resiliente y que cualquier posible intrusión quede totalmente neutralizada sin afectar al rendimiento de las aplicaciones.
Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.