It’s been a crazy past few months with DockerCon and the holidays but yet we are still hacking away on the Docker Engine and have some really awesome security features I would like to highlight with the release of Docker Engine 1.10.

Security is very important to us and our approach is two-fold; one is to provide a secure foundation on which to build applications and second, to provide capabilities to secure the applications themselves. Docker Engine is the foundation on which you pull, build and run containers and all the features listed below are about giving your more granular controls for access, resources and other kickass stuff…

OK, enough with the introduction – let’s get to the good stuff!

Seccomp Profiles



Seccomp filtering allows a process to specify a berkeley packet filter to syscalls. In layman’s terms, this allows a user to catch a syscall and “allow”, “deny”, “trap”, “kill”, or “trace” it via the syscall number and arguments passed. It adds an extra level of granularity in locking down the processes in your containers to only do what they need.

This was first added into Runc and is in Docker Engine 1.10 with the passing of a profile defining the syscalls and the filters for them. There is also a default profile used when none is passed and if the container is not run as privileged. This was hashed out in docker/docker/#18780. We aimed to provide a usable default without being overly restrictive. However, you can also run containers with --security-opt seccomp:unconfined if you need to run without any seccomp profile.

If you would like to know more about Seccomp here and the original pull request here: docker/docker/#17989.

And here is the demo:



A Sneak Peek at Security Profiles

The seccomp profiles mentioned above are just the start of something even better. What started as a side project for a better way to write custom apparmor profiles, https://github.com/jfrazelle/bane, has turned into a proposal for native security profiles in Docker Engine. Now this is still being worked on but I wanted to give a teaser of what is to come – and of course give a plug to my awesome tool 🙂 You can read up and follow the conversation on this here.

User Namespaces

Phil Estes has worked hard to get User Namespaces into the stable release for Docker Engine 1.10. User Namespaces expands on the idea of granular access policies by allowing multiple namespaces to reside on the same Docker host.

Check out the demo:



Authorization Plugins

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. The plugins act as interceptors that can and allow or deny the docker API request based off the rules created by you! These plugins are installed and configured will work the same as the current plugins for volumes and networking via the Docker plugin API.

Many thanks to Dima Stoppel, Liron Levin, and the Twistlock team in contributing this feature to Docker Engine.

Learn more about creating or using an Authorization plugin here.

You can view the pull request here docker/docker/#15365.

There is a go package for easily making an Auth plugin available here.

Coming Soon — PIDs Control Group

This next feature will be in 1.11 but I wanted to give a teaser now. This is a new cgroup to limit the number of processes that can be forked inside a cgroup. It shipped in the 4.3 kernel. We decided to make this feature secure by default, meaning we are setting the PIDs Limit for the docker cgroup parent to 512 (actual number may change but something along these lines), more than enough for the average user, but not enough to do great harm. Of course if you need more you can override the default, or even set it as unlimited.

Awesome right? But the coolest part about this is the feature came to Linux, then Runc, and then Docker all by the same person, Aleksa Sarai! View the commit to the kernel here.

View the pull request to runc and the pull request to Docker.

Also this has been added to the docker stats command and API you know and love.

See how easy it is to prevent a fork bomb with --pids-limit for a container now:



The first part of the video shows a fork bomb in a container with bash, the second part shows docker stats . The container with the large number of pids is chrome 😉

As you can tell there are a lot of awesome things coming in Docker Engine 1.10. As always catch you on #docker-dev IRC or the github repo.

Watch this video on best practices for building secure Docker images

For more information, visit our Docker Security Center.

Additional Resources on Docker 1.10

Learn More about Docker