Asegurar Docker implica múltiples capas — imágenes mínimas y confiables, ejecutar como no-root, escaneo de vulnerabilidades, gestión de secretos, límites de recursos y capacidades, y endurecimiento del host/daemon. La seguridad de contenedores es importante porque las vulnerabilidades pueden afectar tanto al contenedor como al host.
✓ Use MINIMAL base images (alpine, distroless) → fewer packages = smaller attack surface
✓ Use TRUSTED/official images; pin specific versions/DIGESTS (not "latest")
✓ SCAN images for vulnerabilities (Trivy, docker scout, Snyk) — in CI and regularly
✓ Keep base images UPDATED (patch known CVEs)
✓ Don't include secrets or unnecessary tools in images
✓ Run as NON-ROOT (USER instruction) — a root container that's compromised is far more
dangerous (especially with host access). This is one of the most important practices.
✓ Drop capabilities (--cap-drop ALL, add only needed ones) — limit what the container can do
✓ Read-only filesystem (--read-only) where possible
✓ no-new-privileges (prevent privilege escalation)
✓ Set RESOURCE LIMITS (prevent DoS from resource exhaustion)
✓ NEVER run --privileged unless absolutely necessary (it gives near-host access)
✓ Don't bake secrets into images; use secrets management at runtime
✓ Protect the DOCKER DAEMON — the daemon runs as root; access to it = root on the host
(don't expose the Docker socket; mounting /var/run/docker.sock into a container is risky)
✓ Keep the host and Docker engine PATCHED; use minimal/hardened host OS
✓ Isolate networks; limit container-to-container and container-to-host access
✓ Consider rootless Docker / user namespaces for stronger isolation
Asegurar contenedores Docker es conocimiento importante de nivel senior porque las vulnerabilidades de contenedores pueden afectar tanto al contenedor como al host, haciendo que la seguridad sea una preocupación multi-capa con consecuencias reales. Las prácticas de seguridad de imágenes (imágenes base mínimas/confiables para reducir la superficie de ataque, fijar versiones, escanear vulnerabilidades para capturar CVEs conocidos, mantener imágenes actualizadas) previenen enviar imágenes explotables — una fuente común de vulnerabilidades. La seguridad en tiempo de ejecución es especialmente crítica: ejecutar como no-root es una de las prácticas más importantes porque un contenedor root comprometido es mucho más peligroso (potencialmente llevando a compromiso del host), y descartar capacidades, usar filesystems de solo lectura, prevenir escalada de privilegios, y nunca usar --privileged a menos que sea absolutamente necesario (otorga acceso casi a nivel de host) todo limita lo que un atacante puede hacer si un contenedor es brecheado — defensa en profundidad. La gestión de secretos (nunca incrustar secretos en imágenes, usar secretos en tiempo de ejecución) previene fugas de credenciales. La seguridad del host y daemon es crucial y frecuentemente pasada por alto: el daemon de Docker se ejecuta como root, así que acceso a él (o al socket de Docker) efectivamente significa root en el host — haciendo que proteger el daemon, no exponer el socket de Docker, y mantener el host parcheado sea esencial, con Docker sin raíz y namespaces de usuario ofreciendo aislamiento más fuerte.
Ya que los contenedores comparten el kernel del host (así que un escape de contenedor o compromiso del host tiene consecuencias serias) y las aplicaciones containerizadas son generalizadas en producción, y ya que la seguridad apropiada (imágenes mínimas/escaneadas, tiempo de ejecución no-root con capacidades limitadas, gestión de secretos, y endurecimiento de daemon/host) es lo que previene compromisos reales de contenedor y host, entender cómo asegurar contenedores Docker es conocimiento importante de nivel senior — una responsabilidad crítica para deployments de contenedores en producción, donde las prácticas en capas (especialmente ejecución no-root y proteger el daemon con privilegios root) abordan riesgos de seguridad genuinos y serios inherentes a la containerización.