As Docker adoption increases, so does visibility into Docker containers’ security weaknesses. Here’s an overview of the types of security and privacy vulnerabilities that have been discovered in Docker containers so far.
Docker environments are complicated, more so than environments built using virtual machines or bare-metal servers. Because there are so many different tools and layers of services inside a Docker environment, securing containers can be especially difficult.
Docker Security Fault Lines
While it’s impossible to predict the place within Docker stacks where the next security vulnerability will be revealed, the following is a list of areas within a Docker stack that have already proven difficult to secure adequately:
- API endpoints. Docker containers and microservices rely very heavily on APIs to communicate with one another. All of these connections create fruitful opportunities for intrusion. One such vulnerability was recently revealed by Aqua Security. The company showed how the Docker API can be used to drop malware and execute remote code on a Docker host.
- Privilege escalation. Because containers don’t create the same level of deep isolation between the host environment and guest applications as do virtual machines, privilege escalation from a containerized application onto the host server is a challenge. This is the type of attack that was made possible by a vulnerability in runC that was discovered early this year. This particular vulnerability has since been fixed, and Docker is designed to mitigate privilege escalation risks to the extent possible by isolating processes. Due simply to the nature of containers, however, it’s likely that other types of vulnerabilities that enable privilege escalation will be discovered going forward.
- Container image registries. One of the things that makes Docker so great is that, with just a few commands, you can pull a container image from a registry and start an application based on it. But this also creates a security risk: If you don’t trust the content of your images or the maintainer of your registry, you can’t be sure that malicious code is not being hidden inside the images you use. Image scanners such as Clair can help defend against these attacks, but they’re no guarantee that malicious code won’t slip by.
- Private data inside container images. A misconfigured Docker environment could also lead to the leaking of sensitive data. For example, you don’t want to put source code inside container images. This isn’t a security vulnerability per se, but it is an example of how misuse of Docker containers can compromise data privacy. The fact that containers are a new technology that has not yet been addressed well by most data governance policies makes risks like this especially prevalent.
- Persistent storage. In most cases, Dockerized applications store data persistently on the host server or on distributed storage systems. In either case, the data is essentially hosted outside the container environment. Even if your Docker environment is secure, application data could be at risk elsewhere. This, too, is not a security problem with Docker itself, but rather with the way Docker environments are architected. There’s no good solution other than to make sure to keep your storage environments secure as well as your Docker environment.