diff --git a/_data/toc.yaml b/_data/toc.yaml index 91e246d526..e1e923e3e2 100644 --- a/_data/toc.yaml +++ b/_data/toc.yaml @@ -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/ diff --git a/deploy/access-control/deploy-view-only-service.md b/deploy/access-control/deploy-view-only-service.md index 7f124c4a25..c442d46c70 100644 --- a/deploy/access-control/deploy-view-only-service.md +++ b/deploy/access-control/deploy-view-only-service.md @@ -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. + +![](../images/deploy-view-only-service-4.png) + +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**. + + ![](../images/deploy-view-only-service-2.png) + +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. + + +![](../images/view-only-access-diagram.svg) + +### 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. + +![](../images/deploy-view-only-service-1.png) + +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. + +![](../images/deploy-view-only-service-3.png) + +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) diff --git a/deploy/access-control/index.md b/deploy/access-control/index.md index ef879668e5..ea8a4af7b5 100644 --- a/deploy/access-control/index.md +++ b/deploy/access-control/index.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 diff --git a/deploy/access-control/resources-create-collections-namespaces.md b/deploy/access-control/resources-group-resources.md similarity index 98% rename from deploy/access-control/resources-create-collections-namespaces.md rename to deploy/access-control/resources-group-resources.md index d3037ae03a..dc3e88ee76 100644 --- a/deploy/access-control/resources-create-collections-namespaces.md +++ b/deploy/access-control/resources-group-resources.md @@ -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` diff --git a/deploy/access-control/usermgmt-create-subjects.md b/deploy/access-control/usermgmt-create-subjects.md index fe08c435dd..7948378a2b 100644 --- a/deploy/access-control/usermgmt-create-subjects.md +++ b/deploy/access-control/usermgmt-create-subjects.md @@ -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?". -![](../images/create-users-1.png){: .with-border} - > A `UCP Admin` can grant users permission to change the cluster configuration > and manage grants, roles, and collections. +![](../images/create-users-1.png){: .with-border} ![](../images/create-users-2.png){: .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 %} diff --git a/deploy/access-control/usermgmt-create-roles.md b/deploy/access-control/usermgmt-define-roles.md similarity index 58% rename from deploy/access-control/usermgmt-create-roles.md rename to deploy/access-control/usermgmt-define-roles.md index bc9ca54d4d..f609db0f44 100644 --- a/deploy/access-control/usermgmt-create-roles.md +++ b/deploy/access-control/usermgmt-define-roles.md @@ -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. ![Diagram showing UCP permission levels](../images/permissions-ucp.svg) @@ -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**. + ![](../images/custom-role.png){: .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. ![Diagram showing UCP permission levels](../images/permissions-ucp.svg) @@ -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**. + ![](../images/custom-role.png){: .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 %}