A week or two ago The Register carried a story about a Docker image security audit a company called BanyonOps had carried out. BanyonOps published its findings in a blog post, and frankly, they are quite alarming.
- In DockerHub, the official repository for Docker images, more than one-third of the images have high-priority security vulnerabilities, and over two-thirds have some level of vulnerability.
- In general repositories (those placed by general users), the figures were even worse -- 40 percent and 70 percent for high-priority and general vulnerabilities, respectively.
The risk to which Docker users are exposed is critical to understand, both because of the seriousness of the vulnerabilities -- which is significant, but also because of the high likelihood that Docker users will use these images, particularly those from the official repository, as the starting point for their applications.
This is completely understandable. Developers are in a hurry to get their application up and running, and downloading an “official” image seems like it can help. In fact, it might even seem like a good idea, when the potential downloader sees this on DockerHub:
Because the official images are intended to be learning tools for those new to Docker as well as the base images for advanced users to build their production releases, we review each proposed Dockerfile to ensure that it meets a minimum standard for quality and maintainability.
The text goes on to recommend “Version bumps and security fixes should be attended to in a timely manner.” A Docker employee put up a personal post to discuss these findings and noted that many of the vulnerabilities in official images are found in older container versions, e.g., Ubuntu 12.04, which are left unchanged to enable backward compatibility testing. This is a good point and undoubtedly reduces the security vulnerabilities present in official Docker versions.
However, the situation still seems problematic, in that the security state of a given official container seems undefined and Docker does not appear to have a process in place to systematically address security issues that present themselves. By way of comparison, AWS provides Amazon Linux AMIs; can one imagine AWS not having a structured process to evaluate Linux security issues and ensure its AMIs are brought up to date? Clearly, Docker needs to improve the official Docker image process regarding security.
What Does it Mean for Docker Users?
From an end user perspective, dealing with the situation as it stands today is challenging, to say the least. An organization can use official images and face some probability of exposing security vulnerabilities within their applications. Or, to avoid this, it can take the images and attempt to fix the vulnerabilities themselves. The former poses unacceptable risk; the latter means taking on extra work and, crucially, missing out on one of the biggest benefits of containers -- the ability to use an unchanged, consistent container throughout the application lifecycle, thereby enabling automation and faster deployment.
At ActiveState, we confront the same issue -- how to ensure that the Stackato Docker images are secure. Rather than rely on images of uncertain provenance, however, we take a different path. We provide initial base Docker images as part of the Stackato product. After Stackato is installed, administrators can further modify the images to install security patches, etc. in a centralized manner. This ensures that what developers use is fully secure and compliant with organizational requirements. In addition to using these trusted Docker images, we also apply a robust set of security practices to avoid vulnerabilities so that our users may be certain about the quality and security of their Stackato applications. Furthermore, we proactively communicate with our users regarding important security patches so that they can keep their systems secure.
It should be noted that our latest release of Stackato does support Docker image import -- the ability for users to bring pre-existing Docker images into Stackato. This allows users to gain many of the benefits of Stackato -- monitoring, management, autoscaling, and so on -- for their own Docker images. However, our best practice recommendation is that users be very careful about placing imported Docker images into important use, i.e., into production. Of course, the cluster administrator retains control over which images are allowed into the cluster, whether from internal or public repositories.
If you want to learn more about our Stackato security practices, you can read our security whitepaper here.
In summary, at ActiveState we recognize the power of containers and of Docker itself. We use Docker as a core part of our Stackato product. However, the question of Docker image provenance is critical and one that every organization interested in Docker should be aware of. While the BanyonOps blog does raise an alarm, it is not the case that users have to choose between insecure anarchy or no Docker at all. It’s critical that IT organizations have processes and tools that enable Docker to be used in a secure fashion, thereby ensuring that both agility and security are achieved.