[bigmac]

This couldn't be further from the truth.

Docker containers run with default seccomp profiles, namespacing (filesystem, PIDs, mounts, etc), LSM policies (AppArmor, SELinux), and capability dropping.

These are all common sense security controls that aren't widely available because they're typically hard to use. Docker makes them defaults for everyone. This makes classes of remote attacks against applications far more difficult. Tangible example: read-only filesystems + mount namespacing make vulns that require filesystem modification or directory traversal far more difficult.

At this point arguing against running in Docker is like arguing in favor of IE6's security model instead of Chrome's.

Disclaimer: I manage security at Docker.

[yid]

You guys are doing a great job! Some security-related sandboxing options to docker run that people may not be aware of, which are hard to assemble individually from Linux pieces:

  * --read-only
  * --security-opt="no-new-privileges"
  * --cap-drop=ALL
  * --net="none"
  * --cpu-period=
  * --cpu-quota=

[redtuesday]

Is it intended that the last two have nothing after the equal sign? If yes, what does that do?

There is also --pids-limit=<some number> against fork bombs.

EDIT - this git repo has more links to security related articles etc. https://github.com/wsargent/docker-cheat-sheet#security

[cpuguy83]

More detail on actual security issues (real CVE's) prevented just by using docker: https://docs.docker.com/engine/security/non-events/

[nwmcsween]

I argue against using docker but simply due to the fact that docker encompasses too much when everything docker does could be accomplished by simple single use tools like unshared, cgexec, etc. Git does this and it works very well.