As Docker has exploded in popularity, so too has the open-source community around it. Now, as more and more large enterprise software companies jump on the Docker bandwagon, the community is tackling some of the larger issues behind the emerging technology, namely container security.

One of the big names driving security improvements in Docker container technology and the Linux kernel is Red Hat. Daniel Walsh, a Red Hat security engineer who’s spent the better part of 13 years working on the Security-Enhanced Linux module, is among those spearheading Red Hat’s effort to bolster container security with the features in Red Hat Enterprise Linux 7 and other open-source initiatives.

(Related: Docker does deployment reconstruction with CoreOS)

Walsh is in the middle of an OpenSource.com blog series on Docker security, covering subjects from why “containers do not contain” to the container security features in RHEL7, and an upcoming post on new features in the works like user namespaces, customizable SELinux types, and auditing. SD Times spoke to Walsh about Red Hat’s role in the Docker community, SELinux and RHEL7, and where the software container and delivery technology is headed.

SD Times: What spurred Red Hat’s participation in augmenting Docker security, and what are your ultimate goals for fortifying the containers?
Walsh: A couple of years ago I started working on a project called virt-sandbox, which was taking advantage of systemd and the libvirt-LXC package and setting up lots of containerized Linux services sharing the host OS. Imagine running hundreds of Apache containers sharing /usr but with a private /var and /etc. Last summer, the OpenShift team came to us and said their customers were all asking about the Docker strategy and wanted us to look into it. When we saw how Docker was taking off in the community, we decided rather than to attempt to compete against the community, we would join it.

At Red Hat, we look at open-source software with an eye toward how we can make it enterprise-ready. We looked at Docker and wanted to make it more consumable by the non-bleeding edge. We wanted to make sure it worked on supported file systems, so we added patches to make it work on ThinMapper. We wanted better isolation between containers from a security point of view, so we made it work with SELinux. In a lot of ways Red Hat is trying to do for Docker containers what we did for Linux: make it consumable by the enterprise users.

Can you expand upon the main point of your first blog post? What are the main security concerns surrounding containers?
They are not inherently unsafe; in a lot of ways they are more secure then running applications on bare metal. My point was just that a privileged process within a container should be thought of the same was as a privileged process outside a container. Root in container is the same as root outside of the container. I want people to think about the images that they are bringing onto their system. Who wrote the image? Do you trust the image?  I like to compare containers to Linux in the 1990s when people would grab random content off the Internet and install it and run it on their boxes, and not know if the content is trusted.

I want to destroy the idea that containers protect you in some way and make it safe to do this. I also want to prevent the flood of [common vulnerabilities and exposures] that come when people analyze the security of Docker and realize that it is fairly easy for a container’s privileged process to break out of the container. If this happens, Docker could get a bad image, stating that it is insecure. The bottom line was if you use the same security practices for running a service within a container as you do for running a service out of a container, then you should be fine.

How do RHEL 7 features like SELinux, namespaces and file system protections work to dispel the security weaknesses of Docker containers and the Linux kernel?
Well, all of these features are [aimed] at preventing privileged processes within a container from escaping the containment, although some of these features will block even unprivileged processes from causing problems.

Namespaces allow Docker to hide parts of the operating system from the processes running within the container. If a container’s processes cannot see other processes on the system, it is harder to attack them. Dropping Capabilities allows us to limit the power of root with the container.

The best examples of this are dropping sys_admin prevent processes within the container from using the mount command to remount read-only file systems and to mount other parts of the system. Removing net_admin prevents them from changing routing and iptables so they can see other networks. SELinux further blocks breakouts by preventing processes from reading and writing content that is not in the container. All of these can work together to control what the privileged process within the container can do.

Aside from the security features in RHEL 7, what are some of the other measures and initiatives Red Hat and the community as a whole are working to integrate into Docker?
A lot is happening, but I will mention two. One is at the file-system level. Docker relies on COW file systems. Originally it was using Unionfs, which was not in the upstream kernel. Red Hat introduced patches to allow you to run Docker on devicemapper and BTRFS back ends. Red Hat has some of the top kernel file system people, and they are looking at how to make these work better, and we are investigating a new file system called OverlayFS. The goal is to make these file systems work well on Linux, but also to minimize the overhead on processes introduced by the file systems. I believe when people are considering running Docker containers, they should really consider the quality of the kernel and specifically the file system support.

The second major effort by the community now is on “orchestration.” In a Docker world, where you had hundreds or thousands of containers running in your environment, how are you going to manage them and get them to communicate? Google, Red Hat, Twitter and others are working on projects around Kubernetes and Mesos to build an infrastructure for orchestration of containers.

What do you see as Red Hat’s role right now in the Docker community, and how might that role evolve going forward?
The Docker community is one of the most robust communities in the open-source world. Maybe too robust. One problem with Docker right now is it is a little company that is being flooded with people trying to help.

Studying and merging all of the patches flooding them have been a problem. They are adjusting and slowly growing the community of trusted committers on subsections of Docker. If they can build an infrastructure similar to what Linus [Torvalds] has done with the Linux Kernel, this would help.

Now we are working on getting proper signing into images so you can trust the content was not hacked. We are working on getting proper auditing into it so governments are more likely to use it. We are working on getting better systemd integration so it is as easy to build an image running a service inside a container as it is to run the service on bare metal. Also systemd integration should make multi service containers work better.

We are also looking at building an infrastructure to allow third parties to build “certified” application containers for RHEL.

What do you envision as the future of Docker in terms of not only enhancing container security, but also the short- and long-term innovation and adoption of the technology?
I don’t believe that container technology is the really interesting part of Docker. I believe that Docker will become a new standard for shipping software, and this is the game-changer. If a developer, quality engineer or end user can all build, test and run the exact same bits, it is less likely that a modification to a host will cause an application to break. I believe this is what will make Docker take off in the enterprise. But there are pitfalls in this, which companies like Red Hat have to solve.

If I am running lots of applications with their own userspaces, and we have a major vulnerability in something like OpenSSL, how do I check if any of my containers are vulnerable?

Docker security features on the horizon
Walsh gave us a preview of new features Red Hat is currently testing and developing to further bolster the security of container technology.

• User Namespace: Could allow the Linux Kernel to treat roots within a container as non-root outside of the container.
• Customizable SELinux Types: This could allow users to tighten or loosen the security of processes within the container.
• Libseccomp: Can be used to minimize the syscalls available to a container. This could potentially lower the attack surface on the container.
• Audit: Allows Red Hat to work with common criteria to allow easier adoption of container technology into governments.
• Proper Signing of Images: Affords the capability to cryptographically sign images and start to build trust into Docker pull and Docker push.