Role-Based Access Control (RBAC) in UCP is covered in the documentation here: https://docs.docker.com/datacenter/ucp/2.1/guides/
This guide expands on the concepts discussed in the documentation. It is an example of how a team of engineers might use this for their projects, and how each concept relates to their usecase.
There are two developer groups and one devops group. Each of these people might want to deploy various applications they are working on. There are two example "projects." One is called "project alpha," the other is called "project beta." In production, the beta project has some sensitive information that should not be accessed by the developers. Instead, only the head of the devops group should be allowed to access that environment.
First, each person needs a user account in UCP. All accounts are created with a default access of "no access."
Users are then organized into teams. There are two development teams. Leonard is on both teams. Technically, there is only one devops team, but only Gertrude is authorized to handle containers that have sensitive data. Because of this, creating a new team with just Gertrude in it allows Gertrude to have a different level of access.
- Dev Alpha
- Dev Beta
- DevOps (sensitive)
Here's a screenshot showing how the Dev Team Alpha looks inside the user interface:
Each deployed unit of services gets a label. That label is unique across the entire UCP installation. There is a dev, staging, and production deploy for each project: alpha and beta. The beta project handles sensitive data.
This image illustrates what each permission is:
Here is how each of these permissions will map into each of these environments for each of these teams. For example, the dev team for the alpha project should have access to the alpha-dev environment and be able to do deploys. There is not anyone with "full control" permissions here because there is not anyone that needs access to the kernel, and they do not need to be able to run privileged containers. The members of the "DevOps (sensitive)" team are all also on the DevOps team, so it is only necessary to add the one permission difference that is needed. If a person is on multiple teams, the highest permission that is granted for a given resource label is applied.
|Team \ Environment||alpha-dev||alpha-staging||alpha-production||beta-dev||beta-staging||beta-production|
|Dev Team Alpha||Restricted Control||View||View||-||-||-|
|Dev Team Beta||-||-||-||Restricted Control||View||-|
|DevOps||View||Restricted Control||Restricted Control||View||Restricted Control||View|
|DevOps (sensitive)||-||-||-||-||-||Restricted Control|
Now, if anyone tries to access a resource that they have only "view" permissions to, they will get an "access denied" error message. If they don't have any permissions for a resource at all, the resource will not even show up. It will be like it does not exist.
If any of these users want to deploy a resource, they must select a label for that new resource, or they will get an error because they did not specify a label. Any pre-existing resources must have a label applied to them describing who has access.
--- version: '3.1' services: demodocker: image: nginx:alpine environment: - DOMAIN=test.ucp.local ports: - 80 - 443 networks: - frontend volumes: - static_content:/var/www/html:ro deploy: mode: replicated replicas: 1 resources: limits: memory: 1G labels: - com.docker.ucp.access.label=alpha-dev networks: frontend: labels: com.docker.ucp.access.label=alpha-dev volumes: static_content: labels: com.docker.ucp.access.label=alpha-dev