Every enterprise is looking to create more agility when it comes to delivering apps, which is one of the reasons the concept of containerization is so hot.
Containerization is, essentially, encapsulating applications into a “container” that can be deployed to any suitable environment, or hardware, without having to worry about other dependencies. When someone needs an application shifted to a certain cloud, or server – they just do it. My CSC Blogs associate Steven J. Vaughan-Nichols has written about the various choices enterprises have when it comes to containers, as well as the evolution of containers.
But security is also essential when it comes to containers. These self-containing app buckets can shift around pretty quickly, and the containers need to be managed securely and updated property, and they require all of the other hygiene and controls that constitute good security. The good news is that, recently, one of the leading container companies, Docker, made some fairly big strides in security with the release of Docker 1.10 and hinted at additional security capabilities coming in the future.
First, what’s coming soon is what Docker calls the PIDs Control Group, a way to limit processes that can be forked into cgroup to 512 processes. This should help with the so-called fork bombs, when a process replicates to the point of depleting resources and creating a denial-of-service condition. Here is the commit kernel for the PIDs Control Group.
As for what came out this week:
This one has been long-time desired by many, and it improves the ability to create specific access policies through using multiple namespaces within a Docker host. Here is a demo. User Namespaces have been available for awhile in experimental; this good post that describes them.
These plugins bring more access-policy maturity to Docker. As Docker’s security post details, “using an authorization plugin, a Docker administrator can configure granular access policies for managing access to Docker daemon. System administrators can use these plugins to configure user access policies for their infrastructure.” These authorization plugins will permit or deny access to the Docker API based on user policies, and work the same as other volume and networking plugins in Docker. The pull request is here docker/docker/#15365.
Seccomp profiles provide more control over processes. They enable processes to be allowed, denied, trapped, killed, or trace through through the arguments and syscall numbers sent, according to Docker. It adds an extra level of granularity in locking down the processes in your containers to only do what they need,” according to their security post. There is more available on Seccomp on Github here, and this is the original pull request.