Incorporate feedback on rbac topics (#104)

* Incorporate more feedback on rbac topics

* Update permissions image

datacenter/ucp/2.2/guides/admin/manage-users/grant-permissions.md

@@ -11,7 +11,7 @@ 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.
+"Restricted Control" permissions for the "/Production" collection.
 
 The usual workflow for creating grants has four steps.
 
@@ -26,12 +26,11 @@ The usual workflow for creating grants has four steps.
 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
+1.  Click **Create Grant**. All of the collections in the system are listed.
+2.  Click **Select** on the collection you want to grant access to.
+3.  In the left pane, click **Roles** and select a role from the dropdown list.
+4.  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**. 
+5.  Select a user, team, or organization and click **Create**. 
 

datacenter/ucp/2.2/guides/admin/manage-users/index.md

@@ -1,6 +1,6 @@
 ---
-title: Authentication and authorization
-description: Manage access to containers, services, volumes, and networks by using role-based access control
+title: Authentication
+description: Manage access to containers, services, volumes, and networks by using role-based access control.
 keywords: ucp, grant, role, permission, authentication, authorization
 ---
 
@@ -19,6 +19,12 @@ A grant defines who (subject) has how much access (role)
 to a set of resources (collection).
 [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
+collections. An administrator identifies which operations can be performed
+against specific resources and who can perform these actions. An administrator
+can create and manage role assignments against subject in the system.
+Only an administrator can manage subjects, grants, roles, and collections. 
+
 ## Subjects
 
 A subject represents a user, team, or organization. A subject is granted a
@@ -32,11 +38,6 @@ role for a collection of resources.
     team itself. A team exists only as part of an organization, and all of its
     members must be members of the organization. Team members share
     organization permissions. A team can be in one organization only.
--   **Administrator**: A person who identifies which operations can be
-    performed against specific resources and who can perform these actions.
-    An administrator can create and manage role assignments against any user,
-    team, and organization in the system. Only administrators can manage
-    grants. 
 
 ## Roles
 
@@ -51,7 +52,7 @@ 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. 
-[Learn to manage access to resources by using collections](manage-access-with-collections.md).
+[Manage access to resources by using collections](manage-access-with-collections.md).
 
 ## Transition from UCP 2.1 access control
 

datacenter/ucp/2.2/guides/admin/manage-users/manage-access-with-collections.md

@@ -39,9 +39,9 @@ allowed against the target.
 
 UCP provides a number of built-in collections.
 
--  `/` or `/Swarm` - The root swarm collection. All resources in the
+-  `/` - The path to the `Swarm` collection. All resources in the
    cluster are here. Resources that aren't in a collection are assigned
-   to the root `/Swarm` directory.
+   to the `/` directory.
 -  `/System` - The system collection, which contains UCP managers, DTR nodes,
    and UCP/DTR system services. By default, only admins have access to the 
    system collection, but you can change this.
@@ -60,8 +60,9 @@ in UI preferences. When a user deploys a resource in the web UI, the
 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 puts the user’s
-default collection label on the resource.
+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](/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`
@@ -69,8 +70,10 @@ has been set explicitly.
 
 ## Collections and labels
 
-Label limitations still apply to collections. You can't modify collections
-after resource creation for containers, networks, and volumes. You can
+Resources are marked as being in a collection by using labels.
+Some resource types don't have editable labels, so you can't move resources
+like this across collections. You can't modify collections after
+resource creation for containers, networks, and volumes, but you can
 update labels for services, nodes, secrets, and configs. 
 
 For editable resources, like services, secrets, nodes, and configs,

datacenter/ucp/2.2/guides/admin/manage-users/permission-levels.md

@@ -33,9 +33,10 @@ 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 schedule and view workloads on worker nodes. 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. |
 
 ![Diagram showing UCP permission levels](../../images/permissions-ucp.png)
@@ -51,16 +52,16 @@ list, click a role to see the API operations that it uses. For example, the
 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".
+role that uses the node operations, `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.
+Only an administrator can create and remove roles. Roles are always enabled.
+Roles can't be edited, so to change a role's API operations, you must delete it
+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.