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 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.