Virtual machines are generally considered secure. At least, they are secure enough, when implemented properly, to power highly multi-tenant, large-scale public clouds, where a single physical machine can host a large number of virtual instances belonging to different customers. Containers have many advantages over virtual machines: they boot faster, have less performance overhead, and use less resources. However, those advantages also stem from the fact that containers share the kernel of their host, instead of abstracting an new independent environment. This sharing has significant security implications, as kernel exploits can now lead to host-wide escalations.
Additionally, the default settings for Linux Containers are often very permissive, which has led many people to state that containers are not secure. We will show techniques to lock down containers, and discuss which risks they mitigate. The list will include:
We will also detail the specific drawbacks of each method, and demonstrate a way to seamlessly integrate classic virtualization in a container workload when there is no other acceptable possibility.
Jerome is a senior engineer at Docker, where he rotates between Ops, Support and Evangelist duties. In another life he built and operated Xen clouds when EC2 was just the name of a plane, developed a GIS to deploy fiber interconnects through the French subway, managed commando deployments of large-scale video streaming systems in bandwidth-constrained environments such as conference centers, and various other feats of technical wizardry. When annoyed, he threatens to replace things with a very small shell script. His left hand cares for the dotCloud PAAS servers, while his right hand builds cool hacks around Docker.
Comments on this page are now closed.
For exhibition and sponsorship opportunities, contact Sharon Cordesse at firstname.lastname@example.org
For information on trade opportunities with O'Reilly conferences contact email@example.com
For media-related inquiries, contact Maureen Jennings at firstname.lastname@example.org
View a complete list of OSCON contacts