Update rbac diagrams (#214)
* Update rbac diagrams * Add Liquid tags to images
|
@ -13,7 +13,7 @@ to a set of resources (collection). Each grant is a 1:1:1 mapping of
|
|||
subject, role, collection. For example, you can grant the "Prod Team"
|
||||
"Restricted Control" permissions for the "/Production" collection.
|
||||
|
||||

|
||||
{: .with-border}
|
||||
|
||||
The usual workflow for creating grants has four steps.
|
||||
|
||||
|
@ -38,4 +38,8 @@ grants. Administrators create grants on the **Manage Grants** page.
|
|||
|
||||
By default, all new users are placed in the `docker-datacenter` organization.
|
||||
If you want to apply a grant to all UCP users, create a grant with the
|
||||
`docker-datacenter` org as a subject.
|
||||
`docker-datacenter` org as a subject.
|
||||
|
||||
## Where to go next
|
||||
|
||||
- [Isolate volumes between two different teams](isolate-volumes-between-teams.md)
|
|
@ -21,7 +21,7 @@ complete this example.
|
|||
3. Assign a worker node to the `/Prod` collection.
|
||||
4. Grant the `Ops` teams access to its collection.
|
||||
|
||||

|
||||
{: .with-border}
|
||||
|
||||
## Create a team
|
||||
|
||||
|
@ -78,7 +78,7 @@ Move a worker node by changing the value of its access label key,
|
|||
> **Nodes must be in either the shared or system collection without an advanced license.**
|
||||
> [Get a Docker EE Advanced license](https://www.docker.com/pricing).
|
||||
|
||||

|
||||
{: .with-border}
|
||||
|
||||
## Grant access for a team
|
||||
|
||||
|
@ -116,7 +116,7 @@ The same steps apply for the nodes in the `/Prod` collection.
|
|||
7. Click **Create** to grant the Ops team `Scheduler` access to the nodes in the
|
||||
`/Prod` collection.
|
||||
|
||||

|
||||
{: .with-border}
|
||||
|
||||
## Deploy a service as a team member
|
||||
|
||||
|
@ -149,13 +149,13 @@ All resources are deployed under the user's default collection,
|
|||
4. Click the **NGINX** container, and in the details pane, confirm that its
|
||||
**Collection** is **/Prod/Webserver**.
|
||||
|
||||

|
||||
{: .with-border}
|
||||
|
||||
5. Click **Inspect Resource**, and in the dropdown, select **Nodes**.
|
||||
6. Click the node, and in the details pane, confirm that its **Collection**
|
||||
is **/Prod**.
|
||||
|
||||

|
||||
{: .with-border}
|
||||
|
||||
## Alternative: Use a grant instead of the default collection
|
||||
|
||||
|
|
|
@ -14,7 +14,7 @@ nodes.
|
|||
3. Create grants to manage access to the collections.
|
||||
4. Team members create volumes that are specific to their team.
|
||||
|
||||

|
||||
{: .with-border}
|
||||
|
||||
## Create two teams
|
||||
|
||||
|
@ -57,7 +57,7 @@ with the `/Shared/prod-volumes` collection.
|
|||
6. Click **Create Grant** and repeat the previous steps for the **/Shared/prod-volumes**
|
||||
collection and the Prod team.
|
||||
|
||||

|
||||
{: .with-border}
|
||||
|
||||
With the collections and grants in place, users can sign in and create volumes
|
||||
in their assigned collections.
|
||||
|
@ -78,18 +78,18 @@ Team members have permission to create volumes in their assigned collection.
|
|||
to create a "prod-data" volume assigned to the `/Shared/prod-volumes`
|
||||
collection.
|
||||
|
||||

|
||||
{: .with-border}
|
||||
|
||||
Now you can see role-based access control in action for volumes. The user on
|
||||
the Prod team can't see the Dev team's volumes, and if you log in again as a
|
||||
user on the Dev team, you won't see the Prod team's volumes.
|
||||
|
||||

|
||||
{: .with-border}
|
||||
|
||||
Sign in with a UCP administrator account, and you see all of the volumes
|
||||
created by the Dev and Prod users.
|
||||
|
||||

|
||||
{: .with-border}
|
||||
|
||||
## Where to go next
|
||||
|
||||
|
|
|
@ -53,7 +53,12 @@ UCP provides a number of built-in collections.
|
|||
- `/Shared/Legacy` - After updating from UCP 2.1, all legacy access control
|
||||
labels are stored here.
|
||||
|
||||

|
||||
{: .with-border}
|
||||
|
||||
This diagram shows the `/System` and `/Shared` collections that are created
|
||||
by UCP. User private collections are children of the `/Shared/private`
|
||||
collection. Also, an admin user has created a `/prod` collection and its
|
||||
`/webserver` child collection.
|
||||
|
||||
## Default collections
|
||||
|
||||
|
|
|
@ -57,7 +57,7 @@ are listed on the **Create Role** page. For example, you can create a custom
|
|||
role that uses the node operations, `Schedule`, `Update`, and `View`, and you
|
||||
might give it a name like "Node Operator".
|
||||
|
||||

|
||||
{: .with-border}
|
||||
|
||||
You can give a role a global name, like "Remove Images", which might enable
|
||||
the **Remove** and **Force Remove** operations for images. You can apply a
|
||||
|
|
Before Width: | Height: | Size: 23 KiB After Width: | Height: | Size: 31 KiB |
Before Width: | Height: | Size: 30 KiB After Width: | Height: | Size: 40 KiB |
Before Width: | Height: | Size: 39 KiB After Width: | Height: | Size: 52 KiB |
Before Width: | Height: | Size: 39 KiB After Width: | Height: | Size: 46 KiB |
Before Width: | Height: | Size: 32 KiB After Width: | Height: | Size: 105 KiB |