I have been following containers for quite some time now. A year ago it was safe to say that container technologies like Docker were far from production ready when it came to security. What I have seen over the past year is a ton of development towards closing that gap. For this post, I’ll focus on Docker.
Addressing Security Gaps
Let’s start with the Docker Engine.
The Docker engine is a lightweight runtime that builds and runs Docker containers. It contains an in-host daemon that communicates with Docker clients to execute commands. The big security issue is that the daemon runs as root.
Changing this would require a major architecture change in Docker. In fact, this issue is what led the folks at CoreOS to build Rkt (pronounced “Rocket”). The solutions to this problem are many.
- Running containers inside of VMs is a common solution. VMs are very mature and secure and can provide a layer of security around the container.
- Only allow trusted users to control the Docker Daemon
- Docker now uses UNIX sockets as opposed to TCP socket bound by 127.0.0.1 which was prone to cross-site scripting attacks. This allows for the use of traditional UNIX permission checks to limit access.
- Docker machine sets up signed certificates for authentication and encryption for Docker engine (daemon) access.
Another gap that Docker is working on securing Docker Images. A Docker Image is a read-only template that contains the instructions for building a container. For example, the tomcat:7 image contains everything necessary to install Apache Tomcat version 7. When creating a container, the Docker client will communicate with the daemon to send the instructions contained within the image to build the container. Since the daemon runs as root, this creates an opportunity for unauthorized access. To combat this, Docker has made a number of enhancements.
Docker recently announced Docker Content Trust which uses Notary, an open source tool that uses key pairs to secure content . The goal of Notary is to secure the distribution of image content so that consumers of Docker Images can trust that the content is genuine and that the communication between the client and the daemon is secure. Notary is based on TUF, which is a framework for securing software distributions and updates.
Advantages of container based architectures
One point that is often missed when discussing container security, is that there are a number of advantages of container based architectures. Here is a short list:
1. Isolation – Docker containers run as isolated processes. As you can see from the image below, each container is totally isolated from the each other and each has their own security settings and policies. Access between containers must be explicitly assigned.
Containers have no default access to any physical devices thus reducing the attack surface.
2. The nature of containers facilitates faster and easier patching and updating of the OS, application, and infrastructure layers. In traditional systems, the layers are patched independently, often by different teams. With containers, patching is performed on images and a Dockerfile which contains all of the dependencies. This creates a much simpler and easier to automate process and allows for all changes to be processed and tested together, thus improving the overall quality of the process.
Summary
There is still much room for improvement for securing containers. However, many companies are moving forward with containers in production by leveraging containers with VMs. The current state of Docker security is miles ahead of where it was a year ago at this time and it continues to improve with each release. For more information on Docker security, check out their whitepaper.