Docker se ha convertido en una tecnología clave para desplegar aplicaciones modernas, especialmente en arquitecturas basadas en microservicios. Su capacidad para empaquetar aplicaciones en contenedores facilita la portabilidad, la escalabilidad y la automatización, pero también introduce nuevos riesgos si no se aplican controles adecuados de seguridad.

La seguridad en Docker no debe limitarse a revisar una imagen antes de subirla a producción. Debe formar parte de todo el ciclo de vida del software: desde el diseño y el desarrollo hasta la integración continua, el despliegue, la monitorización y la respuesta ante vulnerabilidades. Por eso, aplicar un enfoque devsecops permite integrar la seguridad desde el inicio y no tratarla como una revisión final antes del lanzamiento.

En este artículo repasamos las principales buenas prácticas de seguridad en contenedores, con foco en Docker, microservicios, gestión de secretos, imágenes seguras y seguridad en tiempo de ejecución.

¿Por qué es importante la seguridad en Docker?

Docker permite ejecutar aplicaciones en contenedores aislados, ligeros y reproducibles. Esta ventaja lo ha convertido en una herramienta habitual en entornos DevOps, cloud y Kubernetes. Sin embargo, un contenedor mal configurado puede exponer secretos, ejecutar procesos con privilegios excesivos, incluir dependencias vulnerables o facilitar movimientos laterales dentro de la infraestructura.

La seguridad en Docker es especialmente importante cuando hablamos de docker y microservicios, porque una aplicación puede estar compuesta por decenas o cientos de servicios independientes. Si cada contenedor no se construye, despliega y monitoriza correctamente, la superficie de ataque crece de forma significativa.

Algunos riesgos habituales son:

• Imágenes con vulnerabilidades conocidas.
• Uso de contenedores con usuario root.
• Secretos incluidos en imágenes, variables de entorno o repositorios.
• Puertos expuestos innecesariamente.
• Imágenes descargadas de fuentes no verificadas.
• Falta de control en tiempo de ejecución.
• Ausencia de políticas de red entre microservicios.
• Dependencias de código abierto sin mantenimiento.

Por este motivo, la seguridad microservicios debe abordarse de forma continua, combinando buenas prácticas de desarrollo seguro, automatización, análisis de vulnerabilidades y monitorización.

Checklist rápido de seguridad en Docker

Antes de desplegar contenedores en producción, conviene revisar al menos estos puntos:

Área	Buena práctica recomendada
Imágenes	Usar imágenes mínimas, oficiales y actualizadas
Privilegios	Evitar ejecutar contenedores como root
Secretos	No incluir claves, tokens ni contraseñas en imágenes
Dependencias	Escanear vulnerabilidades en librerías y paquetes
Build	Utilizar builds reproducibles y multi-stage builds
Tags	Evitar latest en producción
Runtime	Monitorizar el comportamiento del contenedor en ejecución
Red	Limitar la comunicación entre servicios
Logs	Registrar eventos relevantes sin exponer información sensible
CI/CD	Integrar controles de seguridad en pipelines

1. Utilizar imágenes pequeñas y seguras

La primera recomendación es usar imágenes Docker lo más ligeras posible.

Cuanto más grande sea una imagen, más componentes tendrá. Y cuantos más componentes tenga, más posibilidades hay de que alguno incluya una vulnerabilidad.

Por ejemplo, si una aplicación solo necesita Java para funcionar, no conviene usar una imagen completa de Ubuntu si existe una imagen más pequeña y específica para ese uso.

Buenas prácticas:

• Usar imágenes oficiales o de proveedores fiables.
• Evitar imágenes antiguas o sin mantenimiento.
• Instalar solo lo necesario.
• Actualizar las imágenes con frecuencia.
• No usar imágenes descargadas de fuentes desconocidas.

Una imagen más pequeña suele ser más fácil de mantener, más rápida de desplegar y más segura.

2. No ejecutar contenedores con usuario root

Muchas imágenes Docker se ejecutan por defecto con el usuario root. Esto no es recomendable.

Si un atacante consigue entrar en un contenedor que se ejecuta como root, el impacto puede ser mayor. Por eso, siempre que sea posible, se debe usar un usuario con permisos limitados.

Ejemplo básico:

RUN adduser –disabled-password appuser

USER appuser

De esta forma, la aplicación no se ejecuta con permisos innecesarios.

3. Revisar las vulnerabilidades de las imágenes

