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.