mirror of https://github.com/docker/docs.git
Upgrade rbac docs (#299)
This commit is contained in:
Gwendolynne Barr
Jim Galasyn
parent
ced3bcbcd5
commit
a89b3919ee
|
|
@ -310,42 +310,44 @@ guides:
|
|||
title: Use the ZFS storage driver
|
||||
- path: /storage/storagedriver/vfs-driver/
|
||||
title: Use the VFS storage driver
|
||||
|
||||
- sectiontitle: Authorize user access
|
||||
section:
|
||||
- path: /deploy/access-control/
|
||||
title: Access control model overview
|
||||
- sectiontitle: User Management
|
||||
section:
|
||||
- path: /deploy/access-control/usermgmt-create-subjects.md
|
||||
- path: /deploy/access-control/usermgmt-create-subjects/
|
||||
title: Create and users and teams
|
||||
- path: /deploy/access-control/usermgmt-sync-with-ldap.md
|
||||
- path: /deploy/access-control/usermgmt-sync-with-ldap/
|
||||
title: Synchronize teams with LDAP
|
||||
- path: /deploy/access-control/usermgmt-create-roles.md
|
||||
- path: /deploy/access-control/usermgmt-define-roles/
|
||||
title: Create roles to authorize access
|
||||
- path: /deploy/access-control/usermgmt-grant-permissions.md
|
||||
- path: /deploy/access-control/usermgmt-grant-permissions/
|
||||
title: Grant access to resources
|
||||
- path: /deploy/access-control/usermgmt-recover-user-password
|
||||
- path: /deploy/access-control/usermgmt-recover-user-password/
|
||||
title: Reset a user password
|
||||
- sectiontitle: Shared Resources
|
||||
section:
|
||||
- path: /deploy/access-control/resources-create-collections-namespaces.md
|
||||
- path: /deploy/access-control/resources-group-resources/
|
||||
title: Group resources as collections or namespaces
|
||||
- path: /deploy/access-control/access-control-node.md
|
||||
- path: /deploy/access-control/access-control-node/
|
||||
title: Learn node access controls
|
||||
- path: /deploy/access-control/isolate-nodes-between-teams
|
||||
- path: /deploy/access-control/isolate-nodes-between-teams/
|
||||
title: Isolate Swarm nodes
|
||||
- path: /deploy/access-control/isolate-volumes-between-teams
|
||||
- path: /deploy/access-control/isolate-volumes-between-teams/
|
||||
title: Isolate volumes
|
||||
- sectiontitle: Tutorials
|
||||
section:
|
||||
- path: /deploy/access-control/howto-deploy-wordpress-with-rbac.md
|
||||
- path: /deploy/access-control/howto-deploy-wordpress-with-rbac/
|
||||
title: Wordpress and MySQL tutorial
|
||||
- path: /deploy/access-control/deploy-view-only-service
|
||||
- path: /deploy/access-control/deploy-view-only-service/
|
||||
title: Deploy service with view-only access
|
||||
- path: /deploy/access-control/access-control-design-ee-standard
|
||||
- path: /deploy/access-control/access-control-design-ee-standard/
|
||||
title: Orcabank tutorial with Docker EE Standard
|
||||
- path: /deploy/access-control/access-control-design-ee-advanced
|
||||
- path: /deploy/access-control/access-control-design-ee-advanced/
|
||||
title: Orcabank tutorial with Docker EE Advanced
|
||||
|
||||
- sectiontitle: Deploy your app in production
|
||||
section:
|
||||
- path: /deploy/
|
||||
|
|
|
|||
|
|
@ -13,12 +13,10 @@ ui_tabs:
|
|||
|
||||
{% if include.ui %}
|
||||
{% if include.version=="ucp-3.0" %}
|
||||
|
||||
## Deploy Kubernetes workload and restrict access
|
||||
This section is under construction.
|
||||
|
||||
{% elsif include.version=="ucp-2.2" %}
|
||||
{% endif %}
|
||||
|
||||
## Deploy Swarm service and restrict access
|
||||
|
||||
In this example, your organization is granted access to a new resource
|
||||
|
|
@ -44,9 +42,8 @@ to the team.
|
|||
3. Click **Create Team**, name the new team `Dev`, and click **Create**.
|
||||
3. Add a non-admin user to the Dev team.
|
||||
|
||||
For more, see:
|
||||
- [Learn how to create and manage users](create-and-manage-users.md).
|
||||
- [Learn how to create and manage teams](create-and-manage-teams.md).
|
||||
For more, see: [Learn how to create users and teams](usermgmt-create-subjects.md).
|
||||
|
||||
|
||||
### Create a collection for the service
|
||||
|
||||
|
|
@ -88,7 +85,108 @@ Currently, users who aren't administrators can't access the
|
|||
`/Shared/View-only services` collection. Create a grant to give the
|
||||
`engineering` organization view-only access.
|
||||
|
||||
> 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*.
|
||||
|
||||
1. Navigate to the **Grants** page and click **Create Grant**.
|
||||
2. In the left pane, click **Collections**, navigate to **/Shared/View-only services**,
|
||||
and click **Select Collection**.
|
||||
3. Click **Roles**, and in the dropdown, select **View Only**.
|
||||
4. Click **Subjects**, and under **Select subject type**, click **Organizations**.
|
||||
In the dropdown, select **engineering**.
|
||||
5. Click **Create** to grant permissions to the organization.
|
||||
|
||||
|
||||
|
||||
Everything is in place to show role-based access control in action.
|
||||
|
||||
### Verify the user's permissions
|
||||
|
||||
Users in the `engineering` organization have view-only access to the
|
||||
`/Shared/View-only services` collection. You can confirm this by logging in
|
||||
as a non-admin user in the organization and trying to delete the service.
|
||||
|
||||
1. Log in as the user who you assigned to the Dev team.
|
||||
2. Navigate to the **Services** page and click **WordPress**.
|
||||
3. In the details pane, confirm that the service's collection is
|
||||
**/Shared/View-only services**.
|
||||
|
||||
|
||||
|
||||
4. Click the checkbox next to the **WordPress** service, click **Actions**,
|
||||
and select **Remove**. You get an error message, because the user
|
||||
doesn't have `Service Delete` access to the collection.
|
||||
|
||||
{% elsif include.version=="ucp-2.2" %}
|
||||
|
||||
## Deploy Swarm service and restrict access
|
||||
|
||||
In this example, your organization is granted access to a new resource
|
||||
collection that contains one Swarm service.
|
||||
|
||||
1. Create an organization and a team.
|
||||
2. Create a collection for the view-only service.
|
||||
3. Deploy a Swarm serivce.
|
||||
4. Create a grant to manage user access to the collection.
|
||||
|
||||
|
||||
|
||||
|
||||
### Create an organization
|
||||
|
||||
Create an organization with one team, and add one user who isn't an administrator
|
||||
to the team.
|
||||
|
||||
1. Log in to UCP as an administrator.
|
||||
2. Navigate to the **Organizations & Teams** page and click
|
||||
**Create Organization**. Name the new organization `engineering` and
|
||||
click **Create**.
|
||||
3. Click **Create Team**, name the new team `Dev`, and click **Create**.
|
||||
3. Add a non-admin user to the Dev team.
|
||||
|
||||
For more, see: [Learn how to create users and teams](usermgmt-create-subjects.md).
|
||||
|
||||
|
||||
### Create a collection for the service
|
||||
|
||||
1. Navigate to the **Collections** page to view all of the resource
|
||||
collections in the swarm.
|
||||
2. Find the **Shared** collection and click **View children**.
|
||||
3. Click **Create collection** and name the collection `View-only services`.
|
||||
4. Click **Create** to create the collection.
|
||||
|
||||
|
||||
|
||||
The `/Shared/View-only services` collection is ready to use for access
|
||||
control.
|
||||
|
||||
### Deploy a service
|
||||
|
||||
Currently, the new collection has no resources assigned to it. To access
|
||||
resources through this collection, deploy a new service and add it to the
|
||||
collection.
|
||||
|
||||
1. Navigate to the **Services** page and create a new service, named
|
||||
`WordPress`.
|
||||
2. In the **Image** textbox, enter `wordpress:latest`. This identifies the
|
||||
most recent WordPress image in the Docker Store.
|
||||
3. In the left pane, click **Collection**. The **Swarm** collection appears.
|
||||
4. Click **View children** to list all of the collections. In **Shared**,
|
||||
Click **View children**, find the **View-only services** collection and
|
||||
select it.
|
||||
5. Click **Create** to add the "WordPress" service to the collection and
|
||||
deploy it.
|
||||
|
||||
|
||||
|
||||
You're ready to create a grant for controlling access to the "WordPress" service.
|
||||
|
||||
### Create a grant
|
||||
|
||||
Currently, users who aren't administrators can't access the
|
||||
`/Shared/View-only services` collection. Create a grant to give the
|
||||
`engineering` organization view-only access.
|
||||
|
||||
> A grant is made up of a *subject*, a *role*, and a *resource collection*.
|
||||
|
||||
1. Navigate to the **Grants** page and click **Create Grant**.
|
||||
2. In the left pane, click **Collections**, navigate to **/Shared/View-only services**,
|
||||
|
|
@ -119,6 +217,8 @@ as a non-admin user in the organization and trying to delete the service.
|
|||
and select **Remove**. You get an error message, because the user
|
||||
doesn't have `Service Delete` access to the collection.
|
||||
|
||||
{% endif %}
|
||||
|
||||
### Where to go next
|
||||
|
||||
- [Isolate volumes between two different teams](isolate-volumes-between-teams.md)
|
||||
|
|
|
|||
|
|
@ -26,13 +26,15 @@ next_steps:
|
|||
{% if include.version=="ucp-3.0" %}
|
||||
|
||||
With Docker Universal Control Plane (UCP), you can authorize how users view,
|
||||
edit, and use cluster resources by granting role-based permissions.
|
||||
edit, and use cluster resources by granting role-based permissions. Resources
|
||||
can be grouped according to an organization's needs and users can be granted
|
||||
more than one role.
|
||||
|
||||
To authorize access to cluster resources across your organization, Docker
|
||||
administrators should take the following high-level steps:
|
||||
administrators might take the following high-level steps:
|
||||
|
||||
- Add and configure subjects (users and teams)
|
||||
- Define customer roles (or use defaults) by adding permissions resource types
|
||||
- Define customer roles (or use defaults) by adding permissions to resource types
|
||||
- Group cluster resources into Swarm collections or Kubernetes namespaces
|
||||
- Create grants by marrying subject + role + resource
|
||||
|
||||
|
|
@ -50,7 +52,7 @@ role that defines permitted operations against one or more resources.
|
|||
|
||||
For more, see:
|
||||
- [Create users and teams in UCP](./usermgmt-create-subjects.md)
|
||||
- [Synchronize users and teams with LDAP](./usermgmt-sync-teams-with-ldap.md)
|
||||
- [Synchronize users and teams with LDAP](./usermgmt-sync-with-ldap.md)
|
||||
|
||||
## Roles
|
||||
|
||||
|
|
@ -66,7 +68,7 @@ Most organizations use different roles to fine-tune the approprate access. A
|
|||
given team or user may have different roles provided to them depending on what
|
||||
resource they are accessing.
|
||||
|
||||
For more, see: [Create roles that define user access to resources](./usermgmt-create-roles.md)
|
||||
For more, see: [Create roles that define user access to resources](./usermgmt-define-roles.md)
|
||||
|
||||
## Resources
|
||||
|
||||
|
|
@ -86,7 +88,7 @@ holds Kubernetes resources.
|
|||
> Kubernetes resources types that can be placed into a namespace include: Pods,
|
||||
> Deployments, NetworkPolcies, Nodes, Services, Secrets, and many more.
|
||||
|
||||
For more, see: [Group resources into collections or namespaces](resources-create-collections-namespaces.md).
|
||||
For more, see: [Group resources into collections or namespaces](resources-group-resources.md).
|
||||
|
||||
## Grants
|
||||
|
||||
|
|
@ -107,14 +109,16 @@ For more, see: [Create grants and authorize access to users and teams](usermgmt-
|
|||
|
||||
{% elsif include.version=="ucp-2.2" %}
|
||||
|
||||
With Docker Universal Control Plane (UCP), you can authorize how users view,
|
||||
edit, and use cluster resources by granting role-based permissions.
|
||||
With [Docker Universal Control Plane (UCP)](https://docs.docker.com/datacenter/ucp/2.2/guides/),
|
||||
you can authorize how users view, edit, and use cluster resources by granting
|
||||
role-based permissions. Resources can be grouped according to an organization's
|
||||
needs and users can be granted more than one role.
|
||||
|
||||
To authorize access to cluster resources across your organization, Docker
|
||||
administrators should take the following high-level steps:
|
||||
administrators might take the following high-level steps:
|
||||
|
||||
- Add and configure subjects (users and teams)
|
||||
- Define customer roles (or use defaults) by adding permissions resource types
|
||||
- Define customer roles (or use defaults) by adding permissions to resource types
|
||||
- Group cluster resources into Swarm collections
|
||||
- Create grants by marrying subject + role + resource
|
||||
|
||||
|
|
@ -132,7 +136,7 @@ role that defines permitted operations against one or more resources.
|
|||
|
||||
For more, see:
|
||||
- [Create users and teams in UCP](./usermgmt-create-subjects.md)
|
||||
- [Synchronize users and teams with LDAP](./usermgmt-sync-teams-with-ldap.md)
|
||||
- [Synchronize users and teams with LDAP](./usermgmt-sync-with-ldap.md)
|
||||
|
||||
## Roles
|
||||
|
||||
|
|
@ -148,7 +152,7 @@ Most organizations use different roles to fine-tune the approprate access. A
|
|||
given team or user may have different roles provided to them depending on what
|
||||
resource they are accessing.
|
||||
|
||||
For more, see [Create roles that define user access to resources](./usermgmt-create-roles.md)
|
||||
For more, see [Create roles that define user access to resources](./usermgmt-define-roles.md)
|
||||
|
||||
## Resources
|
||||
|
||||
|
|
@ -162,7 +166,7 @@ that path.
|
|||
> Swarm resources types that can be placed into a collection include: Containers,
|
||||
> Networks, Nodes (physical or virtual), Services, Secrets, and Volumes.
|
||||
|
||||
For more, see: [Group resources into collections](resources-create-collections-namespaces.md).
|
||||
For more, see: [Group resources into collections](resources-group-resources.md).
|
||||
|
||||
## Grants
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Group resources into collections or namespaces
|
||||
title: Group cluster resources
|
||||
description: Learn how to group resources into collections or namespaces to control access.
|
||||
keywords: rbac, ucp, grant, role, permission, authentication, resource collection
|
||||
redirect_from:
|
||||
|
|
@ -79,7 +79,7 @@ preselected option is the default collection, but this can be changed.
|
|||
Users can't deploy a resource without a collection. When deploying a
|
||||
resource in CLI without an access label, UCP automatically places the
|
||||
resource in the user's default collection.
|
||||
[Learn how to add labels to cluster nodes](../admin/configure/add-labels-to-cluster-nodes/).
|
||||
[Learn how to add labels to cluster nodes](../../datacenter/ucp/2.2/guides/admin/configure/add-labels-to-cluster-nodes/).
|
||||
|
||||
When using Docker Compose, the system applies default collection labels
|
||||
across all resources in the stack, unless the `com.docker.ucp.access.label`
|
||||
|
|
@ -222,7 +222,7 @@ preselected option is the default collection, but this can be changed.
|
|||
Users can't deploy a resource without a collection. When deploying a
|
||||
resource in CLI without an access label, UCP automatically places the
|
||||
resource in the user's default collection.
|
||||
[Learn how to add labels to cluster nodes](../admin/configure/add-labels-to-cluster-nodes/).
|
||||
[Learn how to add labels to cluster nodes](../../datacenter/ucp/2.2/guides/admin/configure/add-labels-to-cluster-nodes/).
|
||||
|
||||
When using Docker Compose, the system applies default collection labels
|
||||
across all resources in the stack, unless the `com.docker.ucp.access.label`
|
||||
|
|
@ -18,19 +18,19 @@ Control Plane (UCP).
|
|||
|
||||
Individual users can belong to one or more teams but each team can only be in
|
||||
one ogranziation. At the fictional startup, Acme Company, some users are on
|
||||
multiple teams; but all teams are necessarily unique.
|
||||
multiple teams; but all teams are necessarily unique:
|
||||
|
||||
```
|
||||
Acme Organization
|
||||
├── DevOps Team
|
||||
│ ├── User Alex
|
||||
│ └── User Brad
|
||||
│ ├── *User Alex*
|
||||
│ └── User Bart
|
||||
├── Infra Team
|
||||
│ ├── User Alex
|
||||
│ └── User Carl
|
||||
│ ├── *User Alex*
|
||||
│ └── User Chen
|
||||
└── Apps Team
|
||||
├── User Doug
|
||||
└── User Evan
|
||||
├── User Deva
|
||||
└── User Emma
|
||||
```
|
||||
|
||||
## Authentication
|
||||
|
|
@ -40,17 +40,11 @@ and also integrates with LDAP directory services.
|
|||
|
||||
> To enable LDAP and authenticate and synchronize UCP users and teams with your
|
||||
> organization's LDAP directory, see:
|
||||
> - [Synchronize users and teams with LDAP in the UI](./usermgmt-sync-teams-with-ldap.md)
|
||||
> - [Synchronize users and teams with LDAP on the backend](../configure/external-auth/index.md).
|
||||
> - [Synchronize users and teams with LDAP in the UI](usermgmt-sync-with-ldap.md)
|
||||
> - [Integrate with an LDAP Directory](../../datacenter/ucp/2.2/guides/admin/configure/external-auth/index.md).
|
||||
|
||||
To use UCP built-in authentication, you must manually create users.
|
||||
|
||||
New users are assigned a default permission level so that they can access the
|
||||
cluster. You can optionally grant them UCP administrator permissions.
|
||||
|
||||
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.
|
||||
|
||||
## Build an organization architecture
|
||||
|
||||
The general flow of designing an organization of teams in UCP is:
|
||||
|
|
@ -60,7 +54,7 @@ The general flow of designing an organization of teams in UCP is:
|
|||
3. Create teams under the organization
|
||||
4. Add users to teams manually or sync with LDAP
|
||||
|
||||
### Create organizations
|
||||
### Create an organization with teams
|
||||
|
||||
To create an organzation in UCP:
|
||||
|
||||
|
|
@ -69,25 +63,28 @@ To create an organzation in UCP:
|
|||
3. Input the organization name.
|
||||
4. Click **Create**.
|
||||
|
||||
### Create teams manually
|
||||
To create teams in the organization:
|
||||
|
||||
1. Click **Organization & Teams** under **User Management**.
|
||||
2. Click through an organization name.
|
||||
3. Click **Create Team**.
|
||||
4. Input a team name (and description).
|
||||
5. Click **Create**.
|
||||
6. Add existing users to the team. If they don't exist, see below.
|
||||
- Click the team name.
|
||||
- Select **Actions** > **Add Users**.
|
||||
- Check users to include.
|
||||
- Click **Add Users**.
|
||||
1. Click through the organization name.
|
||||
2. Click **Create Team**.
|
||||
3. Input a team name (and description).
|
||||
4. Click **Create**.
|
||||
5. Add existing users to the team. If they don't exist, see [Create users manually](#Create-users-manually).
|
||||
- Click the team name and select **Actions** > **Add Users**.
|
||||
- Check the users to include and click **Add Users**.
|
||||
|
||||
> **Note**: To sync teams with groups in an LDAP server, see [Sync Teams with LDAP](./usermgmt-sync-teams-with-ldap).
|
||||
> **Note**: To sync teams with groups in an LDAP server, see [Sync Teams with LDAP](./usermgmt-sync-with-ldap).
|
||||
|
||||
|
||||
{% if include.version=="ucp-3.0" %}
|
||||
|
||||
### Create users manuallly
|
||||
### Create users manually
|
||||
|
||||
New users are assigned a default permission level so that they can access the
|
||||
cluster. You can optionally grant them UCP administrator permissions.
|
||||
|
||||
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.
|
||||
|
||||
To manally create users in UCP:
|
||||
|
||||
|
|
@ -108,6 +105,12 @@ To manally create users in UCP:
|
|||
|
||||
### Create users manuallly
|
||||
|
||||
New users are assigned a default permission level so that they can access the
|
||||
cluster. You can optionally grant them UCP administrator permissions.
|
||||
|
||||
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.
|
||||
|
||||
To manally create users in UCP:
|
||||
|
||||
1. Navigate to the **Users** page.
|
||||
|
|
@ -116,16 +119,15 @@ To manally create users in UCP:
|
|||
4. Click **Create**.
|
||||
5. [optional] Check "Is a UCP admin?".
|
||||
|
||||
{: .with-border}
|
||||
|
||||
> A `UCP Admin` can grant users permission to change the cluster configuration
|
||||
> and manage grants, roles, and collections.
|
||||
|
||||
{: .with-border}
|
||||
{: .with-border}
|
||||
{% endif %}
|
||||
|
||||
## Where to go next
|
||||
|
||||
- [Synchronize users and teams with LDAP](./usermgmt-sync-teams-with-ldap.md)
|
||||
- [Synchronize users and teams with LDAP](./usermgmt-sync-with-ldap.md)
|
||||
- [Create grants and authorize access to users and teams](usermgmt-grant-permissions.md).
|
||||
{% endif %}
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Create roles and set permission levels
|
||||
description: Learn how to create roles and configure user authorization in Docker Universal Control Plane.
|
||||
title: Create roles and authorize operations
|
||||
description: Learn how to create roles and set permissions in Docker Universal Control Plane.
|
||||
keywords: rbac, authorization, authentication, users, teams, UCP
|
||||
redirect_from:
|
||||
- /ucp/
|
||||
|
|
@ -12,13 +12,12 @@ ui_tabs:
|
|||
---
|
||||
|
||||
{% if include.ui %}
|
||||
|
||||
{% if include.version=="ucp-3.0" %}
|
||||
|
||||
Docker Universal Control Plane has two types of users: administrators and
|
||||
regular users. Administrators can make changes to the UCP swarm, while
|
||||
regular users have permissions that range from no access to full control over
|
||||
resources such as volumes, networks, images, and containers.
|
||||
regular users. Administrators can make changes to the UCP cluster, while regular
|
||||
users have permissions that range from no access to full control over resources
|
||||
such as volumes, networks, images, and containers.
|
||||
|
||||
Users are grouped into teams and organizations.
|
||||
|
||||
|
|
@ -30,10 +29,10 @@ permissions to swarm resources.
|
|||
## Administrator users
|
||||
|
||||
In Docker UCP, only users with administrator privileges can make changes to
|
||||
swarm settings. This includes:
|
||||
cluster settings. This includes:
|
||||
|
||||
* Managing user permissions by creating grants.
|
||||
* Managing swarm configurations, like adding and removing nodes.
|
||||
* Managing cluster configurations, like adding and removing nodes.
|
||||
|
||||
## Roles
|
||||
|
||||
|
|
@ -44,13 +43,20 @@ UCP administrators view and manage roles by navigating to the **Roles** page.
|
|||
|
||||
The system provides the following default roles:
|
||||
|
||||
| Built-in role | Description |
|
||||
|----------------------|-------------|
|
||||
| `None` | The user has no access to swarm resources. This maps to the `No Access` role in UCP 2.1.x. |
|
||||
| `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 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. |
|
||||
- **None**: Users have no access to swarm resources. This role maps to the
|
||||
`No Access` role in UCP 2.1.x.
|
||||
- **View Only**: Users can view resources but can't create them.
|
||||
- **Restricted Control**: Users can view and edit resources but can't run a
|
||||
service or container in a way that affects the node where it's running. Users
|
||||
_cannot_: mount a node directory, `exec` into containers, or run containers in
|
||||
privileged mode or with additional kernel capabilities.
|
||||
- **Scheduler**: Users can view nodes and schedule workloads on them. Worker nodes
|
||||
and manager nodes are affected by `Scheduler` grants. By default, all users get
|
||||
a grant with the `Scheduler` role against the `/Shared` collection. Having
|
||||
`Scheduler` access doesn't allow users to view workloads on these nodes--they
|
||||
need the appropriate resource permissions such as `Container View`.
|
||||
- **Full Control**: Users can view and edit all granted resources. They can create
|
||||
containers without any restriction, but can't see the containers of other users.
|
||||
|
||||
|
||||
|
||||
|
|
@ -70,6 +76,13 @@ 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".
|
||||
|
||||
1. Click **Roles** under **User Management**.
|
||||
2. Click **Create Role**.
|
||||
3. Input the role name on the **Details** page.
|
||||
4. Click **Operations**.
|
||||
5. Select the permitted operations per resource type.
|
||||
6. Click **Create**.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
You can give a role a global name, like "Remove Images", which might enable
|
||||
|
|
@ -83,19 +96,15 @@ and create it again.
|
|||
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
|
||||
|
||||
* [Create and manage users](create-and-manage-users.md)
|
||||
* [Create and manage teams](create-and-manage-teams.md)
|
||||
* [Docker Reference Architecture: Securing Docker EE and Security Best Practices](https://success.docker.com/Architecture/Docker_Reference_Architecture%3A_Securing_Docker_EE_and_Security_Best_Practices)
|
||||
|
||||
|
||||
{% elsif include.version=="ucp-2.2" %}
|
||||
|
||||
Docker Universal Control Plane has two types of users: administrators and
|
||||
regular users. Administrators can make changes to the UCP swarm, while
|
||||
regular users have permissions that range from no access to full control over
|
||||
resources such as volumes, networks, images, and containers.
|
||||
regular users. Administrators can make changes to the UCP cluster, while regular
|
||||
users have permissions that range from no access to full control over resources
|
||||
such as volumes, networks, images, and containers.
|
||||
|
||||
Users are grouped into teams and organizations.
|
||||
|
||||
|
|
@ -107,10 +116,10 @@ permissions to swarm resources.
|
|||
## Administrator users
|
||||
|
||||
In Docker UCP, only users with administrator privileges can make changes to
|
||||
swarm settings. This includes:
|
||||
cluster settings. This includes:
|
||||
|
||||
* Managing user permissions by creating grants.
|
||||
* Managing swarm configurations, like adding and removing nodes.
|
||||
* Managing cluster configurations, like adding and removing nodes.
|
||||
|
||||
## Roles
|
||||
|
||||
|
|
@ -121,13 +130,20 @@ UCP administrators view and manage roles by navigating to the **Roles** page.
|
|||
|
||||
The system provides the following default roles:
|
||||
|
||||
| Built-in role | Description |
|
||||
|----------------------|-------------|
|
||||
| `None` | The user has no access to swarm resources. This maps to the `No Access` role in UCP 2.1.x. |
|
||||
| `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 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. |
|
||||
- **None**: Users have no access to swarm resources. This role maps to the
|
||||
`No Access` role in UCP 2.1.x.
|
||||
- **View Only**: Users can view resources but can't create them.
|
||||
- **Restricted Control**: Users can view and edit resources but can't run a
|
||||
service or container in a way that affects the node where it's running. Users
|
||||
_cannot_: mount a node directory, `exec` into containers, or run containers in
|
||||
privileged mode or with additional kernel capabilities.
|
||||
- **Scheduler**: Users can view nodes and schedule workloads on them. Worker nodes
|
||||
and manager nodes are affected by `Scheduler` grants. By default, all users get
|
||||
a grant with the `Scheduler` role against the `/Shared` collection. Having
|
||||
`Scheduler` access doesn't allow users to view workloads on these nodes--they
|
||||
need the appropriate resource permissions such as `Container View`.
|
||||
- **Full Control**: Users can view and edit all granted resources. They can create
|
||||
containers without any restriction, but can't see the containers of other users.
|
||||
|
||||
|
||||
|
||||
|
|
@ -147,6 +163,13 @@ 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".
|
||||
|
||||
1. Click **Roles** under **User Management**.
|
||||
2. Click **Create Role**.
|
||||
3. Input the role name on the **Details** page.
|
||||
4. Click **Operations**.
|
||||
5. Select the permitted operations per resource type.
|
||||
6. Click **Create**.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
You can give a role a global name, like "Remove Images", which might enable
|
||||
|
|
@ -159,12 +182,12 @@ and create it again.
|
|||
|
||||
You can't delete a custom role if it's used in a grant. You must first delete
|
||||
the grants that use the role.
|
||||
{% endif %}
|
||||
|
||||
## Where to go next
|
||||
|
||||
* [Create and manage users](create-and-manage-users.md)
|
||||
* [Create and manage teams](create-and-manage-teams.md)
|
||||
* [Docker Reference Architecture: Securing Docker EE and Security Best Practices](https://success.docker.com/Architecture/Docker_Reference_Architecture%3A_Securing_Docker_EE_and_Security_Best_Practices)
|
||||
|
||||
{% endif %}
|
||||
*
|
||||
{% endif %}
|
||||
Loading…
Reference in New Issue