In the first part of this trilogy we focused on Docker 1.10 and its seccomp capabilities. In this post we’ll explore the authorization plug-in architecture, another feature which was released as part of Docker 1.10.
The Docker User Authorization Challenge
Before the release of this version of Docker, users either had full admin privileges or none at all.
This meant that there was no segregation of duties, and no separation of access privileges between different containers running on the same host. It made Docker deployment in production challenging, as you couldn’t limit application owners to access only their application's containers.
In addition, regular users that were members of the “Docker” group could easily elevate their privileges to root access. This was enabled by running a container as a privileged container, and from it getting full access to the host, including loading kernel modules.
Enter the Authorization Plug-In
The new the plug-in which was released as part of Docker 1.10 allows security vendors to add authorization plug-ins to Docker. This makes it easier to control user access to Docker commands and resources. With such plug-ins, you can assign different privileges to different users for each container.
Alice, for example, might be a full admin of the CRM containers, while Bob is an auditor and can only view container logs. The access policy itself is determined by the plug-in authorization engine.
I’m happy to announce that Scalock officially released an authorization plug-in for Docker 1.10, allowing the integration of our extensive access control policy engine into any Docker-based environment. This is in addition to even more fine-grained access control capabilities that are native to the Scalock solution.
The new authorization plug-in architecture is another step forward toward making Docker container environments enterprise-ready, while it retains great flexibility in managing the access control policy.
