Seguridad de contenedores Docker: la guía completa

Los contenedores cambiaron la forma en que se entrega el software. Un solo docker run le da a la persona desarrolladora un entorno reproducible en segundos, y la misma image viaja sin cambios desde una laptop al CI y a producción. Esa portabilidad es exactamente por qué la seguridad de contenedores Docker merece atención deliberada: la comodidad que hace que los contenedores sean fáciles de entregar también hace que sean fáciles de entregar, junto con ellos, los valores predeterminados inseguros, las base images vulnerables y los secretos filtrados. Esta guía recorre el panorama completo — qué significa la seguridad de contenedores, por qué la arquitectura de Docker necesita protegerse, la superficie de ataque a lo largo del ciclo de vida y las prácticas que se sostienen en producción.

La seguridad de contenedores Docker es la disciplina de proteger las cargas de trabajo en contenedores y la infraestructura en la que se ejecutan, desde el build hasta el runtime. Abarca el código y la configuración que definen una image, la image misma y sus dependencias, el registry que la distribuye, el host y el daemon que la ejecutan, y el comportamiento del contenedor en ejecución. Hacerlo bien significa tratar cada una de esas cosas como su propia capa, con sus propios controles, en lugar de suponer que un contenedor es una caja segura simplemente porque es un contenedor.

Por qué el modelo de Docker necesita protegerse

Lo más importante que hay que entender sobre la seguridad de contenedores es qué es realmente un contenedor. Un contenedor no es una pequeña máquina virtual. Una máquina virtual ejecuta su propio kernel sobre un hypervisor, y ese hypervisor es una frontera dura entre los huéspedes. Un contenedor no tiene un kernel propio — cada contenedor de un host comparte el único kernel Linux del host, y el aislamiento lo crean características del kernel: los namespaces particionan lo que un proceso puede ver (su propio árbol de procesos, pila de red, mounts y usuarios), mientras que los control groups (cgroups) limitan lo que puede consumir (CPU, memoria, PIDs).

Ese diseño es liviano y rápido, pero tiene una consecuencia directa de seguridad: la frontera de aislamiento es el kernel, y el kernel es compartido. Una vulnerabilidad en el kernel, o un contenedor con privilegio suficiente para alcanzarlo, puede afectar a todos los demás contenedores del host y al host mismo. Por eso un "container escape" es un evento tan grave y por eso la frase "los contenedores no son una frontera de seguridad como lo son las VMs" se repite tan a menudo. No es que los contenedores sean inseguros — los contenedores bien configurados están fuertemente aislados — sino que el techo de ese aislamiento es más bajo que el de un hypervisor, así que la configuración importa más.

Dos valores predeterminados agravan esto. Primero, los procesos dentro de un contenedor se ejecutan como root de forma predeterminada y, a menos que intervengas, el root dentro del contenedor se asigna al root del host. Si un atacante escapa, escapa como un usuario privilegiado. Segundo, aquello que orquesta todo esto — el daemon de Docker (dockerd) — se ejecuta como root y escucha en un socket Unix. Cualquiera que pueda comunicarse con ese socket puede iniciar un contenedor que monte el sistema de archivos del host y, a partir de ahí, adueñarse de la máquina. El daemon es una frontera de confianza, y el acceso a él equivale, en la práctica, a root en el host. Ten ambos presentes; casi toda recomendación de hardening que sigue se remonta a ellos.

La superficie de ataque del contenedor a lo largo del ciclo de vida

Ayuda mapear el riesgo a las etapas por las que pasa una image, porque los controles difieren en cada etapa y una brecha en cualquiera de ellas socava a las demás. El ciclo de vida recorre: build, image, registry, host y daemon, y runtime. Las secciones de abajo resumen cada una y enlazan al análisis a fondo que la cubre por completo.

Build: el Dockerfile

