diff --git a/_data/toc.yaml b/_data/toc.yaml index 809cc15d3c..7654c98d0c 100644 --- a/_data/toc.yaml +++ b/_data/toc.yaml @@ -1442,9 +1442,9 @@ manuals: - path: /ee/ucp/authorization/pull-images/ title: Allow users to pull images - path: /ee/ucp/authorization/ee-standard/ - title: Docker Enterprise Standard use case + title: Access control design - path: /ee/ucp/authorization/ee-advanced/ - title: Docker Enterprise Advanced use case + title: Access control design using additional security requirements - sectiontitle: Access UCP section: - path: /ee/ucp/user-access/ diff --git a/ee/ucp/admin/install/index.md b/ee/ucp/admin/install/index.md index dc2b9ff1fc..7650ede3a3 100644 --- a/ee/ucp/admin/install/index.md +++ b/ee/ucp/admin/install/index.md @@ -16,7 +16,7 @@ the same version of Docker Enterprise. > Cloud Providers > -> If you are installing on a public cloud platform there is cloud specific UCP +> If you are installing on a public cloud platform, there is cloud specific UCP > installation documentation. For [Microsoft > Azure](./cloudproviders/install-on-azure/) this is **mandatory**, for > [AWS](./cloudproviders/install-on-aws/) this is optional. @@ -94,7 +94,7 @@ To install UCP: ## Step 5: License your installation -Now that UCP is installed, you need to license it. To use UCP you are required to have a Docker Enterprise standard or advanced subscription, or you can test the platform with a free trial license. +Now that UCP is installed, you need to license it. To use UCP, you are required to have a Docker Enterprise subscription, or you can test the platform with a free trial license. 1. Go to [Docker Hub](https://hub.docker.com/editions/enterprise/docker-ee-trial/trial) to get a free trial license. diff --git a/ee/ucp/admin/monitor-and-troubleshoot/index.md b/ee/ucp/admin/monitor-and-troubleshoot/index.md index 60a4db72aa..915d9fd259 100644 --- a/ee/ucp/admin/monitor-and-troubleshoot/index.md +++ b/ee/ucp/admin/monitor-and-troubleshoot/index.md @@ -65,7 +65,7 @@ use GET instead. ## Monitoring vulnerability counts -For those implementations with an EE Advanced subscription, UCP displays image +For those implementations with a subscription, UCP displays image vulnerability count data from the DTR image scanning feature. UCP displays vulnerability counts for containers, Swarm services, pods, and images. diff --git a/ee/ucp/authorization/ee-advanced.md b/ee/ucp/authorization/ee-advanced.md index c6a3f124a0..325732441e 100644 --- a/ee/ucp/authorization/ee-advanced.md +++ b/ee/ucp/authorization/ee-advanced.md @@ -1,11 +1,11 @@ --- -title: Access control design with Docker Enterprise -description: Learn how to architect multitenancy with Docker Enterprise. +title: Access control design using additional security requirements +description: Learn how to architect multi-tenancy with Docker Enterprise. keywords: authorize, authentication, users, teams, groups, sync, UCP, role, access control --- -Go through the [Docker Enterprise Standard tutorial](ee-standard.md), -before continuing here with Docker Enterprise Advanced. +Go through the [Docker Enterprise tutorial](ee-standard.md), +before completing the following tutorial. In the first tutorial, the fictional company, OrcaBank, designed an architecture with role-based access control (RBAC) to meet their organization's security @@ -15,16 +15,17 @@ collection boundaries on a single platform. In this tutorial, OrcaBank implements new and more stringent security requirements for production applications: -First, OrcaBank adds staging zone to their deployment model. They will no longer -move developed appliciatons directly in to production. Instead, they will deploy +1. First, OrcaBank adds staging zone to their deployment model. They will no longer +move developed applications directly in to production. Instead, they will deploy apps from their dev cluster to staging for testing, and then to production. - -Second, production applications are no longer permitted to share any physical +2. Second, production applications are no longer permitted to share any physical infrastructure with non-production infrastructure. OrcaBank segments the scheduling and access of applications with [Node Access Control](isolate-nodes.md). -> [Node Access Control](isolate-nodes.md) is a feature of Docker EE -> Advanced and provides secure multi-tenancy with node-based isolation. Nodes +> Note +> +> [Node Access Control](isolate-nodes.md) is a feature of Docker Enterprise +> and provides secure multi-tenancy with node-based isolation. Nodes > can be placed in different collections so that resources can be scheduled and > isolated on disparate physical or virtual hardware resources. @@ -109,7 +110,7 @@ access shared `db` networks and secrets. ## OrcaBank access architecture -The resulting access architecture, designed with Docker EE Advanced, provides +The resulting access architecture, designed with Docker Enterprise, provides physical segmentation between production and staging using node access control. Applications are scheduled only on UCP worker nodes in the dedicated application diff --git a/ee/ucp/authorization/ee-standard.md b/ee/ucp/authorization/ee-standard.md index f43e08f4f3..aef30209dd 100644 --- a/ee/ucp/authorization/ee-standard.md +++ b/ee/ucp/authorization/ee-standard.md @@ -1,6 +1,6 @@ --- -title: Access control design with Docker EE Standard -description: Learn how to architect multitenancy by using Docker Enterprise Edition Advanced. +title: Access control design +description: Learn how to architect multi-tenancy by using Docker Enterprise. keywords: authorize, authentication, users, teams, groups, sync, UCP, role, access control --- @@ -53,9 +53,6 @@ built-in collection, `/Shared`. Other collections are also being created to enable shared `db` applications. -> **Note**: For increased security with node-based isolation, use Docker -> Enterprise Advanced. - - `/Shared/mobile` hosts all Mobile applications and resources. - `/Shared/payments` hosts all Payments applications and resources. - `/Shared/db` is a top-level collection for all `db` resources. @@ -107,9 +104,11 @@ collection boundaries. By assigning multiple grants per team, the Mobile and Payments applications teams can connect to dedicated Database resources through a secure and controlled interface, leveraging Database networks and secrets. -> **Note**: In Docker Enterprise Standard, all resources are deployed across the +> Note +> +> In Docker Enterprise, all resources are deployed across the > same group of UCP worker nodes. Node segmentation is provided in Docker -> Enterprise Advanced and discussed in the [next tutorial](ee-advanced.md). +> Enterprise and discussed in the [next tutorial](ee-advanced.md). ![image](../images/design-access-control-adv-2.png){: .with-border} @@ -130,4 +129,4 @@ minus the database tier that is managed by the `db` team. ## Where to go next -- [Access control design with Docker EE Advanced](ee-advanced.md) \ No newline at end of file +- [Access control design with Docker Enterprise](ee-advanced.md) \ No newline at end of file diff --git a/ee/ucp/authorization/group-resources.md b/ee/ucp/authorization/group-resources.md index 746c151311..8f6757f616 100644 --- a/ee/ucp/authorization/group-resources.md +++ b/ee/ucp/authorization/group-resources.md @@ -6,7 +6,7 @@ redirect_from: - /datacenter/ucp/3.0/guides/authorization/group-resources/ --- -Docker EE enables access control to cluster resources by grouping resources +Docker Enterprise 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. @@ -55,7 +55,7 @@ the user, which specifies the operations that are allowed against the target. ### Built-in collections -Docker EE provides a number of built-in collections. +Docker Enterprise provides a number of built-in collections. ![](../images/collections-diagram.svg){: .with-border} @@ -63,7 +63,7 @@ Docker EE provides a number of built-in collections. |:-------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `/` | Path to all resources in the Swarm cluster. Resources not in a collection are put here. | | `/System` | Path to UCP managers, DTR nodes, and UCP/DTR system services. By default, only admins have access, but this is configurable. | -| `/Shared` | Default path to all worker nodes for scheduling. In Docker EE Standard, all worker nodes are located here. In [Docker EE Advanced](https://www.docker.com/enterprise-edition), worker nodes can be moved and [isolated](isolate-nodes.md). | +| `/Shared` | Default path to all worker nodes for scheduling. Worker nodes can be moved and [isolated](isolate-nodes.md). | | `/Shared/Private/` | Path to a user's private collection. Note that private collections are not created until the user logs in for the first time. | | `/Shared/Legacy` | Path to the access control labels of legacy versions (UCP 2.1 and lower). | @@ -73,7 +73,7 @@ Docker EE provides a number of built-in collections. Each user has a default collection which can be changed in UCP preferences. Users can't deploy a resource without a collection. When a user deploys a -resource without an access label, Docker EE automatically places the resource in +resource without an access label, Docker Enterprise automatically places the resource in the user's default collection. [Learn how to add labels to nodes](../admin/configure/add-labels-to-cluster-nodes.md). With Docker Compose, the system applies default collection labels across all @@ -93,8 +93,10 @@ set. Resources are marked as being in a collection by using labels. Some resource types don't have editable labels, so you can't move them across collections. -> Can edit labels: services, nodes, secrets, and configs -> Cannot edit labels: containers, networks, and volumes +> Note +> +> You can edit the `services`, `nodes`, `secrets`, and `configs` labels. +> You cannot edit the `containers`, `networks`, and `volumes` labels. For editable resources, you can change the `com.docker.ucp.access.label` to move resources to different collections. For example, you may need deploy resources diff --git a/ee/ucp/authorization/index.md b/ee/ucp/authorization/index.md index cd48db04ac..5bef618736 100644 --- a/ee/ucp/authorization/index.md +++ b/ee/ucp/authorization/index.md @@ -5,7 +5,7 @@ keywords: ucp, grant, role, permission, authentication, authorization, resource, --- [Docker Universal Control Plane (UCP)](../index.md), -the UI for [Docker EE](https://www.docker.com/enterprise-edition), lets you +the UI for [Docker Enterprise](https://www.docker.com/enterprise-edition), lets you authorize users to view, edit, and use cluster resources by granting role-based permissions against resource sets. @@ -131,8 +131,10 @@ Persistent Volumes using the following storage classes: Local storage class allows a user to mount directorys from the host into a pod. This could be a file, a directory, or even the Docker Socket. - > Note: If an Admin has created a persistent volume with the local storage - > class, a non-admin could consume this via a persitent volume claim. + > Note + > + > If an admin has created a persistent volume with the local storage + > class, a non-admin could consume this via a persistent volume claim. If a user without a cluster admin role tries to deploy a pod with any of these privileged options, an error similar to the following example is displayed: diff --git a/ee/ucp/authorization/isolate-nodes.md b/ee/ucp/authorization/isolate-nodes.md index c0f36d6cfd..7b36b01566 100644 --- a/ee/ucp/authorization/isolate-nodes.md +++ b/ee/ucp/authorization/isolate-nodes.md @@ -1,10 +1,10 @@ --- -title: Isolate cluster nodes in Docker Advanced +title: Isolate cluster nodes description: Create grants that limit access to nodes to specific teams. keywords: ucp, grant, role, permission, authentication, node, Kubernetes --- -With Docker EE Advanced, you can enable physical isolation of resources +With Docker Enterprise, you can enable physical isolation of resources by organizing nodes into collections and granting `Scheduler` access for different users. To control access to nodes, move them to dedicated collections where you can grant access to specific users, teams, and organizations. @@ -15,8 +15,12 @@ In this example, a team gets access to a node collection and a resource collection, and UCP access control ensures that the team members can't view or use swarm resources that aren't in their collection. -You need a Docker EE Advanced license and at least two worker nodes to -complete this example. +> Note +> +> You need a Docker Enterprise license and at least two worker nodes to +> complete this example. + +To isolate cluster nodes: 1. Create an `Ops` team and assign a user to it. 2. Create a `/Prod` collection for the team's node. @@ -73,12 +77,12 @@ Move a worker node by changing the value of its access label key, its value from `/Shared` to `/Prod`. 4. Click **Save** to move the node to the `/Prod` collection. -> Docker EE Advanced required +> Note > -> If you don't have a Docker EE Advanced license, you'll get the following +> If you don't have a Docker Enterprise license, you will get the following > error message when you try to change the access label: -> **Nodes must be in either the shared or system collection without an advanced license.** -> [Get a Docker EE Advanced license](https://www.docker.com/pricing). +> **Nodes must be in either the shared or system collection without a license.** +> [Get a Docker Enterprise license](https://www.docker.com/pricing). ![](../images/isolate-nodes-1.png){: .with-border}