Sharing is Caring: Docker Enterprise Edition Access Control

Mark Church

Nov 21 2017

Multi-tenancy has many benefits in organizations. Clearly it increases hardware utilization but it also allows IT roles to specialize more, and provides better separation of concerns. This leads to more manageable infrastructure. Multi-tenancy is a challenging practice though, as it requires strict security control over resources without becoming too cumbersome for application deployment.

This blog post is about the Role-based Access Control (RBAC) enhancements introduced in Docker Enterprise Edition (Docker EE) 17.06. These enhancements allow for much more granular control and also flexible policy modeling that is one giant building block of a multitenant container infrastructure. This post will help you  address questions like:

  • How do I prevent different teams from viewing or interacting with each other’s applications when using shared infrastructure?
  • How can I enforce scheduling on certain nodes in the cluster?
  • How can I manage all the access policies so it’s clearly understandable who has access to what?

Docker EE Access Control is a policy-based model that uses access control lists called grants to dictate access between users and cluster resources. A grant is a rule that ties together who, can do which actions, against what resource.

As shown below, a grant is made up of a subject (who), role (which actions), and a collection (what resources):

RBAC Docker EE

Let’s dive into the objects that are used by grants to implement access control.


Roles in Docker EE 17.06 are incredibly granular. They map directly to the Docker API, allowing custom roles to be created that are composed of specific API calls such as `docker exec` or `docker network create`. Any of these individual capabilities can be added together to create custom roles that match the types of roles in your organization.

Here are examples of types of roles that we could create:

  • A “Dev” role that allows developers to view, inspec and get logs from their containers but nothing else
  • A “Network Ops” role that allows a network administrator to create, update and delete Docker Networks
  • An “Ops” role that can deploy applications on behalf of developers


A collection is a grouping of resources in a Docker EE cluster. These resources could be containers, services, networks, secrets, nodes, or any 1st class object in the Universal Control Plane (UCP). Collections allow us to identify a group of objects and apply the same level of permissions to them.

In this example a `/production` collection has a `/mobile` and `/payments` collections as children.

What makes collections very powerful is that they are hierarchical. There are many ways that you may want to segment your cluster: by environment (staging/production), by team (appA, appB), or by security zone (backend, frontend) for example. Any segmentation that your organization has can be represented through a hierarchy of collections.

In this example a `/production` collection has a `/mobile` and `/payments` collections as children. Collections can have many tiers to map to organizational boundaries.


Subjects are the “who” component of a grant. Subjects can be an individual user, a team of users, or an organization (a group of teams). This allows us to write policy rules for different sizes of users in a scalable way.

Node Access Control

A common use case in shared infrastructure is the capability to segment across physical boundaries, such as hosts themselves. Node access control is a feature of Docker EE that allows the scheduling of workloads to be enforced to specific nodes. This means that a certain team can have a dedicated set of nodes where their workloads will only be scheduled. When multi-tenant scenarios call for physical separation, this can easily be done using this feature.

Putting it All Together

Let’s use a hypothetical company called OrcaBank. OrcaBank has two application teams, Mobile and Payments, and an Ops team to manage the applications.

Their requirements are simple:

  • Separate applications will use different nodes from the same cluster
  • Developers should be able to get read access to only their own applications
  • Ops team should deploy applications on behalf of the developers

Docker Enterprise Edition

Using a simple set of three grants, we can give special rights to each team. Ops can deploy any kind of resource to the /production collection or its children. The Payments team can only view resources within the /production/payments collection while the Mobile team can do the same for the /production/mobile collection.

Docker Enterprise Edition

Docker EE Access Control is very powerful, but at the same time very clear in how it shows who has access to which resources. This makes it easier for security operations to audit and understand the access policies..

There are many other resources and design guides to help you understand how these Access Control policies could apply to your organization:

Be the first to write a comment.

Leave a Reply