Puede ejecutar Docker en producción durante meses sin ningún problema visible. Los contenedores se inician, las aplicaciones responden, nada se rompe. Entonces, un puerto expuesto o un permiso mal configurado crean un punto de apoyo que el atacante no tenía que conseguir. La mayoría de los errores de seguridad de Docker no parecen errores hasta que algo sale mal.
Este artículo cubre las configuraciones específicas que ponen en riesgo los entornos de contenedores, lo que cada una permite para un atacante y cierra con una lista de verificación que puede ejecutar con su propia configuración hoy.
Por qué la seguridad de Docker es más difícil de lo que parece
Los contenedores se sienten aislados. Inicias uno, ejecuta su propio espacio de proceso y, desde su interior, el siguiente contenedor no existe. Obtienes aislamiento, pero es sólo parcial. Los contenedores comparten el núcleo del host, lo que significa que un proceso dentro de un contenedor puede, bajo condiciones específicas, llegar al sistema host por completo.
Los barcos Docker están configurados para comodidad de los desarrolladores, no para reforzar la producción. Acceso root activado. Todos los puertos se pueden vincular a todas las interfaces. Sin supervisión del tiempo de ejecución. La mayoría de los desarrolladores aceptan esas configuraciones, envían el contenedor y siguen adelante. Ése es un enfoque razonable para empezar; no es una postura de seguridad terminada.
De acuerdo a Informe de seguridad sobre el estado de Kubernetes 2024 de Red Hat, el 67% de las organizaciones retrasaron o ralentizaron la implementación de aplicaciones debido a problemas de seguridad de contenedores o Kubernetes. Esa fricción generalmente no se debe a ataques. Se debe a que los equipos descubren que las configuraciones de sus contenedores necesitaban un refuerzo que no habían incorporado.
A menudo vemos contenedores ejecutándose en producción con la misma configuración que tenían en la máquina local de un desarrollador. Ahí es donde los errores de seguridad de Docker tienden a agravarse silenciosamente, sin síntomas visibles hasta que algo se audita o falla.
Los errores que crean esas brechas son específicos, predecibles y en su mayoría evitables, comenzando en el nivel de configuración.
Errores comunes de configuración de Docker
La mayoría de las infracciones de contenedores no comienzan con un exploit de día cero. Comienzan con una configuración establecida el primer día, sin pensar mucho en la exposición de la red o el alcance de los privilegios.
La configuración predeterminada de Docker está diseñada para funcionar. La brecha entre lo funcional y lo seguro es donde se acumulan los riesgos de seguridad de los contenedores Docker, especialmente en configuraciones autohospedadas que se implementan y nunca se revisan.
Vemos este patrón a menudo: contenedores en servidores de IP pública con enlaces de puertos, configuraciones de usuario y configuraciones de red exactamente como estaban en la implementación inicial.
Ejecutar contenedores como raíz
Cuando inicia un contenedor Docker sin especificar un usuario, se ejecuta como root. Eso significa que cualquier proceso dentro del contenedor, incluida su aplicación, tiene privilegios de nivel raíz dentro del espacio de nombres del contenedor.
La raíz dentro de un contenedor no es lo mismo que la raíz en el host, pero la separación no es absoluta. Los exploits de escalada de privilegios dirigidos al tiempo de ejecución, como el bien documentado runc CVE-2019-5736 y fallas de tiempo de ejecución similares, con frecuencia requieren un proceso contenedor raíz para tener éxito.
Los contenedores no raíz eliminan el requisito del proceso raíz del que dependen esos exploits, lo que reduce significativamente la superficie de ataque para esa clase de vulnerabilidad, aunque no eliminan por completo el riesgo de escape del contenedor.
Agregar una directiva USER a su Dockerfile soluciona esto. Algunas imágenes oficiales se envían con un usuario sin privilegios que puede activar con una directiva de USUARIO, pero muchas aún funcionan como root de forma predeterminada sin un usuario de aplicación listo para usar. En esos casos, crea el usuario en Dockerfile antes de cambiar a él. Para la mayoría de las configuraciones autohospedadas, este único cambio elimina una categoría completa de riesgo de escalada.
Exponer demasiados puertos a la Internet pública
Cuando publica un puerto con Docker, Docker escribe sus propias reglas de iptables directamente. Esas reglas se ejecutan antes que las reglas de firewall a nivel de host. Este es un Comportamiento bien conocido reportado por la comunidad. y documentado en la guía de filtrado de paquetes de Docker, no es una mala configuración, y significa que UFW y herramientas similares no bloquean lo que Docker ya ha abierto.
Docker escribe directamente en iptables, evitando los valores predeterminados de UFW y firewalld en muchos hosts Linux. Eso significa que un puerto vinculado a 0.0.0.0 puede ser accesible públicamente incluso cuando su firewall parezca configurado. Los grupos de seguridad de la nube y las reglas de la cadena DOCKER-USER aún pueden bloquear ese tráfico, por lo que la exposición real depende de la configuración de su red específica.
Vincule los servicios a 127.0.0.1 siempre que sea posible, enrute el tráfico público a través de un proxy inverso y publique solo lo que realmente requiera acceso externo. Un proxy inverso es la forma más confiable de controlar lo que se expone desde fuera del host.
Ignorar el aislamiento de red entre contenedores
Cualquier contenedor de esa red puede llegar a cualquier otro contenedor de ella sin restricciones. El puente predeterminado no aplica ningún filtrado de tráfico entre los contenedores que lo comparten y la mayoría de las configuraciones nunca cambian esa configuración.
Si un contenedor se ve comprometido, esa comunicación abierta se convierte en una ruta de movimiento lateral. Un contenedor frontend puede acceder a una base de datos, una API interna o cualquier otra cosa en la misma red puente predeterminada, incluso cuando ese acceso nunca fue previsto.
Las redes definidas por el usuario le brindan control explícito sobre qué contenedores pueden comunicarse, pero una única red personalizada compartida por todos sus servicios aún permite el tráfico gratuito entre contenedores. El verdadero aislamiento requiere colocar servicios que no deberían comunicarse entre sí en redes separadas. Desactivar el puente predeterminado es el punto de partida, no la línea de meta.
Vista del zócalo Docker
El socket Docker en /var/run/docker.sock es la interfaz de control para todo el motor Docker. Montarlo en un contenedor le da a ese contenedor acceso API directo al demonio que se ejecuta en el host.
Con ese acceso, un contenedor puede iniciar nuevos contenedores, montar directorios de host, inspeccionar y modificar contenedores en ejecución y controlar eficazmente la máquina host. La superficie de ataque es equivalente a la raíz del host, por lo que cualquier herramienta que requiera acceso a sockets merece una evaluación cuidadosa.
Para la mayoría de los casos de uso, existen alternativas más seguras: API con alcance o Herramientas de gestión de Docker que no requieren acceso al socket. Docker-in-Docker conlleva sus propias compensaciones operativas y de seguridad y no es un sustituto sencillo.
Los errores de configuración crean la exposición inicial. Las elecciones de imagen y dependencia determinan cómo esa exposición se agrava con el tiempo.
Errores de imagen y secretos que duran más que el contenedor
Cuando detienes un contenedor, los errores de configuración dentro de él terminan con él. Cuando se reconstruye a partir de una imagen que contiene una vulnerabilidad o una credencial codificada, el problema se reinicia con el contenedor. Los errores a nivel de imagen no se restablecen entre implementaciones.
Viajan con la imagen a cada entorno que la genera, a cada registro que la almacena y a cada miembro del equipo que la ejecuta. Esa persistencia hace que la gestión de imágenes y secretos sea una categoría distinta de riesgo, que vale la pena auditar por separado de la configuración.
Vemos este patrón a menudo: una imagen elegida cuidadosamente al inicio del proyecto y nunca reconstruida desde entonces, alejándose lentamente de la línea base de seguridad que representaba inicialmente.
Uso de imágenes obsoletas o que no son de confianza
Los registros públicos están abiertos a cualquier persona. Se han distribuido imágenes maliciosas a través de Docker Hub que contienen criptomineros y puertas traseras incrustadas en el historial de capas que persisten tras los reinicios del contenedor. La verificación antes de retirar es importante, especialmente para imágenes de editores no oficiales o desconocidos.
El problema aparte es el estancamiento. Una imagen oficial que extrajiste hace seis meses y que nunca reconstruiste desde entonces ha estado acumulando vulnerabilidades de Docker sin parches con cada CVE divulgado en sus paquetes. La imagen no está rota. Simplemente ya no es actual.
Informe de Sonatype sobre el estado de la cadena de suministro de software 2024 descubrió que el 95% de las veces que se consume un componente vulnerable, ya hay una versión reparada disponible y el 80% de las dependencias de las aplicaciones permanecen sin actualizar durante más de un año. Ese patrón también es relevante para las imágenes base de Docker, ya que dependen de los mismos paquetes de código abierto.
Utilice imágenes oficiales de editores verificados y fije etiquetas de versión específicas en lugar de depender de la "última". Cree una cadencia de reconstrucción regular para mantener sus imágenes actualizadas.
Secretos de codificación en Dockerfiles y Compose Files
Las credenciales escritas en una instrucción Dockerfile ENV o ARG, codificadas en un bloque de entorno Compose, pasadas como argumentos de compilación o almacenadas en un archivo .env comprometido para el control de versiones no desaparecen cuando se detiene el contenedor. Permanecen en el historial de la capa de imagen o en el control de fuente, accesibles para cualquiera que pueda acceder a cualquiera de ellos.
Este es uno de los errores de seguridad de Docker que más se pasa por alto porque no causa problemas visibles durante el desarrollo. Una clave API en una instrucción ENV funciona correctamente. También está en su repositorio, integrado en su imagen y distribuido dondequiera que viaje esa imagen.
Modern Docker Compose admite un mecanismo de secretos nativos que monta las credenciales en tiempo de ejecución sin incorporarlas a la imagen. La API de secretos de Docker y los administradores de secretos externos siguen el mismo principio. Estas son las opciones que mantienen las credenciales completamente fuera de los artefactos de compilación y los archivos confirmados.
Las variables del entorno de ejecución son una mejora con respecto a las credenciales codificadas, pero aún están expuestas a través de la inspección de salida de Docker, los registros y los volcados de memoria. Son un paso adelante respecto de los secretos incorporados, no una solución terminada.
No actualizar las imágenes del contenedor con regularidad
Ejecutar la misma imagen durante meses es un hábito común. Cada día que pasa después de que se revela una nueva vulnerabilidad, pero antes de reconstruir, sus contenedores tienen una ventana de exposición que crece sin ningún cambio visible.
Cree un cronograma de reconstrucción consistente. Automatice ese proceso siempre que sea posible y ejecute periódicamente un escáner de vulnerabilidades en sus imágenes actuales. El objetivo no es la perfección. Está reduciendo el tiempo entre el lanzamiento de un parche y su implementación.
El control de acceso y la supervisión pueden perder prioridad en implementaciones rápidas. También son las categorías en las que los incidentes pasan desapercibidos por más tiempo.
Control de acceso y brechas de visibilidad
Después de que un contenedor se ejecuta con una configuración sólida e imágenes actuales, quedan dos categorías de fallas. Ambos son invisibles por naturaleza: no notarás un problema de control de acceso débil hasta que alguien lo use, y no notarás una brecha en el monitoreo hasta que necesites investigar una actividad que nunca se registró.
Lo mismo Investigación de Red Hat 2024 descubrió que el 42% de los equipos carecían de capacidades suficientes para abordar la seguridad de los contenedores y las amenazas relacionadas.
Descubrimos que las lagunas en el seguimiento suelen surgir durante las investigaciones de incidentes, no antes. Cuando la visibilidad se convierte en una prioridad, a menudo responde a algo en lugar de prevenirlo.
Autenticación débil y paneles de administración expuestos
Un panel de administración de contenedores en una IP pública sin autenticación no requiere un atacante sofisticado. Les exige que sepan la dirección. Ese es un listón más bajo de lo que la mayoría de los equipos creen.
Las herramientas de monitoreo y administración autohospedadas generalmente vienen con una interfaz web accesible en todas las interfaces de red. Dejarlos en una IP pública sin autenticación delante de ellos es el equivalente en contenedor a dejar un panel de administración desbloqueado.
La autenticación, un proxy inverso y la ubicación de una red privada son la base. El control de acceso es un paso de configuración que se agrega a cualquier interfaz de administración, no algo que se envía habilitado.
El mismo principio se aplica a Gestión de CLI y GUI de Docker; El acceso a nivel de administrador al demonio conlleva el mismo riesgo independientemente de la interfaz.
No monitorear lo que están haciendo sus contenedores
Si un contenedor se ve comprometido, la actividad del atacante crea un rastro: cambios en el comportamiento del proceso, conexiones de red inusuales y modificaciones inesperadas de los archivos. Sin la recopilación de registros, ese rastro no existe en una forma en la que puedas actuar.
La recopilación de registros centralizados, el registro de auditoría de contenedores y las herramientas de monitoreo del tiempo de ejecución le brindan los datos para detectar actividad anormal antes de que se agrave. El objetivo no es analizar cada línea. Es tener los datos disponibles cuando necesitas investigar.
Las configuraciones de contenedores que se ejecutan silenciosamente en producción, sin canalización de registros y sin alertas, no requieren poco mantenimiento. No están inspeccionados. Esos son dos estados operativos diferentes.
Por qué también es importante el entorno de infraestructura
La seguridad de los contenedores comienza con la configuración, pero la configuración se ejecuta por encima de la infraestructura. Un host con redes mal configuradas, recursos compartidos o sin filtrado a nivel de red crea condiciones que afectan a todos los contenedores que se encuentran encima de él. Lograr la configuración correcta del contenedor y la configuración correcta del servidor son dos tareas separadas.
Muchas brechas de seguridad de Docker se ven amplificadas por condiciones que heredan los propios contenedores:
- Un servidor de arrendamiento compartido sin aislamiento de hardware entre inquilinos
- Un kernel de host que se ejecuta sin parches
- Un host sin filtrado a nivel de red incorporado
Esto no elimina la necesidad de seguir los pasos de configuración anteriores, ya que la protección adecuada del contenedor es importante independientemente de la capa de infraestructura. Comenzar con una infraestructura aislada elimina una capa de preocupación de la ecuación.
En Cloudzy, ofrecemos dos caminos dependiendo de lo que requiera su configuración:
- VPS Linux: un entorno limpio para implementar Docker usted mismo y aplicar los pasos de refuerzo de este artículo
- VPS portainer: una opción de un clic con Portainer preinstalado; El servidor arranca y ya estás en el panel.
Ambas opciones se ejecutan en la misma infraestructura: virtualización KVM, CPU AMD Ryzen 9 con reloj de aumento de hasta 5,7 GHz, memoria DDR5, almacenamiento SSD NVMe, red de hasta 40 Gbps y protección DDoS gratuita a través del filtrado BuyVM, en 12 ubicaciones globales con un SLA de tiempo de actividad del 99,95 %.
Para una visión más profunda de cómo ejecutar Portainer en un VPS, lo cubrimos en un artículo dedicado.
Una lista de verificación de seguridad práctica para implementaciones de Docker
Los errores de seguridad de Docker mencionados anteriormente provienen principalmente de decisiones de configuración únicas tomadas una vez y nunca revisadas. Al ejecutar esta lista de verificación con una configuración existente se detectan esas brechas. Funciona como una auditoría, no como una guía de implementación.
Estas mejores prácticas de seguridad de Docker cubren cómo proteger los contenedores de Docker contra los errores de configuración más comunes descritos anteriormente.
Referencia rápida: los 9 errores
| Error | Categoría | Solución de una sola línea |
| Ejecutando como root | Configuración | Agregar USUARIO directiva a su Dockerfile |
| Puertos vinculados a 0.0.0.0 | Configuración | Vincularse a 127.0.0.1 y enrutarse a través de un proxy inverso |
| Sin aislamiento de red | Configuración | Divida los servicios en redes separadas definidas por el usuario según las necesidades de acceso. |
| Conector Docker montado | Configuración | Retire el soporte; utilizar API con ámbito o alternativas |
| Imágenes no confiables o desactualizadas | Imagen | Utilice imágenes oficiales con etiquetas de versión fijadas |
| Secretos codificados | Imagen | Mover credenciales a entornos de ejecución o a un administrador de secretos |
| No hay programa de reconstrucción de imágenes | Imagen | Establecer una cadencia de reconstrucción mensual; automatizar cuando sea posible |
| Paneles de control no autenticados | Acceso | Agregue autenticación y mueva UI de administración a redes privadas |
| Sin recopilación de registros de contenedor | Acceso | Configurar el registro centralizado y la supervisión del tiempo de ejecución |
Recomendamos ejecutarlo primero con configuraciones existentes, ya que ahí es donde es más probable que ya estén presentes las brechas.
Contenedores que se ejecutan como no root: Verifique sus Dockerfiles para ver si hay una directiva de USUARIO. Si no existe ninguno, el contenedor se ejecuta como root.
Enlaces de puertos limitados a localhost o proxy: Ejecute docker ps y revise los enlaces de puertos. Se puede acceder públicamente a una entrada 0.0.0.0:PORT en hosts donde ningún grupo de seguridad ascendente, firewall externo o regla de cadena DOCKER-USER la bloquea.
Redes puente personalizadas en uso: Los contenedores en el puente predeterminado de Docker pueden comunicarse entre sí libremente. Los contenedores en el mismo puente definido por el usuario aún pueden comunicarse entre sí, por lo que se deben dividir los servicios en redes separadas según el límite de confianza para lograr un aislamiento real.
Socket Docker no montado en contenedores: Marque Redactar archivos y ejecutar argumentos. Si /var/run/docker.sock aparece como un volumen, confirme que es obligatorio e intencional.
Imágenes base de editores verificados con versiones fijadas: A FROM ubuntu:latest extrae una versión no especificada y potencialmente desactualizada. Anclar a una versión específica.
No hay secretos en Dockerfiles, archivos Compose o argumentos de compilación: El historial de la capa de imagen conserva las credenciales después de la eliminación del contenedor. Utilice Compose secrets, Swarm secrets, cree monturas secretas o un administrador de secretos externo. Las variables de entorno de ejecución son mejores que los valores codificados, pero aún aparecen en los registros y resultados de inspección.
Programa de reconstrucción de imágenes definido: Las imágenes antiguas acumulan vulnerabilidades. Una cadencia de reconstrucción mensual mantiene la ventana de exposición manejable para la mayoría de las configuraciones.
Interfaces de gestión detrás de la autenticación: Cualquier panel en una IP pública sin autenticación es un punto de entrada abierto. Siempre que sea posible, es preferible la ubicación en una red privada.
Registros de contenedores que se recopilan: Sin una canalización de registros, la detección de incidentes depende del impacto visible en el sistema. Esa es una señal tardía para actuar.
Conclusión
La configuración predeterminada de Docker está diseñada para brindar comodidad, no seguridad. La mayoría de los errores tratados en este artículo se remontan a configuraciones que nunca se cambiaron después de la implementación inicial, no a ataques sofisticados.
Las correcciones son en su mayoría decisiones de configuración únicas: una directiva de USUARIO, un cambio de enlace de puerto, una red personalizada, un programa de reconstrucción. Ninguno de ellos requiere herramientas nuevas para la mayoría de las configuraciones.
Conseguir la configuración correcta del contenedor es la primera tarea. La infraestructura sobre la que discurre es la segunda. Ambos importan y ninguno sustituye al otro.