La seguridad empieza con el Dockerfile, porque el Dockerfile decide qué termina en la image y cómo se ejecuta el contenedor. Las decisiones aquí son pegajosas — se embarcan en cada pull y en cada deploy. Una línea FROM que fija una base image pesada y desactualizada incrusta cientos de paquetes que nunca usarás pero que tendrás que parchear. Ejecutar todo como root, instalar un gestor de paquetes completo y un shell en una image de producción, usar la tag mutable latest en lugar de un digest fijado y copiar todo el build context con un descuidado COPY . . — todo eso amplía la superficie antes incluso de que el contenedor arranque.

Los remedios son igual de concretos: elige base images mínimas o distroless, agrega un USER no-root dedicado, usa multi-stage builds para que el instrumental de build nunca llegue a la image final, fija versiones y digests para la reproducibilidad, y usa un .dockerignore para mantener los secretos y la basura local fuera del context. Para el checklist completo, consulta Dockerfile security best practices.

Image: base image, dependencias, secretos y procedencia

La image es donde de hecho vive la mayor parte del riesgo explotable, porque una image es una pila de capas que contiene un sistema operativo, runtimes de lenguajes y las dependencias de tu aplicación — cualquiera de las cuales puede acarrear vulnerabilidades conocidas. Una base image que estaba al día en el momento del build queda desactualizada en cuestión de semanas. Las dependencias de la aplicación traídas de registries públicos aportan su propio árbol transitivo de paquetes, y esa cadena de suministro es un objetivo primario: el OWASP Top 10 2025 eleva los fallos de la cadena de suministro de software a la categoría A03, reflejando con qué frecuencia el compromiso hoy llega por las dependencias y los pipelines de build, y no por el código de la aplicación en sí.

La procedencia importa tanto como el contenido. ¿Puedes probar que una image se construyó a partir del código fuente que crees, mediante el pipeline en el que confías, y que no ha sido manipulada desde entonces? Ahí es donde entran un software bill of materials (SBOM), las attestations de build y la firma de images. Escanear images con software composition analysis expone los componentes con vulnerabilidades conocidas; los controles de procedencia hacen que la image sea confiable. Consulta Docker image security y software composition analysis para el tratamiento completo.

Registry: distribución y firma

Entre el build y la ejecución se encuentra el registry, el punto de distribución de tus images y, por lo tanto, un eslabón de alto valor en la cadena. Un registry que permite pushes anónimos, carece de control de acceso o sirve images sin firmar deja que un atacante sustituya una image legítima por una maliciosa, y cada host que la trae ejecuta el código del atacante. La seguridad de registry gira en torno a una autenticación fuerte y un acceso de mínimo privilegio, a firmar images y verificar esas firmas en el pull, a escanear images en el push para que un build vulnerable nunca quede disponible para pull, y a limpiar las tags obsoletas que silenciosamente permanecen como superficie de ataque. Consulta container registry security.

Host y daemon: rootless, exposición del socket y controles de kernel

El host es el cimiento compartido, y el daemon es su componente más sensible. El error de host más común y más dañino es exponer el socket de Docker — montar /var/run/docker.sock dentro de un contenedor o, peor aún, vincular el daemon a un puerto TCP sin TLS mutuo. Cualquiera de los dos reparte root. No hagas ninguno: mantén el socket fuera de la red y nunca lo montes dentro de un contenedor a menos que confíes plenamente en ese contenedor y lo controles.

Más allá del socket, el host es donde se afinan las primitivas de aislamiento del kernel. Las capabilities de Linux te permiten descartar los amplios poderes que root normalmente ostenta y conceder de vuelta solo lo que una carga de trabajo necesita, de modo que un proceso comprometido no pueda, por ejemplo, cargar módulos de kernel o cambiar la propiedad arbitraria de archivos. Un profile de seccomp restringe qué system calls puede hacer un contenedor, reduciendo la superficie de kernel a la que un escape podría apuntar; Docker viene con un profile de seccomp predeterminado sensato, y puedes ajustarlo más estrictamente. AppArmor (o SELinux) agrega control de acceso obligatorio por encima. Y Docker rootless ejecuta el daemon y los contenedores como un usuario sin privilegios, de modo que hasta un breakout aterriza como un usuario no-root en el host, y no como root — una reducción significativa del radio de impacto. Combina esto con límites de cgroup por contenedor para que una sola carga de trabajo no pueda agotar los recursos del host.

