docs/deploy/access-control/access-control-node.md

title	description	keywords	redirect_from	ui_tabs
Node access control in Docker EE Advanced	Learn how to architect node access with Docker Enterprise Edition Standard.	authorize, authentication, node, UCP, role, access control	/ucp/	version orhigher ucp-3.0 true version orlower ucp-2.2 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 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.

{% 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 {% endif %}