Implementación segura de Docker
Docker ha cambiado las reglas del juego en cómo desplegamos aplicaciones. Su velocidad, portabilidad y flexibilidad lo han convertido en una pieza fundamental en entornos DevOps y CI/CD. Pero con esa comodidad también llega una gran responsabilidad. En el mundo corporativo, donde una brecha puede afectar a clientes, partners o datos sensibles, dejar los contenedores "por defecto" es una mala idea.
La mayoría de los desarrolladores saben cómo construir una imagen o levantar un servicio, pero no siempre se presta atención a la seguridad real del entorno donde vive ese contenedor. ¿Corre como root? ¿Tiene acceso innecesario al host? ¿Se escanea antes de enviarse a producción? ¿Quién audita qué hace ese contenedor en tiempo real? Estas preguntas marcan la diferencia entre una infraestructura robusta y un incidente de seguridad.
El objetivo de esta guía no es darte teoría o fórmulas mágicas, sino mostrarte prácticas reales, técnicas que se usan de verdad en entornos de producción. Cosas que puedes aplicar hoy mismo para reforzar tus contenedores sin romper tu flujo de trabajo ni convertirte en un experto en seguridad.
Empieza por la base: Imágenes limpias y oficiales
Cada contenedor empieza con una imagen. Si esa base está mal, da igual lo que le montes encima. Usa imágenes oficiales del hub de Docker o, mejor aún, manten las tuyas internas. Y nada de meter Ubuntu completo si tu app solo necesita Python: usa versiones slim o Alpine.
FROM python:3.11-slim¿Y si necesitas más control? Crea una base desde cero (scratch) o gestiona tus propias imágenes en un registry privado.
No uses el usuario root, ni dentro ni fuera
Por defecto, muchos contenedores corren como "root". Error clásico. Crea un usuario dentro del Dockerfile y cambia el contexto:
RUN adduser --disabled-password appuserUSER appuserY si puedes, configura Docker en el host con --userns-remap, así ni aunque escapen tienen privilegios.
Bloquear todo lo que no necesite
Por cada contenedor, quita capacidades del kernel que no uses. Mejor quitar todo y luego añadir lo justo:
docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE myappAdemás, evita contenedores con --privileged. Eso equivale a abrirles la puerta con llave maestra.
Ficheros: solo lectura, y controlados
Evita que el contenedor escriba en cualquier parte. Usa --read-only y monta solo lo necesario:
docker run --read-only -v /data:/data myappPara temp o logs, monta volúmenes específicos y monitorea qué se escribe.
Seguridad del host: Seccomp, AppArmor, SELinux
Docker ya incluye un perfil Seccomp (Security Computing Mode) por defecto, igual que pasa con AppArmor (en Ubuntu) o SELinux (en RHEL).
Para entenderlo, es una característica de seguridad del kernel de Linux, que permite restringir las llamadas al sistema que un proceso puede hacer.
Cada contenedor corre como un proceso aislado, pero aún puede hacer miles de llamadas al sistema: abrir archivos, acceder a memoria, crear procesos, conectarse a redes... Muchas de estas llamadas no son necesarias para la aplicación que corre dentro, y si un atacante logra ejecutar código malicioso dentro del contenedor, podría aprovechar esas llamadas para escalar privilegios o dañar el host.
Un ejemplo:
docker run --security-opt seccomp=mi_perfil.json myapp
Escanea antes de subir
No metas contenedores con vulnerabilidades conocidas. Usa herramientas como:
Escanéalo antes de subirlo al registry. Que no te explote en producción algo que podías haber evitado.
Control de redes
Nada de exponer puertos que no hacen falta. Usa redes personalizadas o VLANs, aísla servicios y nada de --network=host sin necesidad. Segmenta por microservicio y limita el acceso entre ellos con firewalls de capa 7 si hace falta.
Monitorización en tiempo real
No basta con que el contenedor funcione, tienes que ver qué hace. Integra logs con herramientas de monitorización para detectar comportamientos anómalos (accesos indebidos, procesos extraños...)
En resumen, Docker es seguro si tú lo haces seguro. La mayoría de los ataques exitosos a contenedores vienen por errores básicos: imágenes con fallos, permisos excesivos, sockets abiertos, y poca visibilidad. Con estas prácticas puedes proteger tus contenedores sin complicarte la vida ni romper tu pipeline de CI/CD. Y si estás en una empresa, el hardening no es un extra, es parte del trabajo bien hecho.
Fin del Artículo. ¡Cuéntanos algo en los Comentarios!
