Una de las configuraciones más críticas y frecuentemente mal gestionadas en entornos de contenedores es el montaje del socket de Docker (/var/run/docker.sock) dentro de un contenedor. Si tu arquitectura depende de esto para que herramientas de CI/CD, monitoreo o agentes de logs interactúen con el daemon, podrías estar exponiendo todo tu host a un compromiso total.
El Problema Técnico
El socket de Docker es el punto de entrada de la API del daemon. Por diseño, el daemon de Docker opera con privilegios de root en el host. Si un atacante compromete un contenedor que tiene este socket montado —incluso si el proceso dentro del contenedor corre como un usuario sin privilegios—, puede enviar comandos a la API de Docker de forma directa.
Esto permite a un atacante:
- Listar, detener o borrar contenedores existentes.
- Lanzar nuevos contenedores con privilegios elevados (–privileged) o montar directorios sensibles del host (como /, /etc o /root) dentro de un nuevo contenedor para manipular el sistema de archivos del host.
- Ejecutar comandos arbitrarios en el host, evadiendo las restricciones de seccomp o apparmor.
Es, en esencia, una escalada de privilegios trivial. El hecho de que el contenedor corra como un usuario no root es irrelevante si el socket tiene permisos de escritura, ya que el atacante controla al daemon que gestiona la infraestructura.
Auditoría Rápida
Para verificar qué contenedores en tu infraestructura actual están montando este socket, ejecuta este comando en el host:
$ docker ps --quiet | xargs docker inspect --format '{{.Id}}: {{.Mounts}}' | grep '/var/run/docker.sock'Si el comando devuelve algún ID de contenedor, es momento de auditar esa implementación inmediatamente.
Mitigación y Buenas Prácticas
- Eliminar el montaje: Evalúa si es realmente necesario. Busca alternativas como el uso de la API REST de Docker (protegida con TLS) o arquitecturas desacopladas.
- Docker Socket Proxy: Si el montaje es indispensable, utiliza [docker-socket-proxy]([enlace eliminado]). Este componente actúa como un intermediario que filtra qué comandos puede recibir el daemon, limitando el acceso a endpoints específicos (por ejemplo, permitir solo operaciones GET y bloquear operaciones POST, DELETE o de creación de contenedores).
- User Namespaces: Implementa Docker User Namespaces para mapear el usuario root dentro del contenedor a un usuario sin privilegios en el host, añadiendo una capa de aislamiento adicional.
¿Cuántos de ustedes todavía tienen montado el socket en sus entornos de producción por «comodidad» o por falta de tiempo para implementar una arquitectura más segura? ¿Cuál ha sido su mayor desafío al intentar segurizar Docker en entornos altamente dinámicos?
0 comentarios