mirror of https://github.com/docker/docs.git
Refactor rbac topics (#4229)
* Refactor rbac topics * Make headings sentence case
This commit is contained in:
Joao Fernandes
GitHub
parent
e90b12c425
commit
1fa5f5988d
|
|
@ -26,7 +26,7 @@ cgroups: |
|
|||
collection: |
|
||||
A collection is a group of swarm resources that Docker EE uses for role-based
|
||||
access control. Collections enable organizing permissions for resources like
|
||||
nodes, services, containers, volumes, networks, and secrets. [Learn how to manage collections](/datacenter/ucp/2.2/guides/admin/manage-users/manage-access-with-collections.md).
|
||||
nodes, services, containers, volumes, networks, and secrets. [Learn how to manage collections](/datacenter/ucp/2.2/guides/access-control/manage-access-with-collections.md).
|
||||
Compose: |
|
||||
[Compose](https://github.com/docker/compose) is a tool for defining and
|
||||
running complex applications with Docker. With compose, you define a
|
||||
|
|
@ -151,7 +151,7 @@ grant: |
|
|||
A grant enables role-based access control for managing how users and
|
||||
organizations access Docker EE swarm resources. A grant is made up of a
|
||||
subject, a role, and a collection. For more about grants and role-based access
|
||||
control, see [Grant permissions to users based on roles](/datacenter/ucp/2.2/guides/admin/manage-users/grant-permissions.md).
|
||||
control, see [Grant permissions to users based on roles](/datacenter/ucp/2.2/guides/access-control/grant-permissions.md).
|
||||
image: |
|
||||
Docker images are the basis of [containers](#container). An Image is an
|
||||
ordered collection of root filesystem changes and the corresponding
|
||||
|
|
@ -233,14 +233,14 @@ role: |
|
|||
A role is a set of permitted API operations on a collection of Docker EE swarm
|
||||
resources. As part of a grant, a role is assigned to a subject (a user, team, or
|
||||
organization) and a collection. For more about roles, see [Roles and
|
||||
permission levels](/datacenter/ucp/2.2/guides/admin/manage-users/permission-levels.md).
|
||||
permission levels](/datacenter/ucp/2.2/guides/access-control/permission-levels.md).
|
||||
role-based access control: |
|
||||
Role-based access control enables managing how Docker EE users can access
|
||||
swarm resources. UCP administrators create grants to control how users access
|
||||
resource collections. A grant is made up of a subject, a role, and a collection.
|
||||
A grant defines who (subject) has how much access (role) to a set of resources
|
||||
(collection). For more about role-based access control, see
|
||||
[Authentication](/datacenter/ucp/2.2/guides/admin/manage-users/index.md).
|
||||
[Authentication](/datacenter/ucp/2.2/guides/access-control/index.md).
|
||||
SSH: |
|
||||
SSH (secure shell) is a secure protocol for accessing remote machines and applications.
|
||||
It provides authentication and encrypts data communication over insecure networks such
|
||||
|
|
@ -270,7 +270,7 @@ service discovery: |
|
|||
subject: |
|
||||
A subject represents a user, team, or organization in Docker EE. A subject is
|
||||
granted a role for access to a collection of swarm resources.
|
||||
For more about role-based access, see [Authentication](/datacenter/ucp/2.2/guides/admin/manage-users/index.md).
|
||||
For more about role-based access, see [Authentication](/datacenter/ucp/2.2/guides/access-control/index.md).
|
||||
swarm: |
|
||||
A [swarm](/engine/swarm/) is a cluster of one or more Docker Engines running in [swarm mode](#swarm-mode).
|
||||
Docker Swarm: |
|
||||
|
|
|
|||
|
|
@ -1362,28 +1362,6 @@ manuals:
|
|||
title: Use domain names to access services
|
||||
- path: /datacenter/ucp/2.2/guides/admin/configure/use-your-own-tls-certificates/
|
||||
title: Use your own TLS certificates
|
||||
- sectiontitle: Manage users
|
||||
section:
|
||||
- path: /datacenter/ucp/2.2/guides/admin/manage-users/
|
||||
title: Authentication and authorization
|
||||
- path: /datacenter/ucp/2.2/guides/admin/manage-users/create-and-manage-users/
|
||||
title: Create and manage users
|
||||
- path: /datacenter/ucp/2.2/guides/admin/manage-users/create-and-manage-teams/
|
||||
title: Create and manage teams
|
||||
- path: /datacenter/ucp/2.2/guides/admin/manage-users/deploy-view-only-service/
|
||||
title: Deploy a service with view-only access across an organization
|
||||
- path: /datacenter/ucp/2.2/guides/admin/manage-users/grant-permissions/
|
||||
title: Grant permissions to users based on roles
|
||||
- path: /datacenter/ucp/2.2/guides/admin/manage-users/isolate-nodes-between-teams/
|
||||
title: Isolate swarm nodes to a specific team
|
||||
- path: /datacenter/ucp/2.2/guides/admin/manage-users/isolate-volumes-between-teams/
|
||||
title: Isolate volumes between two different teams
|
||||
- path: /datacenter/ucp/2.2/guides/admin/manage-users/manage-access-with-collections/
|
||||
title: Manage access to resources by using collections
|
||||
- path: /datacenter/ucp/2.2/guides/admin/manage-users/permission-levels/
|
||||
title: Permission levels
|
||||
- path: /datacenter/ucp/2.2/guides/admin/manage-users/recover-a-user-password/
|
||||
title: Recover a user password
|
||||
- sectiontitle: Monitor and troubleshoot
|
||||
section:
|
||||
- path: /datacenter/ucp/2.2/guides/admin/monitor-and-troubleshoot/
|
||||
|
|
@ -1428,6 +1406,34 @@ manuals:
|
|||
title: uninstall-ucp
|
||||
- path: /datacenter/ucp/2.2/reference/cli/upgrade/
|
||||
title: upgrade
|
||||
- sectiontitle: Access control
|
||||
section:
|
||||
- path: /datacenter/ucp/2.2/guides/access-control/
|
||||
title: Access control model
|
||||
- path: /datacenter/ucp/2.2/guides/access-control/create-and-manage-users/
|
||||
title: Create and manage users
|
||||
- path: /datacenter/ucp/2.2/guides/access-control/create-and-manage-teams/
|
||||
title: Create and manage teams
|
||||
- path: /datacenter/ucp/2.2/guides/access-control/deploy-view-only-service/
|
||||
title: Deploy a service with view-only access across an organization
|
||||
- path: /datacenter/ucp/2.2/guides/access-control/grant-permissions/
|
||||
title: Grant permissions to users based on roles
|
||||
- path: /datacenter/ucp/2.2/guides/access-control/isolate-nodes-between-teams/
|
||||
title: Isolate swarm nodes to a specific team
|
||||
- path: /datacenter/ucp/2.2/guides/access-control/isolate-volumes-between-teams/
|
||||
title: Isolate volumes between two different teams
|
||||
- path: /datacenter/ucp/2.2/guides/access-control/manage-access-with-collections/
|
||||
title: Manage access to resources by using collections
|
||||
- path: /datacenter/ucp/2.2/guides/access-control/access-control-node/
|
||||
title: Node access control
|
||||
- path: /datacenter/ucp/2.2/guides/access-control/permission-levels/
|
||||
title: Permission levels
|
||||
- path: /datacenter/ucp/2.2/guides/access-control/access-control-design-ee-standard/
|
||||
title: Access control design with Docker EE Standard
|
||||
- path: /datacenter/ucp/2.2/guides/access-control/access-control-design-ee-advanced/
|
||||
title: Access control design with Docker EE Advanced
|
||||
- path: /datacenter/ucp/2.2/guides/access-control/recover-a-user-password/
|
||||
title: Recover a user password
|
||||
- sectiontitle: User guides
|
||||
section:
|
||||
- sectiontitle: Access UCP
|
||||
|
|
|
|||
|
|
@ -0,0 +1,127 @@
|
|||
---
|
||||
title: Access control design with Docker EE Advanced
|
||||
description: Learn how to architect multitenancy by using Docker Enterprise Edition Advanced.
|
||||
keywords: authorize, authentication, users, teams, groups, sync, UCP, role, access control
|
||||
---
|
||||
|
||||
[Collections and grants](index.md) are strong tools that can be used to control
|
||||
access and visibility to resources in UCP. The previous tutorial,
|
||||
[Access Control Design with Docker EE Standard](access-control-design-ee-standard.md),
|
||||
describes a fictional company called OrcaBank that has designed a resource
|
||||
access architecture that fits the specific security needs of their organization.
|
||||
Be sure to go through this tutorial if you have not already before continuing.
|
||||
|
||||
In this tutorial OrcaBank's deployment model is becoming more advanced.
|
||||
Instead of moving developed applications directly in to production,
|
||||
OrcaBank will now deploy apps from their dev cluster to a staging zone of
|
||||
their production cluster. After applications have passed staging they will
|
||||
be moved to production. OrcaBank has very stringent security requirements for
|
||||
production applications. Its security team recently read a blog post about
|
||||
DevSecOps and is excited to implement some changes. Production applications
|
||||
aren't permitted to share any physical infrastructure with non-Production
|
||||
infrastructure.
|
||||
|
||||
In this tutorial OrcaBank will use Docker EE Advanced feature to segment the
|
||||
scheduling and access control of applications across disparate physical
|
||||
infrastructure. [Node Access Control](access-control-node.md) with EE Advanced
|
||||
licensing allows nodes to be placed in different collections so that resources
|
||||
can be scheduled and isolated on disparate physical or virtual hardware
|
||||
resources.
|
||||
|
||||
## Team access requirements
|
||||
|
||||
As in the [Introductory Multitenancy Tutorial](access-control-design-ee-standard.md)
|
||||
OrcaBank still has three application teams, `payments`, `mobile`, and `db` that
|
||||
need to have varying levels of segmentation between them. Their upcoming Access
|
||||
Control redesign will organize their UCP cluster in to two top-level collections,
|
||||
Staging and Production, which will be completely separate security zones on
|
||||
separate physical infrastructure.
|
||||
|
||||
- `security` should have visibility-only access across all
|
||||
applications that are in Production. The security team is not
|
||||
concerned with Staging applications and thus will not have
|
||||
access to Staging
|
||||
- `db` should have the full set of operations against all database
|
||||
applications that are in Production. `db` does not manage the
|
||||
databases that are in Staging, which are managed directly by the
|
||||
application teams.
|
||||
- `payments` should have the full set of operations to deploy Payments
|
||||
apps in both Production and Staging and also access some of the shared
|
||||
services provided by the `db` team.
|
||||
- `mobile` has the same rights as the `payments` team, with respect to the
|
||||
Mobile applications.
|
||||
|
||||
## Role composition
|
||||
|
||||
OrcaBank will use the same roles as in the Introductory Tutorial. An `ops` role
|
||||
will provide them with the ability to deploy, destroy, and view any kind of
|
||||
resource. `View Only` will be used by the security team to only view resources
|
||||
with no edit rights. `View & Use Networks + Secrets` will be used to access
|
||||
shared resources across collection boundaries, such as the `db` services that
|
||||
are offered by the `db` collection to the other app teams.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
|
||||
## Collection architecture
|
||||
|
||||
The previous tutorial had separate collections for each application team.
|
||||
In this Access Control redesign there will be collections for each zone,
|
||||
Staging and Production, and also collections within each zone for the
|
||||
individual applications. Another major change is that Docker nodes will be
|
||||
segmented themselves so that nodes in Staging are separate from Production
|
||||
nodes. Within the Production zone every application will also have their own
|
||||
dedicated nodes.
|
||||
|
||||
The resulting collection architecture takes the following tree representation:
|
||||
|
||||
```
|
||||
/
|
||||
├── System
|
||||
├── Shared
|
||||
├── prod
|
||||
│ ├── db
|
||||
│ ├── mobile
|
||||
│ └── payments
|
||||
└── staging
|
||||
├── mobile
|
||||
└── payments
|
||||
```
|
||||
|
||||
## Grant composition
|
||||
|
||||
OrcaBank will now be granting teams diverse roles to different collections.
|
||||
Multiple grants per team are required to grant this kind of access. Each of
|
||||
the Payments and Mobile applications will have three grants that give them the
|
||||
operation to deploy in their production zone, their staging zone, and also the
|
||||
ability to share some resources with the `db` collection.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
## OrcaBank access architecture
|
||||
|
||||
The resulting access architecture provides the appropriate physical segmentation
|
||||
between Production and Staging. Applications will be scheduled only on the UCP
|
||||
Worker nodes in the collection where the application is placed. The production
|
||||
Mobile and Payments applications use shared resources across collection
|
||||
boundaries to access the databases in the `/prod/db` collection.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
### DB team
|
||||
|
||||
The OrcaBank `db` team is responsible for deploying and managing the full
|
||||
lifecycle of the databases that are in Production. They have the full set of
|
||||
operations against all database resources.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
### Mobile team
|
||||
|
||||
The `mobile` team is responsible for deploying their full application stack in
|
||||
staging. In production they deploy their own applications but utilize the
|
||||
databases that are provided by the `db` team.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,121 @@
|
|||
---
|
||||
title: Access control design with Docker EE Standard
|
||||
description: Learn how to architect multitenancy by using Docker Enterprise Edition Advanced.
|
||||
keywords: authorize, authentication, users, teams, groups, sync, UCP, role, access control
|
||||
---
|
||||
|
||||
[Collections and grants](index.md) are strong tools that can be used to control
|
||||
access and visibility to resources in UCP. This tutorial describes a fictitious
|
||||
company named OrcaBank that is designing the access architecture for two
|
||||
application teams that they have, Payments and Mobile.
|
||||
|
||||
This tutorial introduces many concepts include collections, grants, centralized
|
||||
LDAP/AD, and also the ability for resources to be shared between different teams
|
||||
and across collections.
|
||||
|
||||
## Team access requirements
|
||||
|
||||
OrcaBank has organized their application teams to specialize more and provide
|
||||
shared services to other applications. A `db` team was created just to manage
|
||||
the databases that other applications will utilize. Additionally, OrcaBank
|
||||
recently read a book about DevOps. They have decided that developers should be
|
||||
able to deploy and manage the lifecycle of their own applications.
|
||||
|
||||
- `security` should have visibility-only access across all applications in the
|
||||
swarm.
|
||||
- `db` should have the full set of capabilities against all database
|
||||
applications and their respective resources.
|
||||
- `payments` should have the full set of capabilities to deploy Payments apps
|
||||
and also access some of the shared services provided by the `db` team.
|
||||
- `mobile` has the same rights as the `payments` team, with respect to the
|
||||
Mobile applications.
|
||||
|
||||
## Role composition
|
||||
|
||||
OrcaBank will use a combination of default and custom roles, roles which they
|
||||
have created specifically for their use case. They are using the default
|
||||
`View Only` role to provide security access to only see but not edit resources.
|
||||
There is an `ops` role that they created which can do almost all operations
|
||||
against all types of resources. They also created the
|
||||
`View & Use Networks + Secrets` role. This type of role will enable application
|
||||
DevOps teams to use shared resources provided by other teams. It will enable
|
||||
applications to connect to networks and use secrets that will also be used by
|
||||
`db` containers, but not the ability to see or impact the `db` applications
|
||||
themselves.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
## Collection architecture
|
||||
|
||||
OrcaBank will also create some collections that fit the organizational structure
|
||||
of the company. Since all applications will share the same physical resources,
|
||||
all nodes and applications are built in to collections underneath the `/Shared`
|
||||
built-in collection.
|
||||
|
||||
- `/Shared/payments` hosts all applications and resources for the Payments
|
||||
applications.
|
||||
- `/Shared/mobile` hosts all applications and resources for the Mobile
|
||||
applications.
|
||||
|
||||
Some other collections will be created to enable the shared `db` applications.
|
||||
|
||||
- `/Shared/db` will be a top-level collection for all `db` resources.
|
||||
- `/Shared/db/payments` will be specifically for `db` resources providing
|
||||
service to the Payments applications.
|
||||
- `/Shared/db/mobile` will do the same for the Mobile applications.
|
||||
|
||||
The following grant composition will show that this collection architecture
|
||||
allows an app team to access shared `db` resources without providing access
|
||||
to _all_ `db` resources. At the same time _all_ `db` resources will be managed
|
||||
by a single `db` team.
|
||||
|
||||
## LDAP/AD integration
|
||||
|
||||
OrcaBank has standardized on LDAP for centralized authentication to help their
|
||||
identity team scale across all the platforms they manage. As a result LDAP
|
||||
groups will be mapped directly to UCP teams using UCP's native LDAP/AD
|
||||
integration. As a result users can be added to or removed from UCP teams via
|
||||
LDAP which can be managed centrally by OrcaBank's identity team. The following
|
||||
grant composition shows how LDAP groups are mapped to UCP teams .
|
||||
|
||||
## Grant composition
|
||||
|
||||
Two grants are applied for each application team, allowing each team to fully
|
||||
manage their own apps in their collection, but also have limited access against
|
||||
networks and secrets within the `db` collection. This kind of grant composition
|
||||
provides flexibility to have different roles against different groups of
|
||||
resources.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
## OrcaBank access architecture
|
||||
|
||||
The resulting access architecture shows applications connecting across
|
||||
collection boundaries. Multiple grants per team allow Mobile applications and
|
||||
Databases to connect to the same networks and use the same secrets so they can
|
||||
securely connect with each other but through a secure and controlled interface.
|
||||
Note that these resources are still deployed across the same group of UCP
|
||||
worker nodes. Node segmentation is discussed in the [next tutorial](#).
|
||||
|
||||
{: .with-border}
|
||||
|
||||
### DB team
|
||||
|
||||
The `db` team is responsible for deploying and managing the full lifecycle
|
||||
of the databases used by the application teams. They have the full set of
|
||||
operations against all database resources.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
### Mobile team
|
||||
|
||||
The `mobile` team is responsible for deploying their own application stack,
|
||||
minus the database tier which is managed by the `db` team.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
## Where to go next
|
||||
|
||||
- [Access control design with Docker EE Advanced](access-control-design-ee-advanced.md)
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,49 @@
|
|||
---
|
||||
title: Node access control in Docker EE Advanced
|
||||
description: Learn how to architect node access by using Docker Enterprise Edition Standard.
|
||||
keywords: authorize, authentication, node, UCP, role, access control
|
||||
---
|
||||
|
||||
The ability to segment scheduling and visibility by node is called
|
||||
*node access control* and is a feature of Docker EE Advanced. By default,
|
||||
all nodes that aren't infrastructure nodes (UCP & DTR nodes) belong to a
|
||||
built-in collection called `/Shared`. By default, all application workloads
|
||||
in the cluster will get scheduled on nodes in the `/Shared` collection. This
|
||||
includes users that are deploying in their private collections
|
||||
(`/Shared/Private/`) and in any other collections under `/Shared`. This is
|
||||
enabled by a built-in grant that grants every UCP user the `scheduler`
|
||||
capability against the `/Shared` collection.
|
||||
|
||||
Node Access Control works by placing nodes in to custom collections outside of
|
||||
`/Shared`. If the `scheduler` capability is granted via a role to a user or
|
||||
group of users against a collection then they will be able to schedule
|
||||
containers and services on these nodes. In the following example, users with
|
||||
`scheduler` capability against `/collection1` will be able to schedule
|
||||
applications on those nodes.
|
||||
|
||||
Note that in the directory these collections lie outside of the `/Shared`
|
||||
collection so users without grants will not have access to these collections
|
||||
unless explicitly granted access. These users will only be able to deploy
|
||||
applications on the built-in `/Shared` collection nodes.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
The tree representation of this collection structure looks like this:
|
||||
|
||||
```
|
||||
/
|
||||
├── Shared
|
||||
├── System
|
||||
├── collection1
|
||||
└── collection2
|
||||
├── sub-collection1
|
||||
└── sub-collection2
|
||||
```
|
||||
|
||||
With the use of default collections, users, teams, and organizations can be
|
||||
constrained to what nodes and physical infrastructure they are capable of
|
||||
deploying on.
|
||||
|
||||
## Where to go next
|
||||
|
||||
- [Isolate swarm nodes to a specific team](isolate-nodes-between-teams.md)
|
||||
|
|
@ -11,7 +11,7 @@ permissions over resources. You do this by adding the user to a team.
|
|||
To create a new team, go to the UCP web UI, and navigate to the
|
||||
**Organizations** page.
|
||||
|
||||
{: .with-border}
|
||||
{: .with-border}
|
||||
|
||||
If you want to put the team in a new organization, click
|
||||
**Create Organization** and give the new organization a name, like
|
||||
|
|
@ -21,7 +21,7 @@ In the list, click the organization where you want to create the new team.
|
|||
Name the team, give it an optional description, and click **Create** to
|
||||
create a new team.
|
||||
|
||||
{: .with-border}
|
||||
{: .with-border}
|
||||
|
||||
## Add users to a team
|
||||
|
||||
|
|
@ -30,7 +30,7 @@ teams list, click the new team, and in the details pane, click **Add Users**.
|
|||
Choose the users that you want to add to the team, and when you're done, click
|
||||
**Add Users**.
|
||||
|
||||
{: .with-border}
|
||||
{: .with-border}
|
||||
|
||||
## Sync team members with your organization's LDAP directory
|
||||
|
||||
|
|
@ -41,7 +41,7 @@ creating a new team or when modifying settings of an existing team.
|
|||
Enabling this option expands the form with additional fields for configuring
|
||||
the sync of team members.
|
||||
|
||||
{: .with-border}
|
||||
{: .with-border}
|
||||
|
||||
There are two methods for matching group members from an LDAP directory:
|
||||
|
||||
|
|
@ -82,7 +82,7 @@ In this example, you'll create a collection for the "Data Center" team,
|
|||
where they can deploy services and resources, and you'll create a grant that
|
||||
gives the team permission to access the collection.
|
||||
|
||||
{: .with-border}
|
||||
{: .with-border}
|
||||
|
||||
1. Navigate to the **Organizations & Teams** page.
|
||||
2. Select **docker-datacenter**, and click **Create Team**. Name the team
|
||||
|
|
@ -101,7 +101,7 @@ gives the team permission to access the collection.
|
|||
**Teams** dropdown, select **Data Center**.
|
||||
11. Click **Create** to create the grant.
|
||||
|
||||
{: .with-border}
|
||||
{: .with-border}
|
||||
|
||||
In this example, you gave members of the `Data Center` team
|
||||
`Restricted Control` permissions to create and edit resources in
|
||||
|
|
@ -19,11 +19,11 @@ swarm.
|
|||
To create a new user, go to the UCP web UI, and navigate to the
|
||||
**Users** page.
|
||||
|
||||
{: .with-border}
|
||||
{: .with-border}
|
||||
|
||||
Click the **Create User** button, and fill-in the user information.
|
||||
|
||||
{: .with-border}
|
||||
{: .with-border}
|
||||
|
||||
Check the `Is a UCP admin?` option, if you want to grant permissions for the
|
||||
user to change the swarm configuration and manage grants, roles, and
|
||||
|
|
@ -11,7 +11,7 @@ collection that contains one service.
|
|||
2. Create a collection for the view-only service.
|
||||
3. Create a grant to manage user access to the collection.
|
||||
|
||||
|
||||
|
||||
|
||||
## Create an organization
|
||||
|
||||
|
|
@ -34,7 +34,7 @@ who isn't an administrator to the team.
|
|||
3. Click **Create collection** and name the collection "View-only services".
|
||||
4. Click **Create** to create the collection.
|
||||
|
||||
|
||||
|
||||
|
||||
The `/Shared/View-only services` collection is ready to use for access
|
||||
control.
|
||||
|
|
@ -56,7 +56,7 @@ collection.
|
|||
5. Click **Create** to add the "WordPress" service to the collection and
|
||||
deploy it.
|
||||
|
||||
|
||||
|
||||
|
||||
You're ready to create a grant for controlling access to the "WordPress" service.
|
||||
|
||||
|
|
@ -74,7 +74,7 @@ Currently, users who aren't administrators can't access the
|
|||
In the dropdown, select **engineering**.
|
||||
5. Click **Create** to grant permissions to the organization.
|
||||
|
||||
|
||||
|
||||
|
||||
Everything is in place to show role-based access control in action.
|
||||
|
||||
|
|
@ -89,7 +89,7 @@ as a non-admin user in the organization and trying to delete the service.
|
|||
3. In the details pane, confirm that the service's collection is
|
||||
**/Shared/View-only services**.
|
||||
|
||||
|
||||
|
||||
|
||||
4. Click the checkbox next to the **WordPress** service, click **Actions**,
|
||||
and select **Remove**. You get an error message, because the user
|
||||
|
|
@ -13,7 +13,7 @@ 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"
|
||||
"Restricted Control" permissions for the "/Production" collection.
|
||||
|
||||
{: .with-border}
|
||||
{: .with-border}
|
||||
|
||||
The usual workflow for creating grants has four steps.
|
||||
|
||||
|
|
@ -0,0 +1,156 @@
|
|||
---
|
||||
title: Access control model
|
||||
description: Manage access to containers, services, volumes, and networks by using role-based access control.
|
||||
keywords: ucp, grant, role, permission, authentication, authorization
|
||||
---
|
||||
|
||||
With Docker Universal Control Plane, you get to control who can create and
|
||||
edit container resources in your swarm, like services, images, networks,
|
||||
and volumes. You can grant and manage permissions to enforce fine-grained
|
||||
access control as needed.
|
||||
|
||||
## Grant access to swarm resources
|
||||
|
||||
If you're a UCP administrator, you can create *grants* to control how users
|
||||
and organizations access swarm resources.
|
||||
|
||||
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).
|
||||
[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
|
||||
role for a collection of resources.
|
||||
|
||||
- **User**: A person that the authentication backend validates. You can
|
||||
assign users to one or more teams and one or more organizations.
|
||||
- **Organization**: A group of users that share a specific set of
|
||||
permissions, defined by the roles of the organization.
|
||||
- **Team**: A group of users that share a set of permissions defined in the
|
||||
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.
|
||||
|
||||
## Roles
|
||||
|
||||
A role is a set of permitted API operations that you can assign to a specific
|
||||
subject and collection by using a grant. UCP administrators view and manage
|
||||
roles by navigating to the **Roles** page.
|
||||
[Learn more about roles and permissions](permission-levels.md).
|
||||
|
||||
## Resource collections
|
||||
|
||||
Docker EE enables controlling access to swarm resources by using
|
||||
*collections*. A collection is a grouping of swarm cluster resources that you
|
||||
access by specifying a directory-like path.
|
||||
|
||||
Swarm resources that can be placed in to a collection include:
|
||||
|
||||
- Physical or virtual nodes
|
||||
- Containers
|
||||
- Services
|
||||
- Networks
|
||||
- Volumes
|
||||
- Secrets
|
||||
- Application configs
|
||||
|
||||
## Collection architecture
|
||||
|
||||
Grants tie together who has which kind of access to what resources. Grants
|
||||
are effectively ACLs, which grouped together, can provide full and comprehensive
|
||||
access policies for an entire organization. However, before grants can be
|
||||
implemented, collections need to be designed to group resources in a way that
|
||||
makes sense for an organization.
|
||||
|
||||
The following example shows a potential access policy of an organization.
|
||||
Consider an organization with two application teams, Mobile and Payments, that
|
||||
will share cluster hardware resources, but still need to segregate access to the
|
||||
applications. Collections should be designed to map to the organizational
|
||||
structure desired, in this case the two application teams. Their collection
|
||||
architecture for a production UCP cluster might look something like this:
|
||||
|
||||
```
|
||||
prod
|
||||
├── mobile
|
||||
└── payments
|
||||
```
|
||||
|
||||
> A subject that has access to any level in a collection hierarchy will have
|
||||
> that same access to any collections below it.
|
||||
|
||||
## Role composition
|
||||
|
||||
Roles define what operations can be done against cluster resources. An
|
||||
organization will likely use several different kinds or roles to give the
|
||||
right kind of access. A given team or user may have different roles provided
|
||||
to them depending on what resource they are accessing. There are default roles
|
||||
provided by UCP and also the ability to build custom roles. In this example
|
||||
three different roles are used:
|
||||
|
||||
- Full Control - This is a default role that provides the full list of
|
||||
operations against cluster resources.
|
||||
- View Only - This is also a default role that allows a user to see resources,
|
||||
but not to edit or delete.
|
||||
- Dev - This is not a default role, but a potential custom role. In this
|
||||
example "Dev" includes the ability to view containers and also `docker exec`.
|
||||
This allows developers to run a shell inside their container process but not
|
||||
see or change any other cluster resources.
|
||||
|
||||
## Grant composition
|
||||
|
||||
The following four grants define the access policy for the entire organization
|
||||
for this cluster. They tie together the collections that were created, the
|
||||
default and custom roles, and also teams of users that are in UCP.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
## Access architecture
|
||||
|
||||
The resulting access architecture defined by these grants is depicted below.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
There are four teams that are given access to cluster resources.
|
||||
|
||||
- `security` can see, but not edit, all resources shown, as it has `View Only`
|
||||
access to the entire `/prod` collection.
|
||||
- `ops` has `Full Control` against the entire `/prod` collection, giving it the
|
||||
capability to deploy, view, edit, and remove applications and application
|
||||
resources.
|
||||
- `mobile` has the `Dev` role against the `/prod/mobile` collection. This team
|
||||
is able to see and `exec` in to their own applications, but will not see any
|
||||
of the `payments` applications.
|
||||
- `payments` has the same type of access but for the `/prod/payments` collection.
|
||||
|
||||
[See a deeper tutorial on how to design access control architectures.](access-control-design-ee-standard.md)
|
||||
|
||||
[Manage access to resources by using collections](manage-access-with-collections.md).
|
||||
|
||||
## Transition from UCP 2.1 access control
|
||||
|
||||
- Your existing access labels and permissions are migrated automatically
|
||||
during an upgrade from UCP 2.1.x.
|
||||
- Unlabeled "user-owned" resources are migrated into the user's private
|
||||
collection, in `/Shared/Private/<username>`.
|
||||
- Old access control labels are migrated into `/Shared/Legacy/<labelname>`.
|
||||
- When deploying a resource, choose a collection instead of an access label.
|
||||
- Use grants for access control, instead of unlabeled permissions.
|
||||
|
||||
## Where to go next
|
||||
|
||||
- [Create and manage users](create-and-manage-users.md)
|
||||
- [Create and manage teams](create-and-manage-teams.md)
|
||||
- [Deploy a service with view-only access across an organization](deploy-view-only-service.md)
|
||||
- [Isolate volumes between two different teams](isolate-volumes-between-teams.md)
|
||||
- [Isolate swarm nodes between two different teams](isolate-nodes-between-teams.md)
|
||||
|
||||
|
|
@ -21,7 +21,7 @@ complete this example.
|
|||
3. Assign a worker node to the `/Prod` collection.
|
||||
4. Grant the `Ops` teams access to its collection.
|
||||
|
||||
{: .with-border}
|
||||
{: .with-border}
|
||||
|
||||
## Create a team
|
||||
|
||||
|
|
@ -78,7 +78,7 @@ Move a worker node by changing the value of its access label key,
|
|||
> **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).
|
||||
|
||||
{: .with-border}
|
||||
{: .with-border}
|
||||
|
||||
## Grant access for a team
|
||||
|
||||
|
|
@ -116,7 +116,7 @@ The same steps apply for the nodes in the `/Prod` collection.
|
|||
7. Click **Create** to grant the Ops team `Scheduler` access to the nodes in the
|
||||
`/Prod` collection.
|
||||
|
||||
{: .with-border}
|
||||
{: .with-border}
|
||||
|
||||
## Deploy a service as a team member
|
||||
|
||||
|
|
@ -155,7 +155,7 @@ All resources are deployed under the user's default collection,
|
|||
6. Click the node, and in the details pane, confirm that its **Collection**
|
||||
is **/Prod**.
|
||||
|
||||
{: .with-border}
|
||||
{: .with-border}
|
||||
|
||||
## Alternative: Use a grant instead of the default collection
|
||||
|
||||
|
|
@ -168,6 +168,7 @@ that has a `Service Create` grant for the user.
|
|||
|
||||
## Where to go next
|
||||
|
||||
- [Node access control in Docker EE Advanced](access-control-node.md)
|
||||
- [Isolate volumes between two different teams](isolate-volumes-between-teams.md)
|
||||
- [Deploy a service with view-only access across an organization](deploy-view-only-service.md)
|
||||
|
||||
|
|
@ -14,7 +14,7 @@ nodes.
|
|||
3. Create grants to manage access to the collections.
|
||||
4. Team members create volumes that are specific to their team.
|
||||
|
||||
{: .with-border}
|
||||
{: .with-border}
|
||||
|
||||
## Create two teams
|
||||
|
||||
|
|
@ -57,7 +57,7 @@ with the `/Shared/prod-volumes` collection.
|
|||
6. Click **Create Grant** and repeat the previous steps for the **/Shared/prod-volumes**
|
||||
collection and the Prod team.
|
||||
|
||||
{: .with-border}
|
||||
{: .with-border}
|
||||
|
||||
With the collections and grants in place, users can sign in and create volumes
|
||||
in their assigned collections.
|
||||
|
|
@ -78,18 +78,18 @@ Team members have permission to create volumes in their assigned collection.
|
|||
to create a "prod-data" volume assigned to the `/Shared/prod-volumes`
|
||||
collection.
|
||||
|
||||
{: .with-border}
|
||||
{: .with-border}
|
||||
|
||||
Now you can see role-based access control in action for volumes. The user on
|
||||
the Prod team can't see the Dev team's volumes, and if you log in again as a
|
||||
user on the Dev team, you won't see the Prod team's volumes.
|
||||
|
||||
{: .with-border}
|
||||
{: .with-border}
|
||||
|
||||
Sign in with a UCP administrator account, and you see all of the volumes
|
||||
created by the Dev and Prod users.
|
||||
|
||||
{: .with-border}
|
||||
{: .with-border}
|
||||
|
||||
## Where to go next
|
||||
|
||||
|
|
@ -53,7 +53,7 @@ UCP provides a number of built-in collections.
|
|||
- `/Shared/Legacy` - After updating from UCP 2.1, all legacy access control
|
||||
labels are stored here.
|
||||
|
||||
{: .with-border}
|
||||
{: .with-border}
|
||||
|
||||
This diagram shows the `/System` and `/Shared` collections that are created
|
||||
by UCP. User private collections are children of the `/Shared/private`
|
||||
|
|
@ -69,7 +69,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](../configure/add-labels-to-cluster-nodes/).
|
||||
[Learn how to add labels to cluster nodes](../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`
|
||||
|
|
@ -121,7 +121,7 @@ collections and create corresponding grants for scheduling tasks.
|
|||
In this example, an administrator has moved worker nodes to a `/prod`
|
||||
collection:
|
||||
|
||||
|
||||
|
||||
|
||||
When you deploy a resource with a collection, UCP sets a constraint implicitly
|
||||
based on what nodes the collection, and any ancestor collections, can access.
|
||||
|
|
@ -39,7 +39,7 @@ The system provides the following default roles:
|
|||
| `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. |
|
||||
|
||||
|
||||
|
||||
|
||||
Administrators can create a custom role that has Docker API permissions
|
||||
that specify the API actions that a subject may perform.
|
||||
|
|
@ -57,7 +57,7 @@ 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".
|
||||
|
||||
{: .with-border}
|
||||
{: .with-border}
|
||||
|
||||
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
|
||||
|
|
@ -14,7 +14,7 @@ the **Users** page, and choose the user whose password you want to change.
|
|||
In the details pane, click **Configure** and select **Security** from the
|
||||
dropdown.
|
||||
|
||||
{: .with-border}
|
||||
{: .with-border}
|
||||
|
||||
Update the user's password and click **Save**.
|
||||
|
||||
|
|
@ -64,5 +64,5 @@ $ docker container run --rm {{ page.ucp_org }}/{{ page.ucp_repo }}:{{ page.ucp_v
|
|||
|
||||
## Where to go next
|
||||
|
||||
- [Create and manage users](../../manage-users/create-and-manage-users.md)
|
||||
- [Create and manage teams](../../manage-users/create-and-manage-teams.md)
|
||||
- [Create and manage users](../../../access-control/create-and-manage-users.md)
|
||||
- [Create and manage teams](../../../access-control/create-and-manage-teams.md)
|
||||
|
|
@ -30,7 +30,7 @@ Now configure your LDAP directory integration.
|
|||
|
||||
Click the dropdown to select the permission level assigned by default to
|
||||
the private collections of new users.
|
||||
[Learn more about permission levels](../../manage-users/permission-levels.md).
|
||||
[Learn more about permission levels](../../../access-control/permission-levels.md).
|
||||
|
||||
## LDAP domains
|
||||
|
||||
|
|
@ -130,7 +130,7 @@ LDAP directory.
|
|||
|
||||
## Where to go next
|
||||
|
||||
- [Create and manage users](../../manage-users/create-and-manage-users.md)
|
||||
- [Create and manage teams](../../manage-users/create-and-manage-teams.md)
|
||||
- [UCP permission levels](../../permission-levels.md)
|
||||
- [Create and manage users](../../../access-control/create-and-manage-users.md)
|
||||
- [Create and manage teams](../../../access-control/create-and-manage-teams.md)
|
||||
- [UCP permission levels](../../../access-control/permission-levels.md)
|
||||
- [Enable LDAP integration by using a configuration file](enable-ldap-config-file.md)
|
||||
|
|
|
|||
|
|
@ -1,75 +0,0 @@
|
|||
---
|
||||
title: Design access control in Docker EE Advanced
|
||||
description: Learn how to architect multitenancy by using Docker Enterprise Edition Advanced.
|
||||
keywords: authorize, authentication, users, teams, groups, sync, UCP, role, access control
|
||||
---
|
||||
|
||||
[Collections and grants](../manage-users/) are strong tools that can be used to control access and visibility to resources in UCP. The previous [Introductory Multitenancy Tutorial](design-access-control-ee-standard.md) describes a fictional company called SecureBank that has designed a resource access architecture that fits the specific security needs of their organization. Be sure to go through this tutorial if you have not already before continuing.
|
||||
|
||||
In this tutorial SecureBank's deployment model and organizational structure has grown in complexity and will require a new UCP access control design to accommodate it. This tutorial builds on the [Introductory Tutorial](design-access-control-ee-standard) by introducing centralized LDAP/AD, multiple grants per team, and also the ability for resources to be shared between different teams.
|
||||
|
||||
|
||||
## Team Access Requirements
|
||||
|
||||
After the initial RBAC design, SecureBank has reorganized their application teams to specialize more and provide shared services to other applications. A `db` team was created just to manage the databases that other applications will utilize. Additionally, SecureBank recently read a book about DevOps. They have decided that developers should have the capability to deploy and manage the lifecycle of their own applications, effectively merging developer and operations teams.
|
||||
|
||||
- `security` should have visibility-only access across all applications in the cluster.
|
||||
- `db` should have the full set of capabilities against all database applications and their respective resources.
|
||||
- `payments` should have the full set of capabilities to deploy Payments apps and also access some of the shared services provided by the `db` team.
|
||||
- `mobile` has the same rights as the `payments` team, with respect to the Mobile applications.
|
||||
|
||||
## Role Composition
|
||||
|
||||
SecureBank will use the same roles as in the Introductory Tutorial, but will replace the `dev` role with a new role called `View & Use Networks + Secrets`. This type of role will enable application DevOps teams to use shared resources provided by other teams. It will enable applications to connect to networks and use secrets that will also be used by `db` containers, but not the ability to see or impact the `db` applications themselves.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
|
||||
## Collection Architecture
|
||||
|
||||
The previous tutorial introduced a tier of collections specific to the types of applications being deployed by SecureBank.
|
||||
|
||||
- `/Shared/payments` hosts all applications and resources for the Payments applications.
|
||||
- `/Shared/mobile` hosts all applications and resources for the Mobile applications.
|
||||
|
||||
Some new collections will be created to enable the shared `db` applications.
|
||||
|
||||
- `/Shared/db` will be a top-level collection for all `db` resources.
|
||||
- `/Shared/db/payments` will be specifically for `db` resources providing service to the Payments applications.
|
||||
- `/Shared/db/mobile` will do the same for the Mobile applications.
|
||||
|
||||
The following grant composition will show that this collection architecture allows an app team to access shared `db` resources without providing access to _all_ `db` resources. At the same time _all_ `db` resources will be managed by a single `db` team.
|
||||
|
||||
## LDAP/AD Integration
|
||||
|
||||
SecureBank has standardized on LDAP for centralized authentication to help their identity team scale across all the platforms they manage. As a result LDAP groups will be mapped directly to UCP teams using UCP's native LDAP/AD integration. As a result users can be added to or removed from UCP teams via LDAP which can be managed centrally by SecureBank's identity team. The following grant composition shows how LDAP groups are mapped to UCP teams .
|
||||
|
||||
## Grant Composition
|
||||
|
||||
The Introductory Tutorial used a design with a 1:1 ratio between grants and teams. That is a valid design but eams can also support multiple grants per team which allows for more complex access scenarios. SecureBank will apply two grants for each application team, allowing each team to fully manage their own apps in their collection, but also have limited access against networks and secrets within the `db` collection.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
|
||||
## SecureBank Access Architecture
|
||||
|
||||
The resulting access architecture shows applications connecting across collection boundaries. Multiple grants per team allow Mobile applications and Databases to connect to the same networks and use the same secrets so they can securely connect with each other but through a secure and controlled interface. Note that these resources are still deployed across the same group of UCP worker nodes. Node segmentation is discussed in the [next tutorial](#).
|
||||
|
||||
{: .with-border}
|
||||
|
||||
|
||||
### DB Team
|
||||
|
||||
The `db` team is responsible for deploying and managing the full lifecycle of the databases used by the application teams. They have the full set of capabilities against all database resources.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
|
||||
|
||||
### Mobile Team
|
||||
|
||||
The `mobile` team is responsible for deploying their own application stack, minus the database tier which is managed by the `db` team.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
|
||||
|
|
@ -1,77 +0,0 @@
|
|||
---
|
||||
title: Design access control in Docker EE Standard
|
||||
description: Learn how to architect multitenancy by using Docker Enterprise Edition Standard.
|
||||
keywords: authorize, authentication, users, teams, groups, sync, UCP, role, access control
|
||||
---
|
||||
|
||||
[Collections and grants](../manage-users/) are strong tools that can be used to control access and visibility to resources in UCP. UCP Access Control is flexible and granular to provide for an access design that fits the architecture and specific needs of diverse organizational structures. Many different structures are possible with the flexibility of UCP and the examples in these tutorials show just a few possible scenarios.
|
||||
|
||||
This example shows a very simple access structure to clearly explain the basics of UCP Access Control at a fictional company named SecureBank.
|
||||
|
||||
## Team Access Requirements
|
||||
|
||||
Company SecureBank deploys their production applications on a UCP cluster. They have four teams that interact with containerized applications along their production lifecycle.
|
||||
|
||||
- `ops` is responsible for deploying and managing all of the operations of all container applications. This is the only team with the capability to deploy applications in the production UCP cluster.
|
||||
- `security` conducts security audits for production applications. They must have visibility across all production container resources in the UCP cluster.
|
||||
- `payments` is a team of developers responsible for payments applications. At SecureBank developers do not deploy applications in to production, however developers can get access directly to the container only to do operations or troubleshooting. This team should only have visibility to their own applications.
|
||||
- `mobile` has the same rights as the `payments` team, but should only be able to have access to only their own applications.
|
||||
|
||||
## Role Composition
|
||||
|
||||
UCP provides some [default roles](../manage-users/permission-levels/#roles) but custom roles can also be created to cater to very specific combinations of capabilities. SecureBank will create custom roles so they can get provide more customized access to resources. SecureBank will have three types of custom roles that will map to the types of actual roles they have in their organization.
|
||||
|
||||
- `Ops` can do any action against any type of resource in the cluster including creating, viewing, and destroying resources.
|
||||
- `View Only` can view but not edit any type of resource in the cluster.
|
||||
- `Dev` can only see services and containers and `exec` into the containers to interact with the processes inside the containers that they have access to.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
## Collection Architecture
|
||||
|
||||
UCP provides [default collections](../manage-users/manage-access-with-collections/#control-access-to-nodes) to enforce broad access rights such as separation between infrastructure (UCP & DTR) nodes and application (worker) nodes. More granular segmentation of users is up to the administrator to design using collections to best fit the organizational structure that they need.
|
||||
|
||||
In addition the the default collections, SecureBank will create two more collections to map to specific application teams in their org.
|
||||
|
||||
- `/Shared` is the default Shared collection that all non-Infra, application hosting nodes will belong to.
|
||||
- `/Shared/payments` is created to host all resources related to the Payments applications.
|
||||
- `/Shared/mobile` is created to host all resources related to the Mobile applications.
|
||||
|
||||
## Grant Composition
|
||||
|
||||
[Grants](../manage-users/grant-permissions/) are the specific rules that govern who has access to which resources. SecureBank will tie together their teams, custom roles, and collections to create a set of grants. The following images shows the four grants that are created that will enforce the access requirements of SecureBank.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
## SecureBank Access Architecture
|
||||
|
||||
The image below shows the access architecture as a result of the UCP Grants. Docker infrastructure nodes that host UCP and DTR are in a `/System` collection that no non-admin UCP users have access to. The remaining UCP worker nodes are by default in the top-level `/Shared` collection and will be shared across all applications.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
### Ops Team
|
||||
|
||||
The `ops` team can execute any capability against resources in the `/Shared` collection. This gives `ops` members the ability to schedule containers on UCP workers, create networks & volumes, and more. The `ops` team has no access against anything in the `/System` collection. When deploying Mobile and Payments applications, `ops` members will select either `/Shared/payments` or `/Shared/mobile` to deploy applications in to.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
### Security Team
|
||||
|
||||
The `security` team can view all resources in the `/Shared` collection. This gives visibility to all resources used by the Mobile and Payments applications.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
|
||||
### Payments Team
|
||||
|
||||
All Mobile applications and their respective resources will be scheduled in the `/Shared/payments` collection. The `payments` team will have visibility to the containers and services in this collection as well as the ability to `exec` in to the container.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
|
||||
### Mobile Team
|
||||
|
||||
The `mobile` team and Mobile applications will also have their own collection, `/Shared/mobile`.
|
||||
|
||||
{: .with-border}
|
||||
|
||||
|
|
@ -1,76 +0,0 @@
|
|||
---
|
||||
title: Authentication
|
||||
description: Manage access to containers, services, volumes, and networks by using role-based access control.
|
||||
keywords: ucp, grant, role, permission, authentication, authorization
|
||||
---
|
||||
|
||||
With Docker Universal Control Plane, you get to control who can create and
|
||||
edit container resources in your swarm, like services, images, networks,
|
||||
and volumes. You can grant and manage permissions to enforce fine-grained
|
||||
access control as needed.
|
||||
|
||||
## Grant access to swarm resources
|
||||
|
||||
If you're a UCP administrator, you can create *grants* to control how users
|
||||
and organizations access swarm resources.
|
||||
|
||||
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).
|
||||
[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
|
||||
role for a collection of resources.
|
||||
|
||||
- **User**: A person that the authentication backend validates. You can
|
||||
assign users to one or more teams and one or more organizations.
|
||||
- **Organization**: A group of users that share a specific set of
|
||||
permissions, defined by the roles of the organization.
|
||||
- **Team**: A group of users that share a set of permissions defined in the
|
||||
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.
|
||||
|
||||
## Roles
|
||||
|
||||
A role is a set of permitted API operations that you can assign to a specific
|
||||
subject and collection by using a grant. UCP administrators view and manage
|
||||
roles by navigating to the **Roles** page.
|
||||
[Learn more about roles and permissions](permission-levels.md).
|
||||
|
||||
## Resource collections
|
||||
|
||||
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.
|
||||
[Manage access to resources by using collections](manage-access-with-collections.md).
|
||||
|
||||
## Transition from UCP 2.1 access control
|
||||
|
||||
- Your existing access labels and permissions are migrated automatically
|
||||
during an upgrade from UCP 2.1.x.
|
||||
- Unlabeled "user-owned" resources are migrated into the user's private
|
||||
collection, in `/Shared/Private/<username>`.
|
||||
- Old access control labels are migrated into `/Shared/Legacy/<labelname>`.
|
||||
- When deploying a resource, choose a collection instead of an access label.
|
||||
- Use grants for access control, instead of unlabeled permissions.
|
||||
|
||||
## Where to go next
|
||||
|
||||
- [Create and manage users](create-and-manage-users.md)
|
||||
- [Create and manage teams](create-and-manage-teams.md)
|
||||
- [Deploy a service with view-only access across an organization](deploy-view-only-service.md)
|
||||
- [Isolate volumes between two different teams](isolate-volumes-between-teams.md)
|
||||
- [Isolate swarm nodes between two different teams](isolate-nodes-between-teams.md)
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 166 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 182 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 176 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 190 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 207 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 209 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 225 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 192 KiB |
|
|
@ -61,7 +61,7 @@ You can also deploy and monitor your applications and services.
|
|||
Docker UCP has its own built-in authentication mechanism and integrates with
|
||||
LDAP services. It also has role-based access control (RBAC), so that you can
|
||||
control who can access and make changes to your swarm and applications.
|
||||
[Learn about role-based access control](admin/manage-users/index.md).
|
||||
[Learn about role-based access control](access-control/index.md).
|
||||
|
||||
{: .with-border}
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ way, from your browser.
|
|||
|
||||
|
||||
Docker UCP secures your swarm by using
|
||||
[role-based access control](../../admin/manage-users/index.md).
|
||||
[role-based access control](../../access-control/index.md).
|
||||
From the browser, administrators can:
|
||||
|
||||
* Manage swarm configurations,
|
||||
|
|
@ -27,5 +27,5 @@ containers, and only when they're granted access by an administrator.
|
|||
|
||||
# Where to go next
|
||||
|
||||
* [Authorization](../../admin/manage-users/index.md)
|
||||
* [Authorization](../../access-control/index.md)
|
||||
* [Access UCP from the CLI](cli-based-access.md)
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ application that allows users to vote on whether they prefer cats or dogs.
|
|||
## Get a client certificate bundle
|
||||
|
||||
Docker UCP secures your Docker swarm with
|
||||
[role-based access control](../../admin/manage-users/index.md),
|
||||
[role-based access control](../../access-control/index.md),
|
||||
so that only authorized users can deploy applications. To be able to run Docker
|
||||
commands on a swarm managed by UCP, you need to configure your Docker CLI
|
||||
client to authenticate to UCP using client certificates.
|
||||
|
|
|
|||
Loading…
Reference in New Issue