A role defines a set of API operations permitted against a resource set. You apply roles to users and teams by creating grants.
Some important rules regarding roles:
You can define custom roles or use the following built-in roles:
Role | Description |
---|---|
None |
Users have no access to Swarm or Kubernetes resources. Maps to No
Access role in UCP 2.1.x. |
View Only |
Users can view resources but can’t create them. |
Restricted Control |
Users can view and edit resources but can’t run a service or container
in a way that affects the node where it’s running. Users cannot mount a
node directory, exec into containers, or run containers in privileged
mode or
with additional kernel capabilities. |
Scheduler |
Users can view nodes (worker and manager) and schedule (not view)
workloads on these nodes. By default, all users are granted the
Scheduler role against the /Shared collection. (To view
workloads, users need permissions such as Container View ). |
Full Control |
Users can view and edit all granted resources. They can create containers without any restriction, but can’t see the containers of other users. |
When creating custom roles to use with Swarm, the Roles page lists all default and custom roles applicable in the organization. To create custom roles for Kubernetes, see Configure native Kubernetes role-based access control.
You can give a role a global name, such as “Remove Images”, which might enable the Remove and Force Remove operations for images. You can apply a role with the same name to different resource sets.
This section describes the set of operations (calls) that can be executed to the Swarm resources. Be aware that each permission corresponds to a CLI command and enables the user to execute that command.
Some important rules regarding roles**: