Container Security in Production: Docker Hardening That Works

I run over 50 Docker containers in production across my projects - 17 for Valta, 12 for Media Server, 11 for Mirage, 4 for SOAR, plus all other services. Container security in production is a daily concern, not a theoretical one. The Docker security hardening best practices I apply were born from real problems encountered in production, not from generic checklists.

The non-negotiable rules

Never root in containers. Every Dockerfile includes a non-privileged user, and the container runs as that user. It seems trivial, but 60% of Docker images on Docker Hub run as root. A compromised container running as root is one step from compromising the host. I use user namespace remapping where possible for an additional layer of isolation.

Network isolation and secrets management

Every Docker stack has its own isolated bridge network. Containers communicate only with what they need to communicate with - there is no flat network where everyone can reach everyone. Valta has a network for collectors, one for the backend, one for the frontend. Secrets never go in environment variables in docker-compose (they are visible with docker inspect). I use Docker secrets or files mounted in tmpfs with restrictive permissions.

Other rules I apply systematically: minimal base images (alpine or distroless when possible), vulnerability scanning on images before deploy (Trivy is my go-to scanner), resource limits on CPU and memory for every container (a container consuming all host RAM is a DoS), read-only filesystem where possible with specific mounts for directories requiring writes. Container security is a continuous process, not a one-time configuration.