mirror of https://github.com/docker/docs.git
70 lines
2.4 KiB
Markdown
70 lines
2.4 KiB
Markdown
---
|
|
title: Node access control in Docker EE Advanced
|
|
description: Learn how to architect node access with Docker Enterprise Edition Standard.
|
|
keywords: authorize, authentication, node, UCP, role, access control
|
|
redirect_from:
|
|
- /ucp/
|
|
ui_tabs:
|
|
- version: ucp-3.0
|
|
orhigher: true
|
|
- version: ucp-2.2
|
|
orlower: true
|
|
---
|
|
|
|
{% if include.ui %}
|
|
{% if include.version=="ucp-3.0" %}
|
|
|
|
*Node access control* lets you segment scheduling and visibility by node. Node access control is available in [Docker EE Advanced](https://www.docker.com/pricing) with Swarm orchestration only.
|
|
|
|
{% elsif include.version=="ucp-2.2" %}
|
|
|
|
*Node access control* lets you segment scheduling and visibility by node. Node access control is available in [Docker EE Advanced](https://www.docker.com/pricing).
|
|
|
|
{% endif %}
|
|
|
|
By default, non-infrastructure nodes (non-UCP & DTR nodes) belong to a built-in
|
|
collection called `/Shared`. All application workloads in the cluster are
|
|
scheduled on nodes in the `/Shared` collection. This includes those deployed in
|
|
private collections (`/Shared/Private/`) or any other collection under
|
|
`/Shared`.
|
|
|
|
This setting is enabled by a built-in grant that assigns every UCP user the
|
|
`scheduler` capability against the `/Shared` collection.
|
|
|
|
Node Access Control works by placing nodes in custom collections (outside of
|
|
`/Shared`). If a user or team is granted a role with the `scheduler` capability
|
|
against a collection, then they can schedule containers and services on these
|
|
nodes.
|
|
|
|
In the following example, users with `scheduler` capability against
|
|
`/collection1` can schedule applications on those nodes.
|
|
|
|
Again, these collections lie outside of the `/Shared` collection so users
|
|
without grants do not have access to these collections unless it is explicitly
|
|
granted. These users can only 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)
|
|
{% endif %}
|