Las imágenes Docker pueden incluir librerías o paquetes con fallos de seguridad. Aunque el código de la aplicación esté bien desarrollado, una dependencia vulnerable puede poner en riesgo todo el entorno.

Por eso es importante analizar las imágenes antes de desplegarlas y seguir revisándolas con el tiempo.

Un servicio de gestión de vulnerabilidades permite detectar, priorizar y corregir estos problemas de forma continua.

Herramientas habituales para este tipo de análisis:

• Docker Scout.
• Trivy.
• Snyk.
• Prisma Cloud.
• Grype.

La clave no es solo encontrar vulnerabilidades, sino saber cuáles son realmente críticas y corregirlas antes de que afecten a producción.

4. No guardar secretos dentro de las imágenes

Uno de los errores más frecuentes en Docker es guardar información sensible dentro de la imagen.

Por ejemplo:

• Contraseñas.
• Tokens de acceso.
• Claves API.
• Certificados.
• Archivos .env.
• Credenciales de bases de datos.

Esto es peligroso porque las imágenes pueden compartirse, copiarse o almacenarse en registros donde otras personas podrían acceder a esa información.

La gestión de secretos en contenedores debe hacerse con herramientas específicas, como Docker Secrets, Kubernetes Secrets, Vault o gestores de secretos cloud.

Mala práctica:

ENV PASSWORD=mi_contraseña

Mejor práctica:

Guardar el secreto fuera de la imagen e inyectarlo solo cuando el contenedor se ejecuta.

5. Evitar el uso del tag latest

Usar el tag latest puede parecer cómodo, pero no es una buena práctica en producción.

El problema es que latest no indica una versión concreta. Si la imagen cambia, podríamos desplegar una versión nueva sin haberla probado antes.

Mala práctica:

FROM nginx:latest

Mejor práctica:

FROM nginx:1.27-alpine

Usar versiones concretas ayuda a saber exactamente qué se está desplegando y facilita la solución de problemas.

6. Firmar y verificar imágenes

Antes de usar una imagen Docker, es importante asegurarse de que viene de una fuente fiable.

Una imagen modificada por un atacante podría incluir malware o código malicioso. Por eso conviene descargar imágenes solo desde registros de confianza y verificar su origen siempre que sea posible.

Recomendaciones:

• Usar imágenes oficiales.
• Revisar quién mantiene la imagen.
• Evitar imágenes abandonadas.
• Controlar qué imágenes pueden entrar en el entorno corporativo.
• Firmar imágenes en procesos críticos.

Esta práctica ayuda a reducir el riesgo de usar imágenes manipuladas.

7. Usar COPY en lugar de ADD

En los Dockerfile existen dos instrucciones parecidas: COPY y ADD.

En la mayoría de los casos, es mejor usar COPY, porque es más simple y predecible. ADD tiene comportamientos adicionales, como descomprimir archivos automáticamente o descargar contenido desde una URL.

Recomendado:

COPY ./app /app

Usar instrucciones claras facilita la revisión del Dockerfile y reduce errores.

8. Separar la compilación de la imagen final

Cuando se crea una imagen Docker, muchas veces se necesitan herramientas solo para compilar o construir la aplicación. Sin embargo, esas herramientas no deberían estar en la imagen final de producción.

Para evitarlo, se pueden usar builds en varias fases, también conocidos como multi-stage builds.

Esto permite tener:

• Una imagen más pequeña.
• Menos dependencias.
• Menor superficie de ataque.
• Un despliegue más limpio.

En resumen: lo que se usa para construir no tiene por qué quedarse en producción.

9. Controlar la seguridad en tiempo de ejecución

No basta con revisar una imagen antes de desplegarla. También hay que controlar qué ocurre cuando el contenedor ya está funcionando.

Esto se conoce como seguridad en tiempo de ejecución de contenedores.

Dicho de forma sencilla: consiste en vigilar si el contenedor hace algo extraño mientras está activo.

Por ejemplo:

• Ejecutar procesos inesperados.
• Conectarse a destinos no autorizados.
• Intentar acceder a archivos sensibles.
• Descargar archivos sospechosos.
• Usar más recursos de los normales.
• Abrir una shell sin motivo.

Entonces, qué es la seguridad de runtime de contenedores: es la capacidad de detectar y controlar comportamientos sospechosos cuando el contenedor está en marcha.

Esta parte es muy importante porque algunas amenazas solo aparecen después del despliegue.

