Keeping Docker containers safe

Weak Link

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.

Infos

  1. Docker daemon attack surface: https://docs.docker.com/engine/security/security/
  2. "Are Docker containers really secure?" by Daniel J. Walsh: https://opensource.com/business/14/7/docker-security-selinux
  3. SELinux: https://selinuxproject.org/page/Main_Page
  4. Stop disabling SELinux: https://stopdisablingselinux.com
  5. Everything is a file: https://en.wikipedia.org/wiki/Everything_is_a_file
  6. Principle of least privilege: https://en.wikipedia.org/wiki/Principle_of_least_privilege
  7. Docker user guide: http://docs.oracle.com/cd/E52668_01/E75728/html/section_rdz_hmw_2q.html
  8. Jenkins: https://jenkins.io
  9. Privilege separation: https://en.wikipedia.org/wiki/Privilege_separation
  10. Knoppix boot disks: http://knopper.net/knoppix/index-en.html
  11. Amazon S3: https://aws.amazon.com/s3/
  12. GlusterFS: http://www.gluster.org
  13. Docker security: https://docs.docker.com/engine/security/security/
  14. User namespaces have arrived in Docker!: https://integratedcode.us/2015/10/13/user-namespaces-have-arrived-in-docker/
  15. CIS Docker 1.11.0 benchmark: https://benchmarks.cisecurity.org/tools2/docker/CIS_Docker_1.11.0_Benchmark_v1.0.0.pdf
  16. AppArmor: http://wiki.apparmor.net/index.php/Main_Page
  17. Grsecurity: https://grsecurity.net
  18. PaX: https://pax.grsecurity.net
  19. Docker capabilities allowed and not allowed by default: https://docs.docker.com/engine/reference/run/
  20. Docker Bench for Security: https://github.com/docker/docker-bench-security
  21. Twistlock: https://www.twistlock.com
  22. AuthZ policy enforcement: https://github.com/twistlock/authz
  23. Twistlock demo: https://www.twistlock.com/demo
  24. rkt: https://coreos.com/rkt/
  25. "Moving from Docker to rkt" by Adriaan de Jonge: https://medium.com/@adriaandejonge/moving-from-docker-to-rkt-310dc9aec938#.ht63ldsn0
  26. KVM: http://www.linux-kvm.org/page/Main_Page
  27. rkt documentation: https://coreos.com/rkt/docs/latest/running-kvm-stage1.html
  28. rkt with containers vs. KVM: https://coreos.com/rkt/docs/latest/running-kvm-stage1.html
  29. containerd: https://containerd.io
  30. rkt vs. other projects: https://coreos.com/rkt/docs/latest/rkt-vs-other-projects.html
  31. Dangers of the docker group: https://www.andreas-jung.com/contents/on-docker-security-docker-group-considered-harmful

The Author

Chris Binnie's new book Linux Server Security: Hack and Defend shows how hackers launch sophisticated attacks to compromise servers, steal data, and crack complex passwords so that you can learn how to defend against such attacks. In the book, he also talks you through making your servers invisible, performing penetration testing, and mitigating unwelcome attacks. You can find out more about Linux servers and security at his website (http://www.linux-server-security.com).

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs



Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>
	</a>

<hr>		    
			</div>
		    		</div>

		<div class=