Access control designEstimated reading time: 4 minutes
Collections and grants are strong tools that can be used to control access and visibility to resources in UCP.
This tutorial describes a fictitious company named OrcaBank that needs to configure an architecture in UCP with role-based access control (RBAC) for their application engineering group.
Team access requirements
OrcaBank reorganized their application teams by product with each team providing shared services as necessary. Developers at OrcaBank do their own DevOps and deploy and manage the lifecycle of their applications.
OrcaBank has four teams with the following resource needs:
securityshould have view-only access to all applications in the cluster.
dbshould have full access to all database applications and resources. See DB Team.
mobileshould have full access to their mobile applications and limited access to shared
dbservices. See Mobile Team.
paymentsshould have full access to their payments applications and limited access to shared
To assign the proper access, OrcaBank is employing a combination of default and custom roles:
View Only(default role) allows users to see all resources (but not edit or use).
Ops(custom role) allows users to perform all operations against configs, containers, images, networks, nodes, secrets, services, and volumes.
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
OrcaBank is also creating collections of resources to mirror their team structure.
Currently, all OrcaBank applications share the same physical resources, so all
nodes and applications are being configured in collections that nest under the
Other collections are also being created to enable shared
/Shared/mobilehosts all Mobile applications and resources.
/Shared/paymentshosts all Payments applications and resources.
/Shared/dbis a top-level collection for all
/Shared/db/paymentsis a collection of
dbresources for Payments applications.
/Shared/db/mobileis a collection of
dbresources for Mobile applications.
The collection architecture has the following tree representation:
/ ├── System └── Shared ├── mobile ├── payments └── db ├── mobile └── payments
OrcaBank’s Grant composition ensures that their collection
architecture gives the
db team access to all
db resources and restricts
app teams to shared
OrcaBank has standardized on LDAP for centralized authentication to help their identity team scale across all the platforms they manage.
To implement LDAP authentication in UCP, OrcaBank is using UCP’s native LDAP/AD integration to map LDAP groups directly to UCP teams. Users can be added to or removed from UCP teams via LDAP which can be managed centrally by OrcaBank’s identity team.
The following grant composition shows how LDAP groups are mapped to UCP teams.
OrcaBank is taking advantage of the flexibility in UCP’s grant model by applying
two grants to each application team. One grant allows each team to fully
manage the apps in their own collection, and the second grant gives them the
(limited) access they need to networks and secrets within the
OrcaBank access architecture
OrcaBank’s resulting access architecture shows applications connecting across collection boundaries. By assigning multiple grants per team, the Mobile and Payments applications teams can connect to dedicated Database resources through a secure and controlled interface, leveraging Database networks and secrets.
In Docker Enterprise, all resources are deployed across the same group of UCP worker nodes. Node segmentation is provided in Docker Enterprise and discussed in the next tutorial.
db team is responsible for deploying and managing the full lifecycle
of the databases used by the application teams. They can execute the full set of
operations against all database resources.
mobile team is responsible for deploying their own application stack,
minus the database tier that is managed by the