Authorization Policy

Slurm-web offers the possibility to manage permissions to access data with fine-grain role-based access control (RBAC) authorization policy. The authorization policy is enforced at agent level. In multi-clusters mode, policies can be different on all clusters.

Slurm-web permissions are independent of Slurm permissions (ex: privatedata, coordinators, operators, etc…). For example, users can have the permission to view reservations in Slurm-web but not in Slurm and vice-versa. Users can even have permissions in Slurm-web without any permission on Slurm cluster.

Slurm-web agent component is installed with a default vendor authorization policy defined in file /usr/share/slurm-web/conf/policy.ini. This default policy gives anonymous users some permissions and authenticated users a bit more permissions.

Do not edit this default vendor authorization policy, or your changes will be lost on next Slurm-web upgrades!

A site specific policy can be defined in configuration file /etc/slurm-web/policy.ini. When this file is created, the default vendor policy is ignored.

File Format

The authorization policy is an INI file with different sections described below.

Roles Members

The file must have one [roles] section to define roles and their memberships. In this section:

  • Keys are arbitrary name of roles,

  • Values are comma separated list of users and groups associated to this role. The groups names must be prefixed by @. Special value ALL can be used to designate all authenticated users.

A special role name is anonymous. When this role is defined, it is automatically assigned to all users when authentication is disabled on Slurm-web gateway. The key of this special role does not have to be associated to a value.

Arbitrary number of roles can be defined.

Roles Permissions

Sections must be defined for every roles defined in [roles] section. All these sections must have an actions key. The value assigned to this key is the comma-separated list of actions granted to the role.

Examples

Show simple example 
[roles]
user=@biology
admin=njones

[user]
actions=stats-view,jobs-view,jobs-view-past,nodes-view

[admin]
actions=partitions-view,qos-view,accounts-view,reservations-view,associations-view

This policy defines two roles:

  • user for members of biology group. This role has permission on stats-view, jobs-view, jobs-view-past and nodes-view actions.

  • admin for njones user. This role has permission on partitions-view, qos-view, accounts-view, reservations-view and associations-view actions.

User njones who is also member of biology group is granted both user and admin roles, she has access to everything:

slurm web policy admin

Another user in biology group can only view jobs and nodes:

slurm web policy user

Access to the cluster is denied to all other users:

slurm web policy others

Show full example 
[roles]
# Enable anonymous role with basic views
anonymous
# All authenticated users have the user role
user=ALL
# Admin role for it group members
admin=@it,jdoe

[anonymous]
actions=stats-view

[user]
actions=stats-view,jobs-view,jobs-view-past,accounts-view

[admin]
actions=nodes-view,partitions-view,qos-view,reservations-view

Anonymous role is enabled in this authorization policy. It is assigned to all users when authentication is disabled in Slurm-web gateway. This role is only granted the stats-view action.

Two other roles are defined in this authorization policy:

  • user role is assigned to all users authenticated on LDAP directory. This role gives permissions on stats-view, jobs-view, jobs-view-past and accounts-view actions.

  • admin role is assigned to all members of it LDAP group and jdoe individual user. Users with this role haves permissions on nodes-view, partitions-view, qos-view and reservations-view actions.

Members of it group and jdoe inherit both user and admin roles with the union of all granted actions.

Show example to restrict users to their own jobs 
[roles]
user=ALL

[user]
actions=stats-view,jobs-view-own,jobs-view-past-own,nodes-view

Authenticated users with the user role can access the Jobs menu and see only their own active and terminated jobs. The jobs-view-own and jobs-view-past-own actions restrict job lists and details to the current user. Users with jobs-view or jobs-view-past still see all users' jobs for the corresponding scope.

Available Actions

This table describes the list of actions that can be assigned to roles:

Action Description

stats-view

View general cluster statistics in home dashboard and clusters list.

view-stats

Deprecated. Use stats-view instead.

jobs-view

Get Jobs entry in main menu and permission to view all users jobs in queue and all jobs details.

view-jobs

Deprecated. Use jobs-view instead.

jobs-view-own

Get Jobs entry in main menu and permission to view only the current user’s own jobs in queue and own job details.

jobs-view-past

Permission to view all users past jobs and query finished jobs from Slurm accounting.

jobs-view-past-own

Permission to view only the current user’s own terminated jobs from Slurm accounting.

nodes-view

Get Resources entry in main menu and permission to view the list of compute nodes in cluster with their status in Slurm.

view-nodes

Deprecated. Use nodes-view instead.

partitions-view

Permission to filter jobs and nodes by partition.

view-partitions

Deprecated. Use partitions-view instead.

qos-view

Get QOS entry in main menu and permission to view the list of defined QOS.

view-qos

Deprecated. Use qos-view instead.

accounts-view

Permission to filter jobs by account.

view-accounts

Deprecated. Use accounts-view instead.

associations-view

Get Accounts entry in main menu and permission to view the list of associations (accounts, users and limits).

reservations-view

Get Reservations entry in main menu and permission to view the list of defined reservations.

view-reservations

Deprecated. Use reservations-view instead.

cache-view

Access to cache information and metrics in settings panel.

cache-reset

Reset cache statistics in settings panel.