If you're an application developer or a system administrator in a virtual environment, chances are good that you've...
been hearing quite a bit about Docker over the past year or so. The platform for Linux application container virtualization is "on fire" popularity-wise -- and for good reason. The agility advantages Docker can offer to development teams and the performance advantages that it can brings in the data center can be game changing.
For security pros, however, Docker might be less familiar. Many probably do not yet have it on their radar, and for those that do, they might be struggling to ramp up quickly on the security aspects of the tool, asking: How does Docker change our security profile? What should we be thinking about as usage becomes more widespread? How do our existing security mechanisms fit into a Docker-enabled environment?
In this tip, I am going to take a detailed look at Docker, diving into what it is and why it's so popular, as well as some of the security ramifications.
If you're a security pro, Docker needs to be on your radar, firstly because given its popularity you'll want to be thinking about how to secure it in the short term. Secondly, Docker is important to know because (depending on how you approach it) using the tool might ultimately offer some security advantages long term. Here is an introduction to Docker and its implications for enterprise security.
What is Docker?
In a nutshell, Docker is a Linux-based, open source application container abstraction and virtualization mechanism. While "Linux-based open source" probably won't confuse anyone, "application container abstraction" very well might. Complicated as it might seem initially, the concept itself is fairly straightforward. Essentially, Docker is a way to create a self-contained virtual environment (i.e., a "container") within which applications can "do their thing." This virtual container provides the application with its own semi-private (and isolated) "view" of the underlying operating system, including resources like storage, networking, processes, etc.
In many ways, this is conceptually similar to OS virtualization. However, think about the "overhead" in a virtual OS image that applications don't care about or specifically use. For example, consider two Web applications both running a LAMP stack. How much of that underlying stack varies between those applications? As a percentage of the overall OS installation, it's not that much, right? Virtualizing just the application (for example, using the Docker Engine) allows one virtual or physical OS instance to isolate applications from each other. This in turn allows creation of application packages that are much lighter-weight, smaller and contain only what they need to run.
Developers find this concept powerful because it allows for more portable and more easily customized containers for their apps, meaning they spend less time customizing the OS environment and more time developing application functionality. Data center teams find the concept powerful because it allows more efficient use of resources and thereby allows a higher allocation density in the data center (e.g., more apps and fewer resources to support them).
But what about Docker security?
From a security point of view, application virtualization might sound appealing. After all, some security pros might see this as an extension of the idea of using chroot to sandbox a file system -- or as a direct analogue to a "jail" under FreeBSD (both of which are ways to insulate the underlying system from compromise of an individual application). While there is some merit to this point of view, there are a few differences that are important to note -- and things that security pros should be aware of as they evaluate Docker security and build controls around it.
First off, only recently has there become a way to automatically verify the integrity of an official Docker image. Official images contain the core utilities and software that an application might need in order to run. This could be an official version of a Linux base image, a middleware component like MySQL or postgreSQL, or a front end component such as Apache or WordPress.
A relatively recent change (as of the October release of version 1.3) allows automated digital signature verification so that users of those official images can have some assurance that an image hasn't been tampered with before it is pulled down. Because of this feature, tampering with official images will become less of a concern in the long run. However, because there may still be a few pre-1.3 installations out there, one short-term step you'll want to have on your to-do list (for pre-1.3 deployments) is to give the images you download and install a little extra scrutiny.
It goes without saying that addressing pre-1.3 installations is a good idea anyway. Like any software, the Docker engine itself can have vulnerabilities. For example, the recent 1.3.2 update addressed some significant security issues which undermined segmentation between containers, one vulnerability allowed an image to loosen security restrictions and another allowed arbitrary file system writing (and thereby code execution). These problems should serve as a good example as to why staying on top of security hygiene and keeping software patched and up to date is an absolute must.
A second consideration to keep in mind is that application containers do not necessarily enforce the same level of isolation as a hypervisor would between "slices." They've done quite a bit to insulate applications from each other to be sure, but their guidance is that, "Traditional virtualization techniques (as implemented by Xen, VMWare, KVM, etc.) are deemed to be more secure than containers, since they provide an extra level of isolation. A container can issue syscalls to the host kernel, while a full VM can only issue hypercalls to the host hypervisor, which will generally have a much smaller surface of attack."
This guidance can and should influence your organization's usage. For the short term, you'll want to be cautious about how much trust you put in the isolation mechanisms. For example, if you're evaluating a multi-tenant situation where you have limited or reduced control about what else might be running alongside your apps (such as in a public cloud situation), you might want to select carefully what applications are put into that environment. A use case like that one might be appropriate for a low-sensitivity app, but you may consider holding off on moving your HR or general ledger system there.
A security benefit?
For the pragmatist however, using application containers can have a security benefit when applied judiciously. First of all, consider the advantages offered from a management point of view that can serve to help inhibit complexity. Reduced complexity in itself can help advance robust security hygiene. For example, consider how much easier it would be to add a security mechanism, system update or hardening technique to a single platform that uses application containers compared to applying that same control across a number of disparate virtual OS instances.
Second, while it's the case that today an application container may not enforce the same level of isolation as a hypervisor, compare the protections it does offer to what are in effect on a "stock" Web server -- where the compromise of one application almost certainly means the compromise of the entire system.
The point is, just as there are some things that are important to approach cautiously from a security point of view, there are also some advantages. Depending on how you use it, Docker can be a useful part of your security toolkit today, and is certainly something to keep track of going forward.
About the author:
Ed Moyle is the director of emerging business and technology at ISACA. He previously worked as senior security strategist at Savvis Inc. and as senior manager at Computer Task Group. Prior to that, he served as vice president and information security officer at Merrill Lynch Investment Managers.
Learn more about the buzz around Docker
Uncover cloud security considerations for Docker hosting
Docker bumps up native security features