Access control design using additional security requirementsEstimated reading time: 4 minutes
This topic applies to Docker Enterprise.
The Docker Enterprise platform business, including products, customers, and employees, has been acquired by Mirantis, inc., effective 13-November-2019. For more information on the acquisition and how it may affect you and your business, refer to the Docker Enterprise Customer FAQ.
Go through the Docker Enterprise tutorial, before completing the following tutorial.
In the first tutorial, the fictional company, OrcaBank, designed an architecture with role-based access control (RBAC) to meet their organization’s security needs. They assigned multiple grants to fine-tune access to resources across collection boundaries on a single platform.
In this tutorial, OrcaBank implements new and more stringent security requirements for production applications:
- First, OrcaBank adds staging zone to their deployment model. They will no longer move developed applications directly in to production. Instead, they will deploy apps from their dev cluster to staging for testing, and then to production.
- Second, production applications are no longer permitted to share any physical infrastructure with non-production infrastructure. OrcaBank segments the scheduling and access of applications with Node Access Control.
Node Access Control is a feature of Docker Enterprise and provides secure multi-tenancy with node-based isolation. Nodes can be placed in different collections so that resources can be scheduled and isolated on disparate physical or virtual hardware resources.
Team access requirements
OrcaBank still has three application teams,
varying levels of segmentation between them.
Their RBAC redesign is going to organize their UCP cluster into two top-level collections, staging and production, which are completely separate security zones on separate physical infrastructure.
OrcaBank’s four teams now have different needs in production and staging:
securityshould have view-only access to all applications in production (but not staging).
dbshould have full access to all database applications and resources in production (but not staging). See DB Team.
mobileshould have full access to their Mobile applications in both production and staging and limited access to shared
dbservices. See Mobile Team.
paymentsshould have full access to their Payments applications in both production and staging and limited access to shared
OrcaBank has decided to replace their custom
Ops role with the built-in
Full Control role.
View Only(default role) allows users to see but not edit all cluster resources.
Full Control(default role) allows users complete control of all collections granted to them. They can also create containers without restriction but cannot see the containers of other users.
View & Use Networks + Secrets(custom role) enables users to view/connect to networks and view/use secrets used by
dbcontainers, but prevents them from seeing or impacting the
In the previous tutorial, OrcaBank created separate collections for each
application team and nested them all under
To meet their new security requirements for production, OrcaBank is redesigning collections in two ways:
- Adding collections for both the production and staging zones, and nesting a set of application collections under each.
- Segmenting nodes. Both the production and staging zones will have dedicated nodes; and in production, each application will be on a dedicated node.
The collection architecture now has the following tree representation:
/ ├── System ├── Shared ├── prod │ ├── mobile │ ├── payments │ └── db │ ├── mobile │ └── payments | └── staging ├── mobile └── payments
OrcaBank must now diversify their grants further to ensure the proper division of access.
mobile application teams will have three grants each--one
for deploying to production, one for deploying to staging, and the same grant to
db networks and secrets.
OrcaBank access architecture
The resulting access architecture, designed with Docker Enterprise, provides physical segmentation between production and staging using node access control.
Applications are scheduled only on UCP worker nodes in the dedicated application
collection. And applications use shared resources across collection boundaries
to access the databases in the
db team is responsible for deploying and managing the full
lifecycle of the databases that are in production. They have the full set of
operations against all database resources.
mobile team is responsible for deploying their full application stack in
staging. In production they deploy their own applications but use the databases
that are provided by the
authorize, authentication, users, teams, groups, sync, UCP, role, access control