Access control design with Docker EE StandardEstimated 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 is designing the access architecture for two application teams that they have, Payments and Mobile.
This tutorial introduces many concepts include collections, grants, centralized LDAP/AD, and also the ability for resources to be shared between different teams and across collections.
Team access requirements
OrcaBank has organized their application teams to specialize more and provide
shared services to other applications. A
db team was created just to manage
the databases that other applications will utilize. Additionally, OrcaBank
recently read a book about DevOps. They have decided that developers should be
able to deploy and manage the lifecycle of their own applications.
securityshould have visibility-only access across all applications in the swarm.
dbshould have the full set of capabilities against all database applications and their respective resources.
paymentsshould have the full set of capabilities to deploy Payments apps and also access some of the shared services provided by the
mobilehas the same rights as the
paymentsteam, with respect to the Mobile applications.
OrcaBank will use a combination of default and custom roles, roles which they
have created specifically for their use case. They are using the default
View Only role to provide security access to only see but not edit resources.
There is an
ops role that they created which can do almost all operations
against all types of resources. They also created the
View & Use Networks + Secrets role. This type of role will enable application
DevOps teams to use shared resources provided by other teams. It will enable
applications to connect to networks and use secrets that will also be used by
db containers, but not the ability to see or impact the
OrcaBank will also create some collections that fit the organizational structure
of the company. Since all applications will share the same physical resources,
all nodes and applications are built in to collections underneath the
/Shared/paymentshosts all applications and resources for the Payments applications.
/Shared/mobilehosts all applications and resources for the Mobile applications.
Some other collections will be created to enable the shared
/Shared/dbwill be a top-level collection for all
/Shared/db/paymentswill be specifically for
dbresources providing service to the Payments applications.
/Shared/db/mobilewill do the same for the Mobile applications.
The following grant composition will show that this collection architecture
allows an app team to access shared
db resources without providing access
db resources. At the same time all
db resources will be managed
by a single
OrcaBank has standardized on LDAP for centralized authentication to help their identity team scale across all the platforms they manage. As a result LDAP groups will be mapped directly to UCP teams using UCP’s native LDAP/AD integration. As a result 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 .
Two grants are applied for each application team, allowing each team to fully
manage their own apps in their collection, but also have limited access against
networks and secrets within the
db collection. This kind of grant composition
provides flexibility to have different roles against different groups of
OrcaBank access architecture
The resulting access architecture shows applications connecting across collection boundaries. Multiple grants per team allow Mobile applications and Databases to connect to the same networks and use the same secrets so they can securely connect with each other but through a secure and controlled interface. Note that these resources are still deployed across the same group of UCP worker nodes. Node segmentation is 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 have the full set of
operations against all database resources.
mobile team is responsible for deploying their own application stack,
minus the database tier which is managed by the