3 ms·
This couldn't be further from the truth. Docker containers run with default seccomp profiles, namespacing (filesystem, PIDs, mounts, etc), LSM policies (AppArm
by bigmac 10y ago
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 10y agoYou 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 10y agoIs 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 https://github.com/wsargent/docker-cheat-sheet#security
- nwmcsween 10y agoI 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.
- cpuguy83 10y agoMore detail on actual security issues (real CVE's) prevented just by using docker: https://docs.docker.com/engine/security/non-events/ https://docs.docker.com/engine/security/non-events/