mirror of https://github.com/docker/docs.git
Refactor old and new rbac topics (#97)
* Refactor old and new rbac topics * Add grant topic to toc * Incorporate feedback on new grant topic
This commit is contained in:
Jim Galasyn
parent
b55460ffbc
commit
f30ac260b6
|
|
@ -1646,8 +1646,10 @@ manuals:
|
|||
title: Create and manage teams
|
||||
- path: /datacenter/ucp/2.2/guides/admin/manage-users/deploy-view-only-service/
|
||||
title: Deploy a service with view-only access across an organization
|
||||
- path: /datacenter/ucp/2.2/guides/admin/manage-users/isolate-nodes-between-teams/
|
||||
title: Isolate swarm nodes between two different teams
|
||||
- path: /datacenter/ucp/2.2/guides/admin/manage-users/deploy-view-only-service/
|
||||
title: Deploy a service with view-only access across an organization
|
||||
- path: /datacenter/ucp/2.2/guides/admin/manage-users/grant-permissions/
|
||||
title: Grant permissions to users based on roles
|
||||
- path: /datacenter/ucp/2.2/guides/admin/manage-users/isolate-volumes-between-teams/
|
||||
title: Isolate volumes between two different teams
|
||||
- path: /datacenter/ucp/2.2/guides/admin/manage-users/manage-access-with-collections/
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ log in with the recovery admin password.
|
|||
|
||||
To configure UCP to create and authenticate users using an LDAP directory,
|
||||
go to the **UCP web UI**, navigate to the **Admin Settings** page, and click the
|
||||
**Auth** tab.
|
||||
**Authentication** tab.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
|
|
|
|||
|
|
@ -1,30 +1,34 @@
|
|||
---
|
||||
title: Create and manage teams
|
||||
description: Learn how to create and manage user permissions, using teams in
|
||||
your Docker Universal Control Plane cluster.
|
||||
keywords: authorize, authentication, users, teams, groups, sync, UCP, Docker
|
||||
title: Create and manage teams
|
||||
---
|
||||
|
||||
You can extend the user's default permissions by granting them fine-grain
|
||||
You can extend the user's default permissions by granting them fine-grained
|
||||
permissions over resources. You do this by adding the user to a team.
|
||||
A team defines the permissions users have for resources that have the label
|
||||
`com.docker.ucp.access.label` applied to them. Keep in mind that a label can
|
||||
be applied to multiple teams with different permission levels.
|
||||
|
||||
To create a new team, go to the **UCP web UI**, and navigate to the
|
||||
**Users & Teams** page.
|
||||
**Organizations** page.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
Click the **Create** button to create a new team, and assign it a name.
|
||||
If you want to put the team in a new organization, click
|
||||
**Create Organization** and give the new organization a name, like
|
||||
"engineering". Click **Create** to create it.
|
||||
|
||||
In the list, click the organization where you want to create the new team.
|
||||
Name the team, give it an optional description, and click **Create** to
|
||||
create a new team.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
## Add users to a team
|
||||
|
||||
You can now add and remove users from the team.
|
||||
Navigate to the **Members** tab, and click the **Add User to Team** button.
|
||||
Then choose the list of users that you want to add to the team.
|
||||
You can now add and remove users from the team. In the current organization's
|
||||
teams list, click the new team, and in the right pane, click the vertical
|
||||
dots icon. In the popup menu, click **Add Users**, and choose the users that
|
||||
you want to add to the team.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
|
|
@ -72,26 +76,17 @@ are fully synced.
|
|||
|
||||
## Manage team permissions
|
||||
|
||||
To manage the permissions of the team, click the **Permissions** tab.
|
||||
Here you can specify a list of labels and the permission level users will have
|
||||
for resources with those labels.
|
||||
Create a grant to manage the team's permissions. [Learn how to grant permissions to users based on roles](grant-permissions.md).
|
||||
|
||||
{: .with-border}
|
||||
|
||||
In the example above, members of the 'Operations' team have permissions to
|
||||
create and edit resources that have the labels
|
||||
`com.docker.ucp.access.label=operations` applied, but can only view resources
|
||||
that have the `com.docker.ucp.access.label=blog` label.
|
||||
|
||||
There are four permission levels available:
|
||||
|
||||
| Team permission level | Description |
|
||||
|:----------------------|:--------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| `No Access` | The user can't view resources with this label. |
|
||||
| `View Only` | The user can view but can't create resources with this label. |
|
||||
| `Restricted Control` | The user can view and create resources with this label. The user can't run `docker exec`, or services that require privileged access to the host. |
|
||||
| `Full Control` | The user can view and create resources with this label, without any restriction. |
|
||||
In the example above, members of the "Operations" team have permissions to
|
||||
create and edit resources.
|
||||
|
||||
## Where to go next
|
||||
|
||||
* [UCP permission levels](permission-levels.md)
|
||||
- [UCP permission levels](permission-levels.md)
|
||||
- [Isolate volumes between two different teams](isolate-volumes-between-teams.md)
|
||||
- [Isolate swarm nodes between two different teams](isolate-nodes-between-teams.md)
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,16 +1,18 @@
|
|||
---
|
||||
title: Create and manage users
|
||||
description: Learn how to create and manage users in your Docker Universal Control
|
||||
Plane cluster.
|
||||
keywords: authorize, authentication, users, teams, UCP, Docker
|
||||
title: Create and manage users
|
||||
---
|
||||
|
||||
When using the UCP built-in authentication, you need to create users and
|
||||
assign them a default permission level so that they can access the
|
||||
cluster.
|
||||
optionally grant them UCP administrator permissions.
|
||||
|
||||
Each new user gets a default permission level so that they can access the
|
||||
swarm.
|
||||
|
||||
To create a new user, go to the **UCP web UI**, and navigate to the
|
||||
**Users & Teams** page.
|
||||
**Users** page.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
|
|
@ -22,19 +24,7 @@ Check the `Is a UCP admin` option, if you want to grant permissions for the
|
|||
user to change cluster configurations. Also, assign the user a default
|
||||
permission level.
|
||||
|
||||
Default permissions specify the permission a user has for resources that don't
|
||||
have the `com.docker.access.label` label applied to them. There are four
|
||||
permission levels:
|
||||
|
||||
| Default permission level | Description |
|
||||
|:-------------------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| `No Access` | The user can't view resource, like services, images, networks, and volumes. |
|
||||
| `View Only` | The user can view images and volumes, but can't create services. |
|
||||
| `Restricted Control` | The user can view and edit volumes and networks. They can create services, but can't see other users' services, run `docker exec`, or run containers that require privileged access to the host. |
|
||||
| `Full Control` | The user can view and edit volumes and networks. They can create containers without any restriction, but can't see other users' containers. |
|
||||
|
||||
[Learn more about the UCP permission levels](permission-levels.md). Finally,
|
||||
click the **Create User** button, to create the user.
|
||||
Finally, click the **Create** button to create the user.
|
||||
|
||||
## Where to go next
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,37 @@
|
|||
---
|
||||
title: Grant permissions to users based on roles
|
||||
description: Grant access to swarm resources by using role-based access control.
|
||||
keywords: ucp, grant, role, permission, authentication, authorization
|
||||
---
|
||||
|
||||
If you're a UCP administrator, you can create *grants* to control how users
|
||||
and organizations access swarm resources.
|
||||
|
||||
A grant is made up of a *subject*, a *role*, and a *resource collection*.
|
||||
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
|
||||
subject, role, collection. For example, you can grant the "Prod Team"
|
||||
"View Only" permissions for the "/Production" collection.
|
||||
|
||||
The usual workflow for creating grants has four steps.
|
||||
|
||||
1. Set up your users and teams. For example, you might want three teams,
|
||||
Dev, QA, and Prod.
|
||||
2. Organize swarm resources into separate collections that each team uses.
|
||||
3. Optionally, create custom roles for specific permissions to the Docker API.
|
||||
4. Grant role-based access to collections for your teams.
|
||||
|
||||
## Create a grant
|
||||
|
||||
When you have your users, collections, and roles set up, you can create
|
||||
grants. Administrators create grants on the **Manage Grants** page.
|
||||
|
||||
1. Click **Create Grant**. The default collection, usually `/Swarm` is listed.
|
||||
2. Click **Selected** to list all of the collections.
|
||||
3. Click **Select** on the collection you want to grant access to.
|
||||
4. In the left pane, click **Roles** and select a role from the dropdown list.
|
||||
5. In the left pane, click **Subjects**. Click **All Users** to create a grant
|
||||
for a specific user, or click **Organizations** to create a grant for an
|
||||
organization or a team.
|
||||
6. Select a user, team, or organization and click **Create**.
|
||||
|
||||
|
|
@ -16,22 +16,13 @@ and organizations access swarm resources.
|
|||
|
||||
A grant is made up of a *subject*, a *role*, and a *resource collection*.
|
||||
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
|
||||
subject, role, collection. For example, you can create a grant that
|
||||
specifies that the "Prod Team" gains "View Only" permission against
|
||||
resources in the "/Production" collection.
|
||||
|
||||
The usual workflow for creating grants has three steps.
|
||||
|
||||
1. Set up your users and teams. For example, you might want three teams,
|
||||
Dev, QA, and Prod.
|
||||
2. Organize swarm resources into separate collections that each team will use.
|
||||
3. Grant access against resource collections for your teams.
|
||||
to a set of resources (collection).
|
||||
[Learn how to grant permissions to users based on roles](grant-permissions.md).
|
||||
|
||||
## Subjects
|
||||
|
||||
A subject represents a user, team, or organization. A subject is granted a role
|
||||
for a collection of resources.
|
||||
A subject represents a user, team, or organization. A subject is granted a
|
||||
role for a collection of resources.
|
||||
|
||||
- **User**: A person that the authentication backend validates. You can
|
||||
assign users to one or more teams and one or more organizations.
|
||||
|
|
@ -51,50 +42,16 @@ for a collection of resources.
|
|||
|
||||
A role is a set of permitted API operations that you can assign to a specific
|
||||
subject and collection by using a grant. UCP administrators view and manage
|
||||
roles by navigating to the **User Management > Roles** page.
|
||||
|
||||
The system provides the following default roles:
|
||||
|
||||
| Built-in role | Description |
|
||||
|----------------------|-------------|
|
||||
| `View Only` | The user can view resources like services, volumes, and networks but can't create them. |
|
||||
| `Restricted Control` | The user can view and edit volumes, networks, and images but can't run a service or container in a way that might affect the node where it's running. The user can't mount a node directory and can't `exec` into containers. Also, The user can't run containers in privileged mode or with additional kernel capabilities. |
|
||||
| `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. |
|
||||
| `Scheduler` | The user can schedule and view workloads on worker nodes. By default, all users get a grant with the `Scheduler` role against the `/Shared` collection. |
|
||||
| `Admin` | The user has full access to all resources, like volumes, networks, images, and containers. |
|
||||
|
||||
Administrators can create a custom role that has Docker API permissions
|
||||
that specify the API actions that a subject may perform.
|
||||
|
||||
The **Roles** page lists the available roles, including the default roles
|
||||
and any custom roles that administrators have created. In the **Roles**
|
||||
list, click a role to see the API operations that it uses. For example, the
|
||||
`Scheduler` role has two of the node operations, `Schedule` and `View`.
|
||||
|
||||
Click **Create role** to create a custom role and define the API operations
|
||||
that it uses. When you create a custom role, all of the APIs that you can use
|
||||
are listed on the **Create Role** page. For example, you can create a custom
|
||||
role that uses all of the node operations, `Join Token`, `Schedule`,
|
||||
`Update`, and `View`, and you might name it "Node Operator".
|
||||
|
||||
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
|
||||
role with the same name to different resource collections.
|
||||
|
||||
Only an administrator can create and remove roles. An administrator
|
||||
can enable and disable roles in the system. Roles can't be edited, so
|
||||
to change a role's API operations, you must delete it and recreate it.
|
||||
|
||||
You can't delete a custom role if it's used in a grant. You must first delete
|
||||
the grants that use the role.
|
||||
roles by navigating to the **Roles** page.
|
||||
[Learn more about roles and permissions](permission-levels.md).
|
||||
|
||||
## Resource collections
|
||||
|
||||
Docker EE enables controlling access to container resources by using
|
||||
*collections*. A collection is a grouping of container resources, like
|
||||
Docker EE enables controlling access to swarm resources by using
|
||||
*collections*. A collection is a grouping of swarm resources, like
|
||||
volumes, networks, secrets, and services, that you access by specifying
|
||||
a directory-like path. For more info, see
|
||||
[Manage access to resources by using collections](manage-access-with-collections.md).
|
||||
a directory-like path.
|
||||
[Learn to manage access to resources by using collections](manage-access-with-collections.md).
|
||||
|
||||
## Transition from UCP 2.1 access control
|
||||
|
||||
|
|
@ -108,6 +65,8 @@ a directory-like path. For more info, see
|
|||
|
||||
## Where to go next
|
||||
|
||||
- [Create and manage users](create-and-manage-users.md)
|
||||
- [Create and manage teams](create-and-manage-teams.md)
|
||||
- [Deploy a service with view-only access across an organization](deploy-view-only-service.md)
|
||||
- [Isolate volumes between two different teams](isolate-volumes-between-teams.md)
|
||||
- [Isolate swarm nodes between two different teams](isolate-nodes-between-teams.md)
|
||||
|
|
|
|||
|
|
@ -112,8 +112,4 @@ on one of the nodes under `/Shared`.
|
|||
If you want to isolate nodes against other teams, place these nodes in
|
||||
new collections, and assign the `Scheduler` role, which contains the
|
||||
`Node Schedule` permission, to the two teams. For more info, see
|
||||
[Isolate swarm nodes between two different teams](isolate-nodes-between-teams.md).
|
||||
|
||||
|
||||
|
||||
|
||||
[Isolate swarm nodes between two different teams](isolate-nodes-between-teams.md).
|
||||
|
|
@ -2,52 +2,68 @@
|
|||
description: Learn about the permission levels available in Docker Universal
|
||||
Control Plane.
|
||||
keywords: authorization, authentication, users, teams, UCP
|
||||
title: Permission levels
|
||||
title: Roles and permission levels
|
||||
---
|
||||
|
||||
Docker Universal Control Plane has two types of users: administrators and
|
||||
regular users. Administrators can make changes to the UCP cluster, while
|
||||
regular users. Administrators can make changes to the UCP swarm, while
|
||||
regular users have permissions that range from no access to full control over
|
||||
volumes, networks, images, and containers.
|
||||
resources like volumes, networks, images, and containers. Users are
|
||||
grouped into teams and organizations.
|
||||
|
||||
Administrators create *grants* to users, teams, and organizations to give
|
||||
permissions to swarm resources.
|
||||
|
||||
## Administrator users
|
||||
|
||||
In Docker UCP, only users with administrator privileges can make changes to
|
||||
cluster settings. This includes:
|
||||
swarm settings. This includes:
|
||||
|
||||
* Managing user and team permissions,
|
||||
* Managing cluster configurations like adding and removing nodes to the cluster.
|
||||
* Managing user permissions by creating grants.
|
||||
* Managing swarm configurations, like adding and removing nodes.
|
||||
|
||||
## Default permission levels
|
||||
## Roles
|
||||
|
||||
Regular users can't change cluster settings, and they are assigned with a
|
||||
default permission level.
|
||||
A role is a set of permitted API operations on a collection that you
|
||||
can assign to a specific user, team, or organization by using a grant.
|
||||
|
||||
The default permission level specify the permission a user has to access or
|
||||
edit resources. You can choose from four permission levels that range from no
|
||||
access to full control over the resources.
|
||||
UCP administrators view and manage roles by navigating to the **Roles** page.
|
||||
|
||||
| Default permission level | Description |
|
||||
|:-------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| `No Access` | The user can't view any resource, like volumes, networks, images, or containers. |
|
||||
| `View Only` | The user can view volumes, networks, and images, but can't create any containers. |
|
||||
| `Restricted Control` | The user can view and edit volumes, networks, and images. They can create containers, but can't see other users' containers, run `docker exec`, or run containers that require privileged access to the host. |
|
||||
| `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. |
|
||||
The system provides the following default roles:
|
||||
|
||||
If a user has Restricted Control or Full Control default permissions, they can create resources without labels, and only the user and Admins can see and access the resources. Default permissions also affect ability for a user to access things that can't have labels, images and nodes.
|
||||
| Built-in role | Description |
|
||||
|----------------------|-------------|
|
||||
| `View Only` | The user can view resources like services, volumes, and networks but can't create them. |
|
||||
| `Restricted Control` | The user can view and edit volumes, networks, and images but can't run a service or container in a way that might affect the node where it's running. The user can't mount a node directory and can't `exec` into containers. Also, The user can't run containers in privileged mode or with additional kernel capabilities. |
|
||||
| `Scheduler` | The user can schedule and view workloads on worker nodes. 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. |
|
||||
|
||||
## Team permission levels
|
||||
|
||||
|
||||
Teams and labels give the administrator fine-grained control over permissions. Each team can have multiple labels. Each label has a key of `com.docker.ucp.access.label`. The label is then applied to the containers, services, networks, secrets, and volumes. Labels are not currently available for nodes and images. DTR has its own permissions.
|
||||
Administrators can create a custom role that has Docker API permissions
|
||||
that specify the API actions that a subject may perform.
|
||||
|
||||
There are four permission levels:
|
||||
The **Roles** page lists the available roles, including the default roles
|
||||
and any custom roles that administrators have created. In the **Roles**
|
||||
list, click a role to see the API operations that it uses. For example, the
|
||||
`Scheduler` role has two of the node operations, `Schedule` and `View`.
|
||||
|
||||
| Team permission level | Description |
|
||||
|:----------------------|:-----------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| `No Access` | The user can't view containers with this label. |
|
||||
| `View Only` | The user can view but can't create containers with this label. |
|
||||
| `Restricted Control` | The user can view and create containers with this label. The user can't run `docker exec`, or containers that require privileged access to the host. |
|
||||
| `Full Control` | The user can view and create containers with this label, without any restriction. |
|
||||
Click **Create role** to create a custom role and define the API operations
|
||||
that it uses. When you create a custom role, all of the APIs that you can use
|
||||
are listed on the **Create Role** page. For example, you can create a custom
|
||||
role that uses all of the node operations, `Join Token`, `Schedule`,
|
||||
`Update`, and `View`, and you might give it a name like "Node Operator".
|
||||
|
||||
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
|
||||
role with the same name to different collections.
|
||||
|
||||
Only an administrator can create and remove roles. An administrator
|
||||
can enable and disable roles in the system. Roles can't be edited, so
|
||||
to change a role's API operations, you must delete it and recreate it.
|
||||
|
||||
You can't delete a custom role if it's used in a grant. You must first delete
|
||||
the grants that use the role.
|
||||
|
||||
## Where to go next
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 251 KiB After Width: | Height: | Size: 53 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 253 KiB After Width: | Height: | Size: 27 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 261 KiB After Width: | Height: | Size: 77 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 36 KiB After Width: | Height: | Size: 65 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 241 KiB After Width: | Height: | Size: 66 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 205 KiB After Width: | Height: | Size: 29 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 24 KiB |
Loading…
Reference in New Issue