Docker Addresses More Security Issues and Outlines “Pluggable” Approach
Docker has released a new version of Docker Engine aimed at reducing some of the security concerns around Docker’s potential to be exploited with malicious images. While the new security features introduce greater validation of images in containers to improve the chain of trust, Docker, Inc. is also seeing new threats that it now has to manage.
After releasing 1.3.2, Docker writes that they discovered additional vulnerabilities that could be exploited by a malicious Dockerfile, image, or registry to compromise a Docker host, or spoof official images. The remediations have been released in both Docker Engine 1.3.3 and Docker Engine 1.4. In the post, Docker encourages users to upgrade to Docker Engine 1.3.3 or higher. There has also been the introduction of a new overlay filesystem as an experimental storage driver. The post also states:
Please note that these vulnerabilities only affect users downloading or running malicious images, or building from malicious Dockerfiles. Users may protect themselves from malicious content by only downloading, building, or running images from trusted sources.
The post was written by Marianna Tessel, Docker’s senior vice president of engineering who recently joined the company from VMware where she had a degree of focus on security issues. CEO Ben Golub said in a recent interview that Tessel will help make security an important aspect of its technology development.
She writes that Docker Engine takes advantage of the security mechanisms and isolation provided by the OS:
This is pluggable, with support on Linux for namespaces, capabilities, and cgroups implemented through either libcontainer or lxc. In the future, we expect new execution engine plugins to offer more choice and greater granularity for our security-focused users. These mechanisms are part of what define a container and running in a container is safer than running without. On systems where supported, Docker has incorporated SELinux and AppArmor integration. Red Hat, Canonical, and other companies have been active members of the Docker community to help us drive security forward.
Docker has always been fairly up front about their security limitations. For the past four months, Docker’s Jerome Petazzoni has presented at several conferences around the globe, often joking that Docker’s security status is best described as “it’s complicated”.
Petazzoni — and Docker Inc.’s — official line is that because Linux containers weren’t made for security, the security concerns are not of Docker’s making. Part of the problem stems from the fact that when root access is granted to an application within a container, it will then be able to access the root privileges of the container’s underlying operating system.
Lenny Zeltser, a security IT leader and blogger wrote yesterday that while Docker addresses root access by isolating the underlying host from an application running in a container without root privileges, “this separation is not as strong as that of virtual machines, which run independent OS instances on top of a hypervisor without sharing the kernel with the underlying OS.”
Zeltser mentions four security benefits of using containers, including the ability to segregate applications on the same host; treating application environments as transient; use of scripted setup instructions to ensure greater control over data and software; and greater frequency of security patching. But he also addresses three key security risks with container technology:
- “The flexibility of containers makes it easy to run multiple instances of applications (container sprawl) and indirectly leads to Docker images that exist at varying security patch levels.
- The isolation provided by Docker is not as robust as the segregation established by hypervisors for virtual machines.
- The use and management of application containers is not well-understood by the broader ops, infosec, dev and auditors community yet.”
Startups don’t generally talk about security, said Tal Klein, vice president of marketing for Adallom, which focuses on evolving the way enterprises secure information in SaaS by monitoring all activity, detecting unauthorized access, and protecting users in real time.
Like any startup, Docker is focused on scale, Klein said. But like most startups, security is not often discussed in the early days. And until now, they really have not had to talk much at all about security as the converastion is more about faster development and the different aspects of the container approach. But now with its growing popularity, Docker needs to engage more with the security community. It’s Docker’s opportunity to get it right.
Docker, for its part, is proposing a new trust system chain that aims to create stricter requirements so that Docker users can have greater confidence in the origin of Docker images.
But Docker, Inc.’s announcement also speaks to the partnerships with operating systems: Red Hat, Canonical (who released Snappy Ubuntu this week), and “other companies,” which you could imagine might include Microsoft. By noting that these operating systems “have been active members of the Docker community to help us drive security forward”, Docker is maintaining its position that the security fault is not with Docker per se, but a limitation of the broader Linux containers approach.
Feature image via Flickr Creative Commons.
