Containers aren’t secure… but neither are VMs
An argument I sometimes here is that large companies (especially financial companies) can’t deploy containers to production because they’re too risky. The people making this argument focus on the fact that the Linux kernel is only a software segregation of resources. They compare this to virtual machines, where the CPU can enforce segregation (eg with VT-x).
I’m not convinced they’re right. It sounds very very similar to the arguments about VMs a decade ago. It also misses out on the hypervisor, itself, being software. This hypervisor runs in privileged mode and is accessible from the client (eg network drivers, block device drivers, paravirt drivers). VT-x instructions can help with some low level primitives and segregation, but even that’s not perfect (oops, rowhammer!).
Will there be bugs in the Linux kernel that’ll enable one container to break out? Sure! But they’ll be found and patched. And hypervisors aren’t bug free. As of time of writing there’s yet another critical Xen bug meaning one of my public VMs will need to be rebooted as my service provider patches their servers.
Intel Clear Containers
So Intel took this concern and ran with it (pdf).
Essentially they created a “one container per VM” solution and optimised the VM. The hypervisor layer is a stripped down and optimised KVM/QEMU solution. Each VM then runs on a minimal Linux OS (“Clear Linux”) that’s been optimised for this work (fast boot times, minimal drivers, optimised for running a container).
So now we have VT-x protections between containers, because there are no containers sharing the same kernel. To make this solution more transparent they have created a “docker runtime” plugin, so Clear Containers can be managed as if they were normal docker containers (eg Swarm, Kubernettes).
They’ve also worked with CoreOS and the OCI for compatibility with those layers.
But is this necessary?
Many of the risks of a shared kernel can be mitigated simply by not running containers as root (eg unprivileged Docker containers; the default) or by running a PaaS (eg CloudFoundry or Apprenda).
Clear Containers are more heavy-weight than a pure container-in-shared-kernel
model and wouldn’t be a suitable replacement for low level container calls
(eg clone() with CLONE_NEWPID and similar flags). But they’re faster
than building a traditional VM.
In this respect they may be a competitor for Canonical’s LXD solution, or perhaps VMware’s Instant Clone. Intel Clear Containters allow you to create a longer running container solutions packaged inside a docker container wrapper and gaining the protections of VT-x via the “one container per VM” model.
I’m not convinced there’s a good use case… but then I’m not convinced by the “container as lightweight VM” use case, either :-)