Change 'resource group' to 'resource set' (#470)

ee/ucp/authorization/grant-permissions.md

@@ -16,20 +16,20 @@ redirect_from:
 {% if include.version=="ucp-3.0" %}
 
 Docker EE administrators can create _grants_ to control how users and
-organizations access resources.
+organizations access [resource sets](group-resources.md).
 
 A grant defines _who_ has _how much_ access to _what_ resources. Each grant is a
 1:1:1 mapping of _subject_, _role_, and _resource set_. For example, you can
-grant the "Prod Team" "Restricted Control" of services in the "/Production"
-collection.
+grant the "Prod Team" "Restricted Control" over services in the "/Production"
+collection. 
 
 A common workflow for creating grants has four steps:
 
 - Add and configure **subjects** (users and teams).
 - Define custom **roles** (or use defaults) by adding permitted API operations
-  per resource type.
+  per type of resource.
 - Group cluster **resources** into Swarm collections or Kubernetes namespaces.
-- Create **grants** by marrying subject + role + resource group.
+- Create **grants** by combining subject + role + resource set.
 
 ## Kubernetes grants
 
@@ -44,9 +44,9 @@ To create a Kubernetes grant in UCP:
 1. Click **Grants** under **User Management**.
 2. Click **Create Grant**.
 3. Click **Namespaces** under **Kubernetes**.
-4. Click **View Children** until you get to the desired resource group and **Select**.
-5. On the Roles tab, select a role.
-6. On the Subjects tab, select a user, team, or organization to authorize.
+4. Click **View Children** until you get to the desired namespace and **Select**.
+5. On the **Roles** tab, select a role.
+6. On the **Subjects** tab, select a user, team, or organization to authorize.
 7. Click **Create**.
 
 > By default, all new users are placed in the `docker-datacenter` organization.
@@ -69,9 +69,9 @@ To create a grant in UCP:
 1. Click **Grants** under **User Management**.
 2. Click **Create Grant**.
 3. On the Collections tab, click **Collections** (for Swarm).
-4. Click **View Children** until you get to the desired resource group and **Select**.
-5. On the Roles tab, select a role.
-6. On the Subjects tab, select a user, team, or organization to authorize.
+4. Click **View Children** until you get to the desired collection and **Select**.
+5. On the **Roles** tab, select a role.
+6. On the **Subjects** tab, select a user, team, or organization to authorize.
 7. Click **Create**.
 
 > By default, all new users are placed in the `docker-datacenter` organization.

ee/ucp/authorization/group-resources.md

@@ -19,6 +19,14 @@ redirect_from:
 ---
 {% if include.version=="ucp-3.0" %}
 
+Docker EE enables access control to cluster resources by grouping resources
+into *resource sets*. Combine resource sets with [grants](grant-permissions)
+to give users permission to access specific cluster resources.
+
+A resource set can be a UCP collection or a Kubernetes namespace, depending 
+on the orchestrator. Use collections for Swarm workloads, and use namespaces
+for Kubernetes workloads. 
+
 ## Kubernetes namespace
 
 A
@@ -135,6 +143,9 @@ The Docker EE Advanced license enables access control on worker nodes. Admin
 users can move worker nodes from the default `/Shared` collection into other
 collections and create corresponding grants for scheduling tasks.
 
+Also, you can [isolate a Kubernetes workload](isolate-nodes.md##deploy-a-Kubernetes-application)
+to specific worker nodes, based on a Kubernetes namespace.
+
 In this example, an administrator has moved worker nodes to a `/prod`
 collection:
 

ee/ucp/authorization/index.md

@@ -22,23 +22,23 @@ next_steps:
 [Docker Universal Control Plane (UCP)](../index.md),
 the UI for [Docker EE](https://www.docker.com/enterprise-edition), lets you
 authorize users to view, edit, and use cluster resources by granting role-based
-permissions against resource types.
+permissions against resource sets.
 
 To authorize access to cluster resources across your organization, UCP
 administrators might take the following high-level steps:
 
 - Add and configure **subjects** (users and teams).
 - Define custom **roles** (or use defaults) by adding permitted operations per
-  resource types.
+  type of resource.
 - Group cluster **resources** into Swarm collections or Kubernetes namespaces.
-- Create **grants** by combining subject + role + resource group.
+- Create **grants** by combining subject + role + resource set.
 
 For an example, see [Deploy stateless app with RBAC](deploy-stateless-app.md).
 
 ## Subjects
 
 A subject represents a user, team, or organization. A subject can be granted a
-role that defines permitted operations against one or more resource types.
+role that defines permitted operations against one or more resource sets.
 
 - **User**: A person authenticated by the authentication backend. Users can
   belong to one or more teams and one or more organizations.
@@ -47,12 +47,12 @@ role that defines permitted operations against one or more resource types.
 - **Organization**: A group of teams that share a specific set of permissions,
   defined by the roles of the organization.
 
-Learn to [create and configure users and teams](create-users-and-teams-manually.md)
+Learn to [create and configure users and teams](create-users-and-teams-manually.md).
 
 ## Roles
 
 Roles define what operations can be done by whom. A role is a set of permitted
-operations against a *resource type*, like a container or volume, that's
+operations against a type of resource, like a container or volume, that's
 assigned to a user or team with a grant.
 
 For example, the built-in role, **Restricted Control**, includes permission to
@@ -63,7 +63,7 @@ Most organizations use multiple roles to fine-tune the appropriate access. A
 given team or user may have different roles provided to them depending on what
 resource they are accessing.
 
-Learn to [define roles with authorized API operations](define-roles.md)
+Learn to [define roles with authorized API operations](define-roles.md).
 
 ## Resource sets