How Docker Changes Cloud Security

People have been skeptical about the security of cloud technologies since the beginning of cloud computing. The idea of multitenancy -- that you could be on the same physical hardware as a stranger, even with the promise of virtual machine separation -- has always had an overtone of security disaster.

Time has shown that virtual machines do offer a strong layer of isolation, and more companies are adopting them every day. Docker containers are like micro virtual machines. For example, if a server could host 10 virtual machines, the equivalent server could host 100 or even 1,000 Docker containers.

The bad news is that out-of-the-box Docker is less secure than virtual machines and most cloud technologies. Because Docker containers share a Linux kernel, there's more risk that a kernel exploit could lead to privilege escalations. In layman's terms, multitenancy with Docker is a bad idea because there isn't enough inherent separation between containers to totally ensure that one customer can never access another customer's container.

[Having trouble identifying cloud benefits? Read Cloud ROI: 6 Takeaways To Consider.]

There are ways to mitigate this risk. For example, using Security-Enhanced Linux (or SELinux, originally developed by the NSA) makes it so that even if the Linux kernel is compromised, there's limited ability to do anything outside the container. But perfecting that setup can be challenging.

Reduced attack surfaces
The good news is that Docker's architecture of a shared Linux kernel actually enables you to dramatically reduce the attack vector surface area for Linux application development. If you're building technology that doesn't require multitenancy (like software for banks, retailers, and online businesses), you can actually improve your security by adopting Docker.

How? If you start with a minimalist Linux operating system built for Docker, like the open source CoreOS, you reduce the potential attack vectors on your host machine. CoreOS strips out most of the features and functionality from Linux, including package managers like apt-get and yum. It's difficult to install external code on CoreOS without using Docker. If you want to install Apache, for example, you must do it by pulling in a Docker container with Apache inside of it.

This requirement reduces one set of attack surface areas, because the accidental running of insecure code on the Docker host becomes much more difficult. But when you combine CoreOS with a special Docker feature called "scratch image," the security benefits become even clearer.

Scratch image is the most minimalistic Docker container. What exactly is in it? Absolutely nothing. It's built from an empty tar file. Not only is there no Apache, but no binaries are built in at all. This concept of no-binary disk images wouldn't be possible with virtual machines because virtual machines don't share Linux kernels, which means they need to come with their own binaries in order to function.

There is interesting work being done right now on building single-binary Docker containers using compiled Go binaries. This work dramatically reduces the attack vector surface area inside the Docker container itself. For example, if you're running your application code inside a scratch image, you don't have to worry about the Bash Shellshock bug. That's because you don't have bash in your container in the first place. The only possible OS-level (non-network) attack vector becomes the Linux kernel itself.

Tenets of securing Dockerized apps
When you combine minimal operating systems like CoreOS with SELinux and the scratch image, you remove unnecessary pieces of technology that could be exploited. Unlike with most Linux distributions, which bundle lots of unnecessary tools, with Docker you can create finely tuned, highly efficient clusters of infrastructure with fewer attack vectors.

When you combine that approach with the network-layer security features that Docker Inc. is planning for the coming year, the security value proposition for Dockerized application deployments becomes that much better.

Of course, this approach doesn't help much if the applications you build within Docker have vulnerabilities, but sometimes the unknowns are the things that haunt us the most. How many more Heartbleeds and Shellshocks are sitting in /usr/bin completely undiscovered?

Who wins in cloud price wars? Short answer: not IT. Enterprises don't want bare-bones IaaS for the same reasons they don't buy many $299 PCs at Wal-Mart. Providers must focus on support, not undercutting rivals. Get the Who Wins In Cloud Price Wars? issue of InformationWeek Tech Digest today. (Free registration required.)