"You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes."<p>-- Theo de Raadt (on the statement "Virtualization seems to have a lot of security benefits")
I think we'll see more security incidents involving Docker in the future as it becomes more popular. I have worked with it for a few months now and I can already see a few attack vectors that could easily be exploited if the corresponding Docker features are not used properly.<p>For example, as Docker can by default mount anything that root can mount, running<p><pre><code> docker run -i --volume=/:/data -t ubuntu
</code></pre>
will give you complete root access to your file system in the docker container (the talk mentions some Docker features that will mitigate this kind of attacks, notably UID mapping). Of course no one would willingly do that, but if you mount user resources into your containers and the resource name contains something that an external user might control (e.g. his/her username), then injection attacks become possible. Even with UID mapping enabled this can leak sensitive information about your host system into the container. And since people often use containers to run untrusted code (e.g. for CI systems), this can be a large security threat in my opinion.<p>Personally I really like Docker and I think it (or similar technologies) will change many aspects of IT/Devops/Data Analysis in the future, I just think that maybe they should have some more sensible defaults for security-relevant settings, i.e. only grant network access to containers if you ask for it, restrict default memory usage by default, limit the type of volumes you can mount, etc.
It's curious to me that of the various container options, only lxc/lxd seems to put in the effort required to get truly non-privileged containers working without issues.<p>Lxc/lxd goes far enough that you can boot a systemd based container, get a sanely partitioned view of /proc, etc. The effort is non-trivial...they had to create cgmanager, lxcfs, etc.<p>Rkt, runc, etc, are all working on it, but don't seem close to a real solution.
Docker also needs to address the hardcoding of the repo<p><a href="https://github.com/docker/docker/issues/1988" rel="nofollow">https://github.com/docker/docker/issues/1988</a>
Good presentation. One thing I'd mention is that they talk about the CIS security guide, but it's currently pretty out of date as it covers 1.6 and therefore misses a lot of Docker features like Content Trust, User Namespaces and Seccomp-BPF.<p>In general I'd say that Docker security is getting better, although I'm really looking forward to getting a better authentication/authorisation model on the docker engine as right now it's all or nothing, which is a pretty blunt instrument. Also this model causes problems when people do things like mount docker.sock inside a container for introspection as anyone compromising that container can take over the host. A better authorisation model would allow safer introspection...<p>Also worth noting as it's not in the presentation, one of the key Docker security features, User Namespaces, is not switched on by default, so you need to enable it on the daemon.
I will never get the Docker rant.<p>At the beginning I loved it however the deeper I digged the more I hated it. Actually the only thing I need would be immutable infrastructure and resource isolation. However for most of these things you don't need docker at all.
You would've need some sort of container that could be fully isolated with the kernel cgroups and have somehow a way to isolate the network, but docker grows to a extremely fat monolithic approach where everything is put into and still it gets worse every release and the problems will never be fully addressed.<p>And on top of that the Docker Inc. tries to monetize on that with software that other vendors could do as well. Docker Inc. should focus on Docker and not on everything surrounding that.<p>Docker should've been easy, but now to make a good use of it your infrastructure will definitly not as easy as you planned at first. The way how you deploy software will change, but I doubt that it's docker who will make the "global" change. Maybe it was docker who gave a first impression how it could look but it's definitely not the end.
For your convenience here are the URLs from that broken document:<p><a href="http://blog.bofh.it/debian/id_413" rel="nofollow">http://blog.bofh.it/debian/id_413</a>
<a href="http://reventlov.com/advisories/using-the-docker-command-to-root-the-host" rel="nofollow">http://reventlov.com/advisories/using-the-docker-command-to-...</a>
<a href="http://events.linuxfoundation.org/sites/events/files/slides/Containers,%20Docker,%20and%20Security_%20State%20of%20the%20Union.pdf" rel="nofollow">http://events.linuxfoundation.org/sites/events/files/slides/...</a>
<a href="http://opensource.com/business/14/9/security-for-docker" rel="nofollow">http://opensource.com/business/14/9/security-for-docker</a>
<a href="https://zeltser.com/security-risks-and-benefits-of-docker-application/" rel="nofollow">https://zeltser.com/security-risks-and-benefits-of-docker-ap...</a>
<a href="https://benchmarks.cisecurity.org/tools2/docker/CIS_Docker_1.6_Benchmark_v1.0.0.pdf" rel="nofollow">https://benchmarks.cisecurity.org/tools2/docker/CIS_Docker_1...</a>
<a href="https://forums.grsecurity.net/viewtopic.php?f=7&t=2522" rel="nofollow">https://forums.grsecurity.net/viewtopic.php?f=7&t=2522</a>
<a href="http://xebia.github.io/cd-with-docker/#/" rel="nofollow">http://xebia.github.io/cd-with-docker/#/</a>
<a href="http://www.schibsted.pl/2015/06/how-we-used-docker-to-deploy-schibsted-pl/" rel="nofollow">http://www.schibsted.pl/2015/06/how-we-used-docker-to-deploy...</a>
<a href="http://itrevolution.com/the-three-ways-principles-underpinning-devops/" rel="nofollow">http://itrevolution.com/the-three-ways-principles-underpinni...</a><p>Most of these will be already in your bookmarks, when you are following docker development.<p>Why was this talk is interesting? Is there a video that shows things that happened that are not reflected in the powerpoint pdf? What was new?<p>BTW the powerpoint document wins the "most annoying document of the week"- award. We have better ways to publish URLs in 2016 than powerpoint. Please use reveal or anything else next time, thanks!
We changed the url from <a href="https://www.insinuator.net/2016/03/docker-devops-security/" rel="nofollow">https://www.insinuator.net/2016/03/docker-devops-security/</a>, which points to this and doesn't seem to have any content of its own.