Docker Engine 1.10 Puts Emphasis On Container SecurityDocker Engine 1.10 Puts Emphasis On Container Security

8 DevOps Lessons IT Can Teach The Enterprise

Docker has added key security features in the latest release of its container building system, Docker Engine 1.10. It has also enhanced other components of its container management platform, including Docker Compose 1.6 and its clustering software, Docker Swarm 1.1.

Among other things, the user name spaces launched in the experimental channel for Docker Engine 1.9 are now part of the stable, production-ready release of 1.10.

That means a user can be given privileges at a lower level than "root." Root privileges put the user on the same level as a system administrator and open all the resources of the container host to him. User name spaces allow a much lower level of privilege and force a user who moves outside the container to default to zero or minimal read privileges on the server.

It's been a leading request from the Docker community to separate everyday container operation from root privileges on the server host, noted Docker's Scott Johnston, senior vice president of product management. In June, Docker announced that it was countering the root privilege access problem with containers.

The user name spaces became available with the Thursday, Feb. 4, release of Docker Engine 1.10 and mark the first time user privileges can be separated from host privileges, a long-known container vulnerability.

With Docker Engine 1.10, it will be possible to assign each container a level of group privilege that's appropriate to it. For many container users, that will mean a much lower level of privilege than root.

"If a user does a breakout (from his assigned container), he will default to zero write access and limited read access" to the host, Johnston noted. That would amount to a common policy setting on a user's name space.

The capability is made possible because Docker in 1.10 has separated the Docker daemon or background process running the workings of the container from the container user.

Focus on Security

In another Docker Engine security feature, the 1.10 release allows the operation of Seccomp or secure computing mode with a given container and the Linux kernel. Instead of being able to make any system call to the kernel, it is given a defined set of calls appropriate to it, and the operating system will block any that don't meet the profile. Seccomp "helps make it easier to secure a Docker container," said Johnston, or apply a default set of limits on all containers, then augment them only where needed.

Syscalls can include such things as directing the operating system to activate an account, access a disk, or reboot a system. Limiting what calls an application can make is already a standard feature of secure Linux systems. Now operations managers familiar with Seccomp will be able to make them part of container operations as well, Johnston noted.

Another important element of the Docker Platform is Docker Compose, the schematic where a developer defines a container's final properties for deployment. The 1.6 release of Compose, also out Feb. 4, includes the ability to assign a container a given amount of networking capacity and storage volumes without the developer needing to know how those connections will be made or which networks or storage systems will be used.

Previously, a developer could hand off his Docker container to operations and explain the networking and storage that he envisioned for it, but it was a verbal process that risked something being lost in translation.

"Networks and volumes weren't first class citizens in the (container-building) hierarchy," said Johnston.

Now the application can be defined in a single file that's handed off to operations and deployed with a single command, if operations chooses. The networking and storage are listed in the file hierarchy and can also be specifically provisioned by the operations staff to the resources they deem most suited.

"It makes it lower friction to migrate from development into operations," said Johnston. There's more information is available in a blog addressing Compose on the Docker website.

The container clustering software, Docker Swarm 1.1, became available with the 1.10 release of Docker Engine. It's been enhanced to allow the automated rescheduling of containers when they are on a server that fails. The feature is available in the experimental release of Swarm 1.1, which is now out in parallel with the production 1.1 release, but is updated frequently and not regarded as always being as stable. By automatically restarting a container on a healthy node, a Swarm can insure that a Dockerized application appears to run continuously to end-users.

Additional Updates

In addition to the automated restart on a healthy node, the Swarm cluster may now continually add new nodes, even when some are failing. The Swarm management software detects when a new nodes is available, can incorporate it into the cluster, and will assign it its share of the container workload. Status updates and error messages are provided operators upon the addition of a node.

[Want to learn more about Docker security features? Read Docker Tightens Security Over Container Vulnerabilities.]

Docker 1.10 also implements content addressable image IDs, where the system's call for a piece of open source code from a known source is added to a container only after its content has been checked through an identifier hash tag. Any tampering with the image alters the tag, and the platform knows it may not be dealing with the verified code that it thought it was.

The Docker daemon in the 1.10 system has an embedded DNS server as well, a boon to containers running in a user-defined network. They can consult the DNS server to discover services available and resolve the service name with its TCP/IP address.

Are you an IT Hero? Do you know someone who is? Submit your entry now for information's IT Hero Award. Full details and a submission form can be found here.