Docker Security: Blindando tus contenedores contra la escalada de privilegios

La ejecución de contenedores Docker con el usuario root por defecto es una de las brechas de seguridad más comunes y críticas en entornos productivos. Con la sofisticación de los vectores de ataque, los actores maliciosos buscan activamente contenedores con privilegios excesivos para realizar escapes hacia el host (Container Escape).

Si un proceso dentro del contenedor se compromete y tiene privilegios de root, el atacante puede romper el aislamiento de los namespaces y obtener control administrativo sobre el sistema operativo anfitrión. La regla de oro en DevSecOps es aplicar estrictamente el principio de menor privilegio.

Ejemplo práctico: Restricción de Capabilities

No basta con usar la directiva USER en el Dockerfile; debes restringir las capacidades del kernel de Linux (Linux Capabilities) que se asignan al contenedor. Por defecto, Docker otorga capacidades como CAP_NET_RAW o CAP_SYS_ADMIN que raramente son necesarias para aplicaciones estándar.

Comando para ejecutar un contenedor reduciendo la superficie de ataque al mínimo:

$ docker run -d \
--name app-segura \
--user 1000:1000 \
--cap-drop ALL \
--cap-add NET_BIND_SERVICE \
--no-new-privileges \
--read-only \
--memory="512m" \
imagen-base:latest

Checklist de Hardening para tus contenedores:

• User Space: Define explícitamente un usuario no root (USER 1000) en el Dockerfile para que el proceso no inicie con ID 0.
• Flag –no-new-privileges: Impide que los procesos ganen nuevos privilegios a través de binarios setuid o setgid. Es fundamental.
• Flag –read-only: Monta el sistema de archivos raíz como de solo lectura. Obliga a usar volúmenes específicos para escrituras necesarias.
• Recursos: Limita el consumo con –memory y –cpus para mitigar ataques DoS.
• Capabilities: Usa –cap-drop ALL y añade solo las estrictamente necesarias (ej. NET_BIND_SERVICE si necesitas escuchar puertos bajos).

Mitigación y Monitoreo

La seguridad no termina en el despliegue. La mitigación efectiva implica integrar el escaneo de imágenes en el pipeline de CI/CD (utilizando herramientas como Trivy o Grype) para detectar CVEs antes de la ejecución.

A nivel de runtime, es imperativo monitorear llamadas al sistema (syscalls) sospechosas. Si un contenedor intenta ejecutar execve o modificar archivos en /etc sin autorización, herramientas como Wazuh o Falco deben alertar o terminar el proceso automáticamente. No confíes en la configuración por defecto del daemon de Docker.