Isolate cluster nodes with Swarm¶
This tutorial explains how to give a team access to a node collection and a resource collection. MKE access control ensures that team members cannot view or use Swarm resources that are not in their collection.
You need an MKE license and at least two worker nodes to complete this tutorial.
The following is a high-level overview of the steps you will take to isolate cluster nodes:
Opsteam and assign a user to it.
Prodcollection for the team node.
Assign a worker node to the Prod collection.
Grant the Ops teams access to its collection.
To create a team:
Log in to the MKE web UI.
Create a team named
Opsin your organization.
Add a user to the team who is not an administrator.
To create the team collections:
In this example, the Ops team uses a collection for its assigned nodes and another for its resources.
Create a Swarm collection called
Prodnested under the Swarm collection.
Create a Swarm collection called
Webservernested under the Prod collection.
The Prod collection is for the worker nodes and the Webserver sub-collection is for an application that you will deploy on the corresponding worker nodes.
To move a worker node to a different collection:
MKE places worker nodes in the Shared collection by default, and it places those running MSR in the System collection.
Navigate to Shared Resources > Nodes to view all of the nodes in the swarm.
Find a node located in the Shared collection. You cannot move worker nodes that are assigned to the System collection.
Click the slider icon on the node details page.
In the Labels section on the Details tab, change
Click Save to move the node to the Prod collection.
To create two grants for team access to the two collections:
Create a grant for the Ops team to access the Webserver collection with the built-in Restricted Control role.
Create a grant for the Ops team to access the Prod collection with the built-in Scheduler role.
The cluster is now set up for node isolation. Users with access to nodes in the Prod collection can deploy Swarm services and Kubernetes apps. They cannot, however, schedule workloads on nodes that are not in the collection.
To deploy a Swarm service as a team member:
When a user deploys a Swarm service, MKE assigns its resources to the default collection. As a user on the Ops team, set Webserver to be your default collection.
From the resource target collection, MKE walks up the ancestor collections until it finds the highest ancestor that the user has Scheduler access to. MKE schedules tasks on any nodes in the tree below this ancestor. In this example, MKE assigns the user service to the Webserver collection and schedules tasks on nodes in the Prod collection.
Log in as a user on the Ops team.
Navigate to Shared Resources > Collections.
Navigate to the Webserver collection.
Under the vertical ellipsis menu, select Set to default.
Navigate to Swarm > Services and click Create to create a Swarm service.
Name the service
nginx:latestin the Image* field, and click Create.
Click the NGINX service when it turns green.
Scroll down to TASKS, click the NGINX container, and confirm that it is in the Webserver collection.
Navigate to the Metrics tab on the container page, select the node, and confirm that it is in the Prod collection.
An alternative approach is to use a grant instead of changing the
default collection. An administrator can create a grant for a role that has
the Service Create permission for the Webserver
collection or a child collection. In this case, the user sets the value of
com.docker.ucp.access.label to the new collection or one of its
children that has a Service Create grant for the required user.