El acceso al socket de Docker equivale a root en el host: lo que realmente otorga montarlo en un contenedor

Qué es

La documentación de seguridad de Docker indica que el daemon requiere privilegios de root salvo que se use el modo Rootless, y que solo debería permitirse controlarlo a usuarios de confianza. La razón que da: Docker permite compartir un directorio entre el host y el contenedor sin limitar los derechos de acceso del contenedor, de modo que se puede iniciar un contenedor con el / del host montado y alterar libremente el sistema de archivos del host.

El socket Unix /var/run/docker.sock es el canal de control habitual. Cualquiera que pueda escribir en él controla el daemon.

Por qué importa

Varias configuraciones habituales otorgan ese control sin decirlo:

• Montar el socket en un contenedor para que pueda gestionar otros contenedores (ejecutores de CI, paneles, proxies inversos que leen etiquetas, sandboxes de agentes que generan contenedores hermanos). Comprometer ese contenedor equivale a comprometer el host.
• El grupo docker: pertenecer a él equivale en la práctica a tener root en la máquina.
• La API por TCP sin autenticación de cliente TLS, que otorga lo mismo a cualquiera en la red.

Para los agentes, el socket resulta atractivo porque facilita «ejecutar esto en un contenedor»; también significa que el sandbox puede escapar de sí mismo con una sola llamada a la API.

Cómo aplicarlo

• Inventariar qué contenedores montan el socket: docker inspect sobre todos los contenedores y buscar la ruta del socket entre los montajes.
• Donde una herramienta solo necesite leer metadatos de contenedores, poner delante del socket un proxy de filtrado que permita únicamente los endpoints de solo lectura que necesita, y montar ese proxy en su lugar.
• Ejecutar los sandboxes de agentes que deban iniciar contenedores con modo Rootless, un daemon separado, o un límite de máquina virtual, en lugar de usar el daemon del host.
• Mantener el grupo docker tan reducido como la lista de sudoers, y revisar ambos juntos.
• Nunca exponer la API por TCP sin TLS mutuo; preferir el acceso al socket por SSH.

Trampas

• El montaje de solo lectura del socket (:ro): impide reemplazar el archivo del socket, no impide enviar solicitudes de API a través de él.
• Suponer que los espacios de nombres de usuario o un usuario no root dentro del contenedor ayudan; el daemon que actúa sobre la solicitud sigue siendo root.