mirror of https://github.com/docker/docs.git
Merge pull request #9567 from traci-morrison/update-ee-branding
Remove Advanced and Standard names
This commit is contained in:
Traci Morrison
GitHub
commit
46b217ba6e
|
|
@ -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/
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
|
||||
{: .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)
|
||||
- [Access control design with Docker Enterprise](ee-advanced.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.
|
||||
|
||||
{: .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
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
|
||||
{: .with-border}
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue