This is where security tips about Docker go. The Docker security page goes into more detail.
First things first: Docker runs as root. If you are in the docker
group, you effectively have root access. If you expose the docker unix socket to a container, you are giving the container root access to the host.
Docker should not be your only defense. You should secure and harden it.
For an understanding of what containers leave exposed, you should read Understanding and Hardening Linux Containers by Aaron Grattafiori. This is a complete and comprehensive guide to the issues involved with containers, with a plethora of links and footnotes leading on to yet more useful content. The security tips following are useful if you've already hardened containers in the past, but are not a substitute for understanding.
Security Tips
For greatest security, you want to run Docker inside a virtual machine. This is straight from the Docker Security Team Lead -- slides / notes. Then, run with AppArmor / seccomp / SELinux / grsec etc to limit the container permissions. See the Docker 1.10 security features for more details.
Docker image ids are sensitive information and should not be exposed to the outside world. Treat them like passwords.
See the Docker Security Cheat Sheet by Thomas Sjögren: some good stuff about container hardening in there.
Check out the docker bench security script, download the white papers.
Snyk's 10 Docker Image Security Best Practices cheat sheet
You should start off by using a kernel with unstable patches for grsecurity / pax compiled in, such as Alpine Linux. If you are using grsecurity in production, you should spring for commercial support for the stable patches, same as you would do for RedHat. It's $200 a month, which is nothing to your devops budget.
Since docker 1.11 you can easily limit the number of active processes running inside a container to prevent fork bombs. This requires a linux kernel >= 4.3 with CGROUP_PIDS=y to be in the kernel configuration.docker run --pids-limit=64
Also available since docker 1.11 is the ability to prevent processes from gaining new privileges. This feature have been in the linux kernel since version 3.5. You can read more about it in this blog post.docker run --security-opt=no-new-privileges
From the Docker Security Cheat Sheet (it's in PDF which makes it hard to use, so copying below) by Container Solutions:
Turn off interprocess communication with:docker -d --icc=false --iptables
Set the container to be read-only:docker run --read-only
Verify images with a hashsum:docker pull debian@sha256:a25306f3850e1bd44541976aa7b5fd0a29be
Set volumes to be read only:docker run -v $(pwd)/secrets:/secrets:ro debian
Define and run a user in your Dockerfile so you don't run as root inside the container:RUN groupadd -r user && useradd -r -g user user
USER user
User Namespaces
There's also work on user namespaces -- it is in 1.10 but is not enabled by default.
To enable user namespaces ("remap the userns") in Ubuntu 15.10, follow the blog example.
Security Videos
- Using Docker Safely
- Securing your applications using Docker
- Container security: Do containers actually contain?
- Linux Containers: Future or Fantasy?
Security Roadmap
The Docker roadmap talks about seccomp support.
There is an AppArmor policy generator called bane, and they're working on security profiles.