Add cool rbac graphics (#4289)
|
@ -7,14 +7,14 @@ keywords: ucp, grant, role, permission, authentication, authorization
|
||||||
If you're a UCP administrator, you can create *grants* to control how users
|
If you're a UCP administrator, you can create *grants* to control how users
|
||||||
and organizations access swarm resources.
|
and organizations access swarm resources.
|
||||||
|
|
||||||
|
{: .with-border}
|
||||||
|
|
||||||
A grant is made up of a *subject*, a *role*, and a *resource collection*.
|
A grant is made up of a *subject*, a *role*, and a *resource collection*.
|
||||||
A grant defines who (subject) has how much access (role)
|
A grant defines who (subject) has how much access (role)
|
||||||
to a set of resources (collection). Each grant is a 1:1:1 mapping of
|
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"
|
subject, role, collection. For example, you can grant the "Prod Team"
|
||||||
"Restricted Control" permissions for the "/Production" collection.
|
"Restricted Control" permissions for the "/Production" collection.
|
||||||
|
|
||||||
{: .with-border}
|
|
||||||
|
|
||||||
The usual workflow for creating grants has four steps.
|
The usual workflow for creating grants has four steps.
|
||||||
|
|
||||||
1. Set up your users and teams. For example, you might want three teams,
|
1. Set up your users and teams. For example, you might want three teams,
|
||||||
|
@ -23,6 +23,8 @@ The usual workflow for creating grants has four steps.
|
||||||
3. Optionally, create custom roles for specific permissions to the Docker API.
|
3. Optionally, create custom roles for specific permissions to the Docker API.
|
||||||
4. Grant role-based access to collections for your teams.
|
4. Grant role-based access to collections for your teams.
|
||||||
|
|
||||||
|
{: .with-border}
|
||||||
|
|
||||||
## Create a grant
|
## Create a grant
|
||||||
|
|
||||||
When you have your users, collections, and roles set up, you can create
|
When you have your users, collections, and roles set up, you can create
|
||||||
|
|
|
@ -19,7 +19,7 @@ A grant defines who (subject) has how much access (role)
|
||||||
to a set of resources (collection).
|
to a set of resources (collection).
|
||||||
[Learn how to grant permissions to users based on roles](grant-permissions.md).
|
[Learn how to grant permissions to users based on roles](grant-permissions.md).
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
An administrator is a user who can manage grants, subjects, roles, and
|
An administrator is a user who can manage grants, subjects, roles, and
|
||||||
collections. An administrator identifies which operations can be performed
|
collections. An administrator identifies which operations can be performed
|
||||||
|
|
|
@ -8,6 +8,8 @@ Docker EE enables controlling access to container resources by using
|
||||||
*collections*. A collection is a group of swarm resources,
|
*collections*. A collection is a group of swarm resources,
|
||||||
like services, containers, volumes, networks, and secrets.
|
like services, containers, volumes, networks, and secrets.
|
||||||
|
|
||||||
|
{: .with-border}
|
||||||
|
|
||||||
Access to collections goes through a directory structure that arranges a
|
Access to collections goes through a directory structure that arranges a
|
||||||
swarm's resources. To assign permissions, administrators create grants
|
swarm's resources. To assign permissions, administrators create grants
|
||||||
against directory branches.
|
against directory branches.
|
||||||
|
|
|
@ -11,6 +11,8 @@ regular users have permissions that range from no access to full control over
|
||||||
resources like volumes, networks, images, and containers. Users are
|
resources like volumes, networks, images, and containers. Users are
|
||||||
grouped into teams and organizations.
|
grouped into teams and organizations.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
Administrators create *grants* to users, teams, and organizations to give
|
Administrators create *grants* to users, teams, and organizations to give
|
||||||
permissions to swarm resources.
|
permissions to swarm resources.
|
||||||
|
|
||||||
|
@ -39,7 +41,7 @@ The system provides the following default roles:
|
||||||
| `Scheduler` | The user can view nodes and schedule workloads on them. Worker nodes and manager nodes are affected by `Scheduler` grants. Having `Scheduler` access doesn't allow the user to view workloads on these nodes. They need the appropriate resource permissions, like `Container View`. By default, all users get a grant with the `Scheduler` role against the `/Shared` collection. |
|
| `Scheduler` | The user can view nodes and schedule workloads on them. Worker nodes and manager nodes are affected by `Scheduler` grants. Having `Scheduler` access doesn't allow the user to view workloads on these nodes. They need the appropriate resource permissions, like `Container View`. By default, all users get a grant with the `Scheduler` role against the `/Shared` collection. |
|
||||||
| `Full Control` | The user can view and edit volumes, networks, and images, They can create containers without any restriction, but can't see other users' containers. |
|
| `Full Control` | The user can view and edit volumes, networks, and images, They can create containers without any restriction, but can't see other users' containers. |
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
Administrators can create a custom role that has Docker API permissions
|
Administrators can create a custom role that has Docker API permissions
|
||||||
that specify the API actions that a subject may perform.
|
that specify the API actions that a subject may perform.
|
||||||
|
|
After Width: | Height: | Size: 24 KiB |
Before Width: | Height: | Size: 39 KiB After Width: | Height: | Size: 53 KiB |
After Width: | Height: | Size: 44 KiB |
After Width: | Height: | Size: 25 KiB |
After Width: | Height: | Size: 44 KiB |
After Width: | Height: | Size: 12 KiB |
After Width: | Height: | Size: 70 KiB |