In its default configuration a docker container has pretty good baseline security. The technology behind containers is mature and time proven (chroot 1979, zones 2004, LXC 2007). Breaking out of one is like breaking out of a VM. Possible, but hard - I’am talking side channels, row hammering, cache busting and speculative execution abuse.

However, there are three things to keep in mind from the security perspective:

• A running container is just another box. You might not be able to jailbreak out to the host, but you can surely abuse the software that is running in the container. Update and patch whatever you’ve deployed in the container just like you would if it was running in a VM or on bare metal.
  • Use built in docker control paths (like exec or cp), do not install ssh
• Kernel level exploits may work if your host kernel is vulnerable. Patch your host.
• Go easy on the non-default configurations when running the container. Some examples:
  • --network=host will completely expose your host’s network stack to the container
  • Relaxing namespaces or cgroups will stretch the attack surface to your host.
  • Sharing volumes need proper user and space management. Users from a container will map over to your host fs. E.g. a root inside a container is the root on the host as far as OverlayFS is concerned. Try running this: docker run --rm -v /:/x/ alpine cat /x/etc/shadow Sidenote: rkt (Rocket) containers don’t have a daemon and run as processes directly which may help here.
• Limit resources allocated to a container to protect against DoS of the container and host - CPU, fork bombs, space
• Sensitive data exposure - image build history contains all the steps from the dockerfile. Never put anything sensitive there. Use environment variables (not build variables), docker secrets
• Trusted source and supply chain - if you don’t trust the source of the image, do not run it, build your own. If you trust the source but don’t verify the supply chain, you are no better off.

Good practices

• Disable inter-container communication if you want them not affect each other –icc=false
• Scan docker containers for vulnerabilites - nessus is probably an overkill but you need to know whats' running and what version, opensource or otherwise

What does mitigate the issues above is the ease of blowing way and recreating containers. This makes your patch cycle short . With a very short lived container (think serverless type) you are guaranteed to have a very short exposure window.

TLDR; Containers are secure, have several footguns (things to shoot yourself in the foot with), but help your security by their propensity to be short lived.