Understanding Security and Containers

Containers have become the technology du jour in the DevOps world because they offer many concrete advantages. They allow for more agile infrastructure. They simplify software development and delivery workflows. They enable applications to be delivery platform agnostic.

However, one dimension of the container conversation revolves around security. While containers in some ways help to mitigate the security challenges associated with traditional application development and delivery, they also create new ones.

The security implications of containers are changing rapidly as new security tools emerge for the container ecosystem. Just this past spring, Docker and CoreOS debuted new security scanners for containers in the form of Docker Security Scanning and Clair. As a result, what was true about container security best practices a few months ago may no longer be accurate. However the principles that held true about security on virtual machines, private cloud, or physical infrastructure remain true in many cases.

Security benefits of containers

Containers are a new technology. New technologies are generally associated with security risks, for the simple reason that what is new has not been hardened by experience in the real world.

This does not mean that everything related to containers and security is negative. In many ways, containers help to solve the security challenges associated with monolithic apps. They do this in the following ways:

• Containers can reduce environmental variability. Platforms like Docker provide a consistent environment for running apps regardless of the operating system, storage solution, or networking configuration running on the host, they make runtime environments more consistent. That is a plus when it comes to security, since consistency means more predictability and a smaller attack surface.
• Containers isolate different parts of the application. Containers break applications up into discrete pieces. If an application is containerized, the front end code is usually in a separate container than the backend or database. This approach offers the security benefit of isolation. If an attacker breaches one part of the app, she does not necessarily have access to the whole running environment.
• Containers minimize the attack surface of your application infrastructure. With traditional infrastructure, an application would usully run directly on a bare-metal server or inside a virtual machine powered by VMware, KVM, Hyper-V or another hypervisor. Deploying applications on these platforms often requires a complex deployment platform. In contrast with containers, you only need to set up the container and the host. If you design your architecture properly, each container has only the minimal amount of code and dependencies necessary to run your app. That means a smaller software stack and fewer potential vulnerabilities for attackers to exploit.

Container security challenges

Containers also create new security challenges that need to be considered.

• Potential isolation issues. One of the advantages of containers over type-1 hypervisors such as VMware, is that they share more resources with the host environments, allowing them to be more densely populated on hosts. That makes containers lighter-weight and reduces overhead. This has the side effect of potentially increases the chances that a security breach inside one container could lead to breaches inside other containers running on the same host. There was a working exploit for this up until Docker 1.0.1 This was, historically, a more serious problem than it is today. Currently, there is no known vulnerability in Docker that allows an attacker to escalate privileges from inside one container in order to compromise another one, but it is a concern as with new technology.
• Risks from using public container images. Part of the beauty of containers is that they allow you to pull and deploy a packaged service. For example if you want to fire up an NGINX server you can `docker pull nginx` and an NGINX container image from a public repository will be deployed and run on your host. There is nothing inherently wrong with using public repositories, in fact the in most cases the opposite is true. There is always a risk with running untrusted code, and having an audit trail from source to binary is important in any environment. When using a public container registry, you are trusting the maintainers to secure their software and you are trusting that the people who designed each container image have secured it and not intentionally left it vulnerable. This is why the security scanner and trusted builds are important tools, but not the only things one has to pay attention to.
• ITOps doesn’t fully understand containers. The nature of containers being a new technology to most businesses is a risk in and of itself. They raises new, unfamiliar security risks. Despite cgroups and therefore containers technically being available in the kernel since 2008 Docker has been around for only three years. Few programmers or admins have much training or experience in container technology. As a result, people who create and manage containers may not yet have the experience to do so securely. We know that there were many, many vulnerabilities running wild in the docker hub before security scanning was introduced, as a result of this inexperience.

Some of the security challenges associated with containers will be overcome with time as newer security tools emerge and DevOps teams gain more experience with containers. Some of these risks will only be mitigated with the same resolve and persistence that security professionals are known for.

Either way, organizations can help to reduce the security risks of containerized infrastructure by making sure that they do not approach containers blindly or lightly.