Docker Puts Emphasis on Container Security with Docker 1.10

With user namespaces, privileges for the Docker daemon and container are handled separately, meaning each container can receive its own user-level privileges.  So while the Docker daemon would still require "root" privileges, a user can now be granted privileges at a lower level than root.  Root privileges give the user the same level of authority as a system administrator, which means it can open up and expose all the resources of the container host. 

According to Docker, user namespaces will provide a much lower level of privilege and force a user who breaks out from his assigned container to default to a zero write access and a minimal read access to the host server.  This update solves the container vulnerability long argued by critics.

In another Docker Engine 1.10 security update, Docker allows the operation of Seccomp or "secure computing mode" with a given container and the Linux kernel.  You can use it to restrict the actions available within the container.  You can also use this feature to restrict your application’s access.

According to Docker, "Seccomp filtering allows a process to specify a berkeley packet filter to syscalls."  Seccomp helps make it easier to secure a Docker container or apply a default set of limits on all containers, then augment them only where needed.  

In other words, it allows a user to catch a syscall and "allow", "deny", "trap", "kill", or "trace" it via the syscall number and arguments passed.  By doing so, it provides an extra level of granularity in locking down the processes in the containers to only do what they need.

With the latest release, Docker has also introduced an authorization plugin system for access controls.

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

Another big security enhancement implemented with Docker 1.10 is content addressable image IDs.  Image IDs represent the content that is inside an image, in a similar way to how Git commits represent the content inside commits.  This means you can guarantee that the content you’re running is what you expect by just specifying that image’s ID. 

With it, code can only be added to a container once its content has been checked and verified via an identifier hash tag.  Any alteration with the image alters the tag, so the platform knows it is no longer dealing with verified code.

If security isn’t your thing, don’t worry — there are a host of other features and capabilities added to Docker 1.10.  

When ready, you can Download Docker 1.10 or read the Docker 1.10 release notes