A Whole Host of Changes

Although I've run through a number of ways to harden your Docker daemon and containers, there are still issues presented by the not-so-helpful butler, Jenkins. When you add more security to any solution, there's always an overhead akin to adding PINs to your credit cards or another lock to your front door (so you have to carry another key and replace it when it's been lost). As far I've discovered so far, though, there's really only one type of solution to the problem of root user access being made available to the Docker daemon.

That solution is adding (potentially) lots of granular rules to each user or adding another type of user or process to intercept the commands being run. With this approach, you limit who can run what, mount what, download what, and so on. Initially, the overhead might be a little tiresome, but ultimately this solution offers a finely tuned level of access on each host.

One freely available way to create such rules is AuthZ from a pioneering company called Twistlock [21]. Their GitHub page spells out the basic policy enforcement [22]. The impressive Twistlock also has a commercial product that includes several additional eye-watering features, such as scanning containers for Common Vulnerabilities and Exposures (CVEs) in an efficient manner through a friendly web interface. Importantly, they also manage to remove the need to write lots of rules manually using sophisticated machine learning. Additionally, there's a free-to-try Developer's Edition that's sophisticated and brimming with useful features [23] and a useful whitepaper.

Rocket-Fueled Containers

A direct rival to Docker is the CoreOS product rkt (pronounced rock-it). CoreOS sells rkt [24] out of the box as "a security-minded, standards-based container engine." You might have heard of CoreOS, because they also produce etcd and flannel , which are used by OpenShift and Kubernetes, the container orchestration engines. You can find plenty of interesting security information on the CoreOS site.

I have only used rkt for testing but have been genuinely intrigued with how I might best use it in an enterprise environment. It is slick, performant, and – would you believe – Docker container-compatible. You might be able to tell that I'm a fan. Be warned, however, that its maturity could potentially cause stumbling blocks. There's more information on migrating between Docker and rkt online [25].

I mention rkt because it boosts host security by introducing a local hypervisor into the mix – KVM [26] in this example:

$ rkt run --insecure-options=image --stage1-name=coreos.com/rkt/stage1-kvm:1.21.0 docker://registry-1.docker.io/library/nginx:latest

The turbo-charged rkt uses a KVM plugin of sorts and announces that it's using an "insecure" (unsigned) image to launch a docker://-built image. The docs for this can be found online [27].

I will leave you to come to grips with how the clever isolation works, but the handy diagram in Figure 3 explains which component is used with the KVM approach and how it compares to the usual systemd method. I have read that similar functionality will be available via pluggables in Docker when it moves to using containerd [29] as its run time in a future version.

Figure 3: The components used when container and KVM methods are used to launch a container in rkt [28].

Horses for Courses

Which container solution suits your needs? The quick answer is that you have a whole host of options (pun intended), and you probably will not find a one-size-fits-all solution.

For more in-depth reading, you can spend a few minutes reading a comparison of current container technologies [30] on the CoreOS site, which could be biased, intentionally or not.

You have your work cut out securing containers. I hope the methods I've suggested for mitigating their security issues offers you some solace. Before you relax too much, however, you should read a somewhat scathing but informative blog post about the dangers of the docker group [31]. Comments such as "broken-by-design feature" are certainly a reminder to stay vigilant.