Role-Based Access Control¶
Clusters accessed via their agents secure socket require authentication, and a Role-Based Access Crontrol is applied to the API requests.
A user's privileges are described in the
grant keyword of the
usr object. The value is a whitespace-separated list of grant expressions.
Each grant expression can be:
- A cluster-wide role
- A namespace-limited role coupled to a namespace glob
This role is required to deploy and update non-containerized services.
A user granted root has sufficient privilege to read and change system's files and execute commands as the root system user.
A user granted the squatter role can create new namespaces.
When a new namespace is created, the namespace admin role is automatically granted to its squatter.
system namespace is not squattable.
A user granted the blacklistadmin role can clear the client blacklist.
om daemon blacklist clear --node '*'
Can list objects, read status and configurations.
Inherit guest privileges.
set services and volumes target state to:
execute the CRM-level actions:
wake the monitor thread
Inherit guest and operator privileges. Can execute any action in the namespace, notably: deploy and purge.
Volumes deployment by configuration injection is not allowed. Use volume resources in services to express the volume requirements, so the service provision can provision the volumes if necessary.
Unautorized in deployed configurations:
- ip other than ip.cni
- container other than container.docker and container.podman
- task other than task.docker and task.podman
- share, fs, disk, sync (use volumes instead)
- app (use container)
- triggers (use detach=false containers instead)
host paths in keyword values. Use volume-relative paths instead.
give grant that the requester does have
change a usr object cn
monitor_action value other than freezestop and switch