Runtime: drift, escapes y monitoreo

Todo lo anterior concierne al estado de un contenedor antes de que se ejecute. La seguridad de runtime concierne a su comportamiento una vez que está en marcha. Se supone que las images son inmutables, pero los contenedores en ejecución sufren drift — se instala un paquete a mano, se edita un archivo de configuración, se deja un shell abierto, arranca un proceso que nunca estuvo en la image. El drift es a la vez un mal olor operativo y una señal de seguridad: un contenedor que hace algo que su image nunca describió merece ser investigado. El runtime también es donde aparecen los intentos de escape, la escalada de privilegios, las conexiones salientes inesperadas y la cripto-minería. Las defensas son monitorear el comportamiento del contenedor contra una línea base esperada, imponer sistemas de archivos raíz de solo lectura donde sea posible, alertar sobre el drift y la actividad anómala de procesos o de red, y tener una ruta de respuesta cuando algo se dispara. Consulta container runtime security.

Secretos en contenedores: build args, env y filtración por capas

Los secretos merecen su propia advertencia porque los errores son tan fáciles de cometer y tan difíciles de deshacer. Tres patrones filtran credenciales, y los tres son comunes.

Primero, los build arguments. Los valores pasados con --build-arg y referenciados vía ARG quedan visibles en el historial de la image — docker history los mostrará — así que una clave de API pasada como build arg queda, en la práctica, publicada dentro de la image. Segundo, las variables de entorno. Incrustar un secreto en una instrucción ENV lo almacena en una capa de la image que cualquiera con la image puede leer; inyectar secretos como variables de entorno en runtime es mejor que incrustarlos, pero las env vars siguen siendo visibles para cualquier proceso del contenedor y, a menudo, para los logs y los informes de error. Tercero, las capas. Como cada instrucción del Dockerfile crea una capa, copiar un secreto y luego borrarlo en una instrucción posterior no lo elimina — el archivo sigue existiendo en la capa anterior, y cualquiera puede desempaquetar la image para encontrarlo.

La regla es sencilla: no pongas secretos en las images. Usa secret mounts en tiempo de build (el --mount=type=secret de BuildKit), que nunca persisten en una capa, inyecta los secretos de runtime a través de un gestor de secretos dedicado, y escanea images y Dockerfiles en busca de credenciales committeadas por accidente como parte del CI. Trata como comprometido cualquier secreto que alguna vez haya tocado una capa de image, y rótalo.

La relación con Kubernetes

La seguridad de contenedores Docker y la seguridad de Kubernetes están relacionadas, pero no son lo mismo, y vale la pena ser preciso sobre la frontera. Todo en esta guía trata del contenedor en sí — cómo se construye, qué hay en él, cómo se distribuye y cómo el host lo ejecuta. Kubernetes se sitúa una capa por encima: orquesta contenedores a través de una flota de hosts, agendándolos, conectándolos en red, escalándolos y gestionando su configuración y sus secretos a escala. Los contenedores que Kubernetes ejecuta son las mismas images y las mismas preocupaciones de runtime descritas aquí — una image vulnerable es vulnerable ya sea que la ejecutes con docker run o lo haga un agendador — así que la seguridad de contenedores es el cimiento sobre el que se construye la seguridad de Kubernetes.

Lo que Kubernetes agrega es su propia superficie de ataque: el API server y el RBAC, el admission control de cargas de trabajo, los pod security standards, las network policies entre servicios y el manejo de secretos a nivel de cluster. Eso pertenece a la capa de orquestación, y la cubrimos por separado para que esta guía no la duplique. Si ejecutas contenedores en Kubernetes, lee Kubernetes security junto con esta guía, y Kubernetes image security para saber cómo los controles de image se extienden hacia dentro del cluster. El admission control es donde se encuentran los dos mundos: es la puerta del cluster que puede rechazar una image que falló tus verificaciones de las etapas de build y registry.

