Docker 1.10, the latest version of the software containerization system, addresses one of its most long-standing criticisms.
Until now, containers have had to run as root under the Docker daemon, with various hair-raising (in)security implications. The solution in Docker 1.10 is a feature called user namespacing. Originally introduced as an experimental feature in version 1.9, it’s now generally available in version 1.10 along with a bundle of other improvements.
A safe space for your name
With user namespaces, privileges for the Docker daemon and container are handled separately, so each container can receive its own user-level privileges. Containers do not need root access on the host, although the Docker daemon still does.
However, Nathan McCauley, director of security at Docker, clarified in an email that user namespaces are currently available only for Linux. “Windows has its own isolation features that we’ll integrate with Docker,” he wrote. “On every platform we’ll aim to support every isolation feature.”
Docker has further expanded on user namespaces by providing a plug-in mechanism for authorization, so admins can configure how Docker deals with user access policies within their organization. Syscalls passed from containers can also be permitted, denied, or traced based on policy settings.
That the Docker runtime runs as root, and the security implicationsa> stemming from that, have long been chief criticisms of Docker. CoreOS was among the most vocal critics, and used the 1.0 release of its rkt container runtime to show how it is possible to run containers without root access. (Rkt can run existing Docker containers as-is.)
Docker has long been aware that having users in containers potentially run as root is problematic, but it took them several point revisions of Docker to mitigate that by way of namespace support and make it stable. CoreOS’s rkt currently hasexperimental support for such a feature.
Re-weaving the net
Docker 1.10 adds major improvements in two other areas. Docker Compose, the native Docker tool for creating multicontainer applications, has a new definition format that now includes ways to describe networks between containers, as supported by Docker’s networking subsystem. This means the work needed to describe a multicontainer application is spread across fewer places.
Networking has also been bolstered. The Docker daemon now includes its own DNS client, which is a way to allow container networks to automatically perform service discovery without the /etc/hosts hackery that was previously required. DNS queries can also be forwarded to an external server if needed.
This goes hand-in-hand with a new internal networking feature that lets containers have network traffic restricted to only their own private subnet by specifying a command-line flag.
Networking has been another long-standing Docker issue and was eventually solved by acquiring and integrating a third-party solution. The latest changes to Docker networking are being touted as a way to take the network topology created for a Dockerized application in development and deploy it in production without changes — addressing another persistent criticism stemming from the limits of Docker’s legacy networking model.
[Source:- Javaworld]
