Container-based virtualization platforms provide a means to run multiple applications in separate instances. Container technologies can provide significant benefits to DevOps, including increased scalability, resource efficiency, and resiliency. Unless containers are decoupled from the host system, however, there will be the potential for security problems. Until that decoupling happens, this blog posting describes why administrators should keep a close eye on the privilege levels given to applications running within the containers and to users accessing the host system.

Containers have become the hot new technology in DevOps. One company in particular, Docker, has emerged as the go-to provider for container technology. Using the Docker platform, an application can be packaged into a unit referred to as an image, along with all its dependencies. Docker can then run instances of that image. Each instance resides within a container.

Docker is becoming synonymous with DevOps. If you are unfamiliar with the benefits of containers, in a nutshell they include the readily available images and easy-to-use public repository, image versioning, and the application-centric nature of Docker. (For more information see Three Reasons We Use Docker on devops.com.)

Containers also offer a lot of benefit when it comes to their size. Unlike a virtual machine, a container doesn't need the full operating system running or a virtual copy of all of the system's hardware. The container only needs enough of the operating system and hardware information to run the application that it is responsible for. As a result, the container can be much smaller than a virtual machine, so a host system can run far more containers than virtual machines.

To minimize what the container has to run, however, there are trade-offs. One of these trade-offs is less separation between the container and the host system. In contrast, virtual machines contain much more separation from the host than a container. The Docker user requires root privileges to run the containers. Problems can arise if the Docker user does not understand what is running in the container. Often these repositories are not vetted, meaning anyone can create and post an image. Obviously, there are security implications associated with putting too much trust in containers downloaded from the internet.

The problem of shared namespaces is often cited as one of the largest problems with Docker. A namespace refers to groups created by the kernel that designate access levels for different resources and areas in the system. The reason that Docker does not have different namespaces for each of its containers is scaling--if you have hundreds of containers running, each must have its own namespace. In addition, if a container wants to share storage, all namespaces sharing that storage must have explicit access to the storage.

In response to some of these security concerns Docker has come out with an article detailing some concerns about how they attempt to mitigate possible issues. Included in these mitigations is guidance for limiting permissions to the server both by those with access directly to the host and by applications running within the containers.

In addition to Docker's security guidance there are others that have chimed in to provide help in securing containers. One potential solution to the issue of shared namespace is to use Seccomp, a process security tool. Daniel Walsh detailed this work-around on opensource.com.

Administrators should always know exactly what your containers are running. Images downloaded from Internet repositories should be carefully vetted before being run in any sensitive environments. As a general rule, unlike the name implies, containers shouldn't be expected to contain running applications within the container.

Every two weeks, the SEI will publish a new blog post offering guidelines and practical advice for organizations seeking to adopt DevOps in practice. We welcome your feedback on this series, as well as suggestions for future content. Please leave feedback in the comments section below.

Additional Resources

To view the webinar Culture Shock: Unlocking DevOps with Collaboration and Communication with Aaron Volkmann and Todd Waits please click here.

To view the webinar What DevOps is Not! with Hasan Yasar and C. Aaron Cois, please click here.

To listen to the podcast DevOps--Transform Development and Operations for Fast, Secure Deployments featuring Gene Kim and Julia Allen, please click here.