A User Guide For Securing Docker Containers
As important and prevalent Docker containers are today, they still pose a unique security risk for users. Containers simplify the distribution of software and allow greater sharing of resources on a computer system, which is great and well used in today’s IT environments. But adding more applications onto a system also increases the chances for a security breach.
Let's take a look at common container security challenges and the six strategies that can be used to help solve or mitigate them.
First: What security issues do containers pose? The answers are important because security threats on containers fall into several different categories.
They include the risk of privilege escalation via containers. For example, if an attacker can get inside a containerized app, that could become a stepping stone to gaining root access to the host system. Another security threat is an attack originating from one container that compromises data or resources used by a different container. This could potentially happen even without getting root access.
Similarly, you could face simple denial-of-service (DoS) attacks where one container seizes control of all available system resources in order to stop other containers from operating properly.
Last but certainly not least is the risk of insecure or un-validated app images. Part of the magic of containers is how quickly and easily they let you spin up apps based on images that you pull from a repository. If you’re downloading from a public repository, however, there is a risk that you’ll get an image containing malicious code, or that someone has tampered with the repository's authentication mechanism to insert a malicious image in place of what appears to be a validated, signed image.
Some of these threats are common in any type of computing environment. Security validation is always an issue with a public code repository. With Docker containers, the threats are amplified in certain respects. For instance, the privilege escalation issue would not be as serious if you were using a traditional hypervisor, like a kernel-based virtual machine (KVM) or Hyper-V. There, the virtual environment would be strictly abstracted from the host system.
With Docker, a process running inside a container by default has the same namespace as one on the host system. That makes it much easier for someone who gains root inside a container to get root on the host system. With traditional virtualization, in contrast, getting root access on a guest won’t do much to help you become root on the host.
Repository validation and image signing also arguably represent special threats in the container world. That’s because it has become common for administrators to pull images from public repositories maintained by unknown persons. This is a cultural issue more than a technical one. But it’s also a problem that isn’t as serious within the context of public repositories used for other purposes, like installing packages on a Linux system. There, admins tend to stick to the “official” repositories and packages delivered by the maintainers of their distribution.
Hence, security remains a serious concern when it comes to containers. Fortunately, solutions are emerging to make it easy to address container security. Among them are:
- Always start Docker containers with the "-u flag" so they run as an ordinary user instead of root. This is a basic first step toward improving security.
- Taking that a step further, remove SUID (Set owner User ID) flags from container images. This makes privilege escalation attacks even harder.
- Configure Docker control groups (also known as "c groups"), which helps set limits on how many resources each container can use. This will go a long way toward preventing container-based DoS attacks. (Note, however, that c groups aren’t intended to help provide other security isolations between containers—to do that, use namespaces.)
- Use namespaces in Docker to isolate containers from one another. Namespaces help assure that a user or process running inside one container can’t affect those in other containers.
- Don’t use images from untrusted repositories. In particular, avoid public repositories if they are not from an official source and you don’t know the maintainer. This may sound like a no-brainer, but it’s worth noting because it is often tempting to pull an image from a random registry.
- Consider using Clair (the CoreOS container security scanner) to validate containers from your registries. You can use Clair to scan images locally or you can run it directly from public registry services that are supported (which, for now, include CoreOS’s own platform, Quay, as well as Dockyard).
Container security remains a challenge. But it’s no longer an issue that can’t be solved without the same basic level of vigilance as that demanded by any other type of security challenge in a modern computing environment. Taking the steps will help secure containers.
Mark Bloom is the director of product marketing for compliance and security at Sumo Logic. Connect with him on LinkedIn or follow him on Twitter @bloom_mark