Running applications in containers rather than virtual machines is gaining traction in the IT community. This ecosystem presently revolves around Docker, a platform for packaging, distributing and managing Linux apps within containers. Though this technology is not very mature yet, it will evolve along the trajectory similar to that of VLANs and virtual machines. In the meantime, let's explore the security risks and benefits of using such containers.

The Degree of Isolation of Application Containers

Containers take advantage of the Linux kernel's ability to create isolated environments that are often described as a "chroot on steroids." Containers and the underlying host share a kernel. However, each container is assigned its own mostly independent runtime environment as with the help of Control Groups (cgroups) and namespaces. Each container receives its own network stack and process space, as well as its instance of a file system.

As of this writing, Docker does not provide each container with its own user namespace, which means that it offers no user ID isolation. A process running in the container with UID 1000, for example, will have the privileges of UID 1000 on the underlying host as well. Along these lines, a process running as root (UID 0) in a container has root-level privileges on the underlying host when interacting with the kernel.

Docker recognizes the lack of namespace isolation as a limitation and is working to address it. As of this writing, Docker introduced experimental support into the software that lays the foundation for being able to map a container's root user to a non-root user on the host.

Docker isolates many aspects of the underlying host from an application running in a container without root privileges. However, this separation is not as strong as that of virtual machines, which run independent OS instances on top of a hypervisor without sharing the kernel with the underlying OS. It's too risky to run apps with different security profiles as containers on the same host, but there are security benefits to encapsulating into containers applications that would otherwise run directly on the same host.

Locking Down and Patching Containers

A regular system often contains software components that aren't required by its applications. In contrast, a proper Docker container includes only those dependencies that the application requires, as explicitly prescribed in in the corresponding Dockerfile. This decreases the vulnerability surface of the application's environment and makes it easier to lock it down. The smaller footprint also decreases the number of components that need to be patched with security updates.

When patching is needed, the workflow is different from a typical vulnerability management approach:

• Traditionally, security patches are installed on the system independently of the application, in the hopes that the update doesn't break the app.
• Containers integrate the app with dependencies more tightly and allow for the container's image to be patched as part of the application deployment process.
• Rebuilding the container's image (e.g., "docker build") allows the application's dependencies to be automatically updated.
• The container ecosystem changes the work that ops might traditionally perform, but that isn't necessarily a bad thing.

Running a vulnerability scanner when distributing patches the traditional way doesn't quite work in this ecosystem. What a container-friendly approach should entail is still unclear. However, it promises the advantage of requiring fewer updates, bringing dev and ops closer together and defining a clear set of software components that need to be patched or otherwise locked down.

Security Benefits and Weaknesses of Containers

Application containers offer operational benefits that will continue to drive the development and adoption of the platform. While the use of such technologies introduces risks, it can also provide security benefits:

• Containers make it easier to segregate applications that would traditionally run directly on the same host. For instance, an application running in one container only has access to the ports and files explicitly exposed by other container.
• Containers encourage treating application environments as transient, rather static systems that exist for years and accumulate risk-inducing artifacts.
• Containers make it easier to control what data and software components are installed through the use of repeatable, scripted instructions in setup files.
• Containers offer the potential of more frequent security patching by making it easier to update the environment as part of an application update. They also minimize the effort of validating compatibility between the app and patches.

Not all is peachy in the world of application containers, of course. The security risks that come to mind when assessing how and whether to use containers include the following:

• The flexibility of containers makes it easy to run multiple instances of applications (container sprawl) and indirectly leads to Docker images that exist at varying security patch levels.
• The isolation provided by Docker is not as robust as the segregation established by hypervisors for virtual machines.
• The use and management of application containers is not well-understood by the broader ops, infosec, dev and auditors community yet.

Containers are Coming

The current state of application containers is reminiscent of the early days of other segmentation technologies, namely VLANs and virtual machines.

VLANs were created for performance and convenience. They allow defining Ethernet broadcast domains flexibly across multiple switches. As an isolation tool, they are useful for improving the network's performance. They were initially seen as risky due to software, hardware and security implementation flaws. Security concerns with VLANs still exist, but the technology and management practices have matured to the point that rare is a network that doesn't employ VLANs in some capacity.

Similarly, one could draw a parallel to the evolution of virtualization technologies. Even today, the flexibility that they provide acts as a magnifying force for accomplishing great IT feats, while also giving the organization plenty of opportunities to weaken its security posture. Yet, the proper use of virtual machines is now widely understood and accepted even in environments where data security is important.

Application containers, whether implemented using Docker, LXC, Rocket or another project, are gaining momentum. They are not going away. As the technology and associated processes mature they will address many of the risks outlined above. Security professionals can help shape the evolution of the container ecosystem by exploring its risks and mitigation strategies. We also need to be prepared to discuss containers with our dev and ops colleagues when the time comes. It'll be sooner than you think.