10. Proteger la comunicación entre microservicios

En arquitecturas de microservicios, una aplicación puede estar formada por muchos servicios pequeños que se comunican entre sí.

El problema es que, si todos los servicios pueden hablar con todos, un atacante que comprometa uno de ellos podría moverse con más facilidad por el entorno.

Para mejorar la seguridad microservicios, es recomendable:

• Permitir solo las comunicaciones necesarias.
• Separar entornos de desarrollo, pruebas y producción.
• Limitar puertos expuestos.
• Aplicar políticas de red.
• Cifrar comunicaciones cuando sea necesario.
• Revisar qué servicio puede acceder a cada recurso.

La idea es sencilla: cada microservicio debe tener solo los permisos y accesos que necesita para funcionar.

11. Incluir la seguridad en la integración continua

La seguridad debe formar parte del proceso de desarrollo, no ser una revisión final antes de publicar.

Con una buena integración continua se pueden automatizar controles como:

• Revisión de vulnerabilidades.
• Detección de secretos.
• Análisis del Dockerfile.
• Revisión de dependencias.
• Validación de configuraciones.
• Bloqueo de despliegues inseguros.

Esto permite detectar problemas antes y reducir errores en producción.

12. Crear buenas prácticas internas

Cada empresa debería definir unas reglas mínimas para trabajar con Docker de forma segura.

Por ejemplo:

• Qué imágenes se pueden usar.
• Qué registros están permitidos.
• Cómo se gestionan los secretos.
• Qué permisos pueden tener los contenedores.
• Cómo se revisan las vulnerabilidades.
• Qué controles debe pasar una imagen antes de llegar a producción.

Estas reglas deben ser fáciles de entender y aplicar por los equipos técnicos.

Un programa de Security Champions puede ayudar mucho en este punto, ya que permite tener personas dentro de los equipos que impulsan las buenas prácticas de seguridad en el día a día.

13. Aplicar seguridad desde el inicio del desarrollo

La seguridad en Docker funciona mejor cuando se tiene en cuenta desde el principio.

Un enfoque SSDLC ayuda a incorporar controles de seguridad durante todo el ciclo de vida del software: diseño, desarrollo, pruebas, despliegue y mantenimiento.

De esta forma, la seguridad deja de ser un bloqueo al final del proyecto y se convierte en una parte natural del desarrollo.

Errores frecuentes en seguridad Docker

Estos son algunos errores que conviene evitar:

Error	Riesgo
Usar imágenes sin verificar	Malware o imágenes manipuladas
Ejecutar como root	Mayor impacto ante una explotación
Incluir secretos en la imagen	Exposición de credenciales
Usar latest	Despliegues no controlados
No escanear vulnerabilidades	CVEs sin detectar
Abrir puertos innecesarios	Mayor superficie de exposición
Montar el socket Docker	Riesgo de control sobre el host
No limitar recursos	Riesgo de denegación de servicio
No monitorizar runtime	Detección tardía de compromisos
No aplicar políticas de red	Movimiento lateral entre servicios

Resumen de buenas prácticas de seguridad en Docker

Recomendación	Por qué es importante
Usar imágenes mínimas	Reduce vulnerabilidades y dependencias innecesarias
No ejecutar como root	Limita el impacto de un ataque
Revisar vulnerabilidades	Detecta fallos antes de producción
No guardar secretos en imágenes	Evita fugas de credenciales
Evitar latest	Permite controlar versiones
Verificar imágenes	Reduce el riesgo de imágenes manipuladas
Usar COPY mejor que ADD	Hace el Dockerfile más claro y seguro
Usar builds por fases	Crea imágenes finales más limpias
Vigilar el runtime	Detecta comportamientos sospechosos
Limitar comunicación entre servicios	Reduce el movimiento lateral

Conclusión

Docker aporta muchas ventajas para desplegar aplicaciones y trabajar con microservicios, pero también requiere una estrategia clara de seguridad.

La seguridad en contenedores debe cubrir todo el proceso: desde la creación de la imagen hasta su ejecución en producción. Esto incluye usar imágenes seguras, evitar permisos innecesarios, proteger secretos, revisar vulnerabilidades, controlar la comunicación entre servicios y monitorizar el comportamiento de los contenedores.

En Ciberso podemos ayudarte a mejorar la seguridad de tus entornos Docker y microservicios, integrando buenas prácticas DevSecOps en tus procesos de desarrollo, despliegue y operación