Shift left: atrapa los problemas antes de que se ejecuten

El lugar más barato para corregir un problema de seguridad de contenedor es antes de que la image se construya, y el segundo más barato es antes de que se despliegue. Desplazar a la izquierda (shift left) significa mover estas verificaciones hacia dentro del flujo de trabajo de la persona desarrolladora y del pipeline de CI, en lugar de descubrir los problemas en producción. En la práctica eso se ve así: hacer lint y escanear los Dockerfiles en busca de instrucciones inseguras a medida que se escribe el código, ejecutar software composition analysis en cada build para que las dependencias vulnerables reprueben el pipeline, escanear la image terminada en busca de CVEs de OS y de bibliotecas y de secretos incrustados, generar un SBOM y firmar la image, y aplicar política en una puerta de registry o de admission para que una image no conforme no pueda promoverse.

La misma disciplina se extiende al entorno en el que se ejecutan los contenedores. Los hosts de contenedores y la orquestación se definen cada vez más como código — Dockerfiles, archivos Compose y plantillas de infraestructura — así que escanear esa configuración atrapa las configuraciones incorrectas (un contenedor privilegiado, un socket montado, un límite de recursos ausente) antes de que se aprovisionen. Consulta IaC security para ese lado del panorama. El shift left no reemplaza la defensa de runtime; reduce cuánto llega al runtime, para que tu monitoreo tenga menos cosas, y más significativas, que atrapar.

Mejores prácticas

Uniendo los hilos, una postura fuerte de seguridad de contenedores Docker se apoya en un conjunto consistente de hábitos:

• Parte de base images mínimas, confiables y actualizadas con regularidad, y fíjalas por digest en lugar de una tag flotante.
• Ejecuta los contenedores como un usuario no-root, descarta todas las capabilities de Linux y vuelve a agregar solo lo que se requiere, y mantén el sistema de archivos raíz de solo lectura donde la carga de trabajo lo permita.
• Nunca expongas el socket del daemon de Docker a un contenedor o a la red, y prefiere Docker rootless para reducir el radio de impacto de cualquier escape.
• Mantén el profile de seccomp predeterminado en su lugar (o ajústalo más estrictamente), y suma AppArmor o SELinux por encima para el control de acceso obligatorio.
• Mantén los secretos completamente fuera de las images — usa secret mounts de build y un gestor de secretos de runtime, y escanea en busca de credenciales filtradas.
• Escanea images y dependencias de forma continua, genera un SBOM y firma las images para que la procedencia pueda verificarse en el pull.
• Fija límites de recursos de cgroup para que un contenedor no pueda ahogar al host, y monitorea los contenedores en ejecución en busca de drift y comportamiento anómalo.
• Aplica todo lo anterior como política automatizada en el CI y en las puertas de registry o de admission, no como un paso de revisión manual.

Cómo ayuda Rainforest

Proteger contenedores es un problema de ciclo de vida completo, y por eso es difícil resolverlo con herramientas puntuales atornilladas al final. Rainforest lleva la seguridad de image de contenedor y la software composition analysis a una única plataforma de seguridad de aplicaciones, de modo que las mismas verificaciones que escanean el código de tu aplicación también inspeccionan las images que entregas: paquetes de OS y dependencias con vulnerabilidades conocidas, secretos incrustados y configuración insegura de image, expuestos en el pipeline donde las personas desarrolladoras pueden actuar sobre ellos, en lugar de en una consola separada después del hecho. Como se ejecuta en el CI y genera los datos de procedencia — SBOMs y resultados de escaneo — de los que dependen las puertas posteriores, los hallazgos llegan con el contexto para priorizarlos y corregirlos, y la misma política acompaña a la image desde el build, pasando por el registry, hasta el punto de despliegue.

Si quieres ver dónde están hoy las images de contenedor de tu organización, book a demo o explora container security dentro de la plataforma más amplia de application security testing.