Role-Based Access Control System#

As described in Role-Based Access Controls, the ClusterWareAI ™ Role-Based Access Control system has multiple primary roles, internal system-used roles, plus the "No Access" pseudo-role. A role is a set of one or more permissions, usually grouped according to an employee's job-related needs. For example, there is an Onsite Engineer role that is designed to capture all the actions a "rack-and-cable" technician might need in their daily job. The ClusterWareAI platform ships with a set of default roles, but admins can also create new roles or modify the existing ones.

Database Primitive Permissions#

Every ClusterWareAI database primitive type has at least a Read and Write permission. Many primitives have additional permissions specific to that primitive type. As an example, the Boot Configs-Read permission allows an admin to read the information about any Boot Configuration in the system. There is also an Image-Write permission that allows an admin to create or overwrite/modify any Image in the system.

Tenants, tenancies, and other features are available if you have paid for multi-tenant support. Contact Penguin Computing to learn more.

Primitive/Feature

Permissions

Actions

ActionsRead

ActionsWrite

Admin

AdminsRead

AdminsWrite

AdminsWriteSelf

AI Factory Operations Agent

UseAiAgent

Attribute Groups

AttribGroupsRead

AttribGroupsReadReserv

AttribGroupsWrite

AttribGroupsWriteReserv

Boot Configs

BootConfigsRead

BootConfigsWrite

Certificates

CertsRead

CertsWrite

Cluster

ClusterRead

ClusterWrite

Distros

DistrosRead

DistrosWrite

Dynamic Groups

DynGroupsRead

DynGroupsWrite

Git Repos

GitReposRead

GitReposWrite

Head Nodes

HeadsRead

HeadsWrite

Health Checks

HealthChecksRead

HealthChecksWrite

Hostnames

HostnamesRead

HostnamesWrite

Images

ImagesRead

ImagesWrite

InfiniBand Networks

IbnetsRead

IbnetsWrite

Multitenancy

MultitenancyRead

MultitenancyWrite

Naming Pools

NamingPoolsRead

NamingPoolsWrite

Networks

NetworksRead

NetworksWrite

Nodes

NodesRead

NodesExecCommand

NodesReadAttribs

NodesReadReserv

NodesWriteGroups

NodesWrite

NodesPowerControl

NodesWriteAttribs

NodesWriteReserv

Providers

ProvidersRead

ProvidersAlloc

ProvidersWrite

Remedies

RemediesRead

RemediesWrite

Repos

ReposRead

ReposWrite

State Maps

StateMapsRead

StateMapsActivate

StateMapsWrite

Switches

SwitchesRead

SwitchesExecCommand

SwitchesReadAttribs

SwitchesReadReserv

SwitchesWriteGroups

SwitchesWrite

SwitchesPowerControl

SwitchesWriteAttribs

SwitchesWriteReserv

Tenancies

TenanciesRead

TenanciesReadSelf

TenanciesWrite

TenanciesWriteSelf

Tenants

TenantsRead

TenantsReadSelf

TenantsWrite

TenantsWriteSelf

All Write permissions include the ability to create, modify, and delete primitives of that type. All Read permissions include the ability to list all primitives of that type and to see their details.

  • Nodes, switches, and attribute groups have ReadReserv and WriteReserv permissions, which allow reading/writing of the reserved attributes, including the attributes that control how the nodes boot. Nodes and switches also have the ReadAttribs and WriteAttribs permissions to allow reading/writing of node or switch attributes. NodesReadReserv and NodesReadAttribs permissions should always be assigned together when configuring user roles.

  • Nodes and switches have ExecCommand to allow execution of code and ssh access. Nodes and switches also have WriteGroups to allow changing which group(s) a given node or switch is joined to (this permission allows addition and removal of groups).

  • Nodes and switches have additional permissions to allow power control through the BMC or IPMI, NodesPowerControl and SwitchesPowerControl.

  • In multi-tenant clusters, tenants and tenancies have ReadSelf and WriteSelf permissions. These are used by the tenant or tenancy making the request to view or make changes. See Multi-Tenant Token Roles for details. Viewing or making changes outside of the tenant or tenancy, such as from the super-cluster instance of ClusterWareAI, requires Read or Write on the tenant or tenancy. Only the Full Admin user has the TenantsRead, TenantsWrite, TenanciesRead, and TenanciesWrite permissions.

User Roles#

The default set of roles provided by the ClusterWareAI software are: Authenticated User, Onsite Engineer, Imaging Engineer, Production Engineer, Manager, and Full Admin. The "No Access" pseudo-role can be used to quickly and easily block access to a user.

If you have multi-tenant support, the Managed Tenant role is also available.

See Role-Based Access Controls for a description of each role.

Note

The No Access role supercedes all other roles and will block even Full Admins from performing any action.

The following table includes a list of roles and their associated permissions. This information is also available from the User Management > Role Mapping page in the ClusterWareAI GUI.

Role

Permission Set

AuthUser

Read permissions for most primitive types, excluding cluster and provider

FullAdmin

all Read and Write permissions for all primitive types;

all special permissions for all primitive types;

UseAiAgent for the AI Factory Operations Agent

NoAccess

all permissions are revoked; account is blocked

ImagingEngineer

inherits from AuthUser, plus:

ImagesWrite, NodesReadReserv, NodesReadAttribs,

AttribGroupsReadReserv

Manager

inherits from AuthUser, plus:

AdminsWrite, NodesReadReserv, NodesReadAttribs,

AttribGroupsReadReserv

OnsiteEngineer

inherits from AuthUser, plus:

NodesPowerControl, NodesWrite, NodesReadAttribs,

NodesWriteAttribs

ProductionEngineer

inherits from AuthUser, plus:

AttribGroupsReadReserv, AttribGroupsWriteReserv

NodesWrite, NodesReadAttribs, NodesWriteAttribs,

NodesWriteGroups, NodesWriteReserv, StateMapsWrite,

StateMapsActivate, NodesPowerControl,

AttribGroupsWrite, ImagesWrite, NamingPoolsWrite,

BootConfigsWrite, GitReposWrite, HealthChecksWrite,

RemediesWrite, ActionsWrite

ManagedTenant

inherits from AuthUser, plus:

AdminsWrite, AttribGroupsWrite, NodesReadReserv,

AttribGroupsReadReserv, NodesReadAttribs,

NodesWriteAttribs, NodesPowerControl

Assign Roles to Users#

To assign roles when a new account is created, use the cw-adminctl tool with a comma-separated list of roles:

cw-adminctl create name=charlie roles=ImagingEngineer,OnsiteEngineer

To assign roles after an account has been created, update the admin record with the new list of roles:

cw-adminctl -icharlie update roles=Manager

Modifying the Role-Permissions Mapping#

Caution

Admins are strongly encouraged to work with Penguin Computing staff when looking to modify the role-to-permissions mapping since misconfiguration could lead to non-functioning cluster head nodes.

The role-to-permissions mapping is stored in a configuration file on the head nodes -- /opt/scyld/clusterware/src/cw_common/files/roles.ini. This is a standard INI file format with only one section named "Roles". Within that section, admins can define one or more role using lines like:

role_name = permission1, permission2

Alternately, permissions can be listed one per line (without commas).

All roles automatically have all Read permissions to all primitive types. The Authenticated User and Full Admin roles are always pre-defined and do not need to be manually created. An example file might include:

[Roles]
# custom On-site engineer that adds exec and power-control
MyOnsiteEngineer = NodesPowerControl
                   NodesWrite
                   NodesExecCommand
                   NetworksWrite

Once the roles.ini file has been modified, it must be copied to every head node in the cluster and must overwrite the current /opt/scyld/clusterware/src/cw_common/files/roles.ini file. Once all head nodes have the new file, restart the clusterware service on every head node for the changes to take effect. To avoid any disruption in cluster services, restart the clusterware service on one head node at a time, waiting for it to become fully operational before issuing the restart on the next head node.

Note

The ClusterWareAI platform may change how these configuration settings are stored in the future. The roles.ini file may be deprecated in favor of storing the values in the main ClusterWareAI database.

System Roles#

System roles are internal accounts used by the ClusterWareAI software to complete specific tasks. System roles should not have any associated users and are not shown by default when listing user roles. You should not modify these roles without contacting Penguin Computing.

  • The sys-ars system role has the permissions required by the Auto Remediation Service (ARS) to take action on compute nodes, view attributes, and so on.

  • The sys-ai system role is used by the AI Factory Operations Agent to access the ClusterWareAI API and get information about the cluster.

Use cw-adminctl ls --show-sys or the Role Mapping page of the ClusterWareAI GUI to view system roles.

Role

Permission Set

sys-ars

NodesRead, NodesReadAttribs, NodesReadReserv,

StateMapsRead, StateMapsActivate, NodesExecCommand,

NodesWrite, NodesWriteAttribs, NodesWriteReserv,

NodesPowerControl, ProvidersRead

sys-ai

AdminsRead, AttribGroupsRead, AttribGroupsReadReserv,

BootConfigsRead, CertsRead, ActionsRead,

HealthChecksRead, DistrosRead, DynGroupsRead,

GitReposRead, HeadsRead, HostnamesRead, ImagesRead,

NamingPoolsRead, IbnetsRead, NetworksRead,

NodesRead, NodesReadAttribs, NodesReadReserv,

SwitchesRead, SwitchesReadAttribs,

SwitchesReadReserv, RegistryRead, ReposRead,

StateMapsRead, ClusterRead, RemediesRead,

ProvidersRead, MultitenancyRead, RacksRead,

TenantsRead, TenantsReadSelf, TenanciesRead,

TenanciesReadSelf

Multi-Tenant Token Roles#

In addition to the user roles listed above, multi-tenant clusters have tenant and tenancy token roles: TenancyTokenRead, TenancyTokenWrite, TenantTokenRead, TenantTokenWrite. These roles are created automatically and are used to validate the tenant or tenancy when they attempt actions controlled by the super-cluster, such as power control. These roles are used to make sure a tenant or tenancy can only take action on itself and not other tenants or tenancies.

Tenants, tenancies, and other features are available if you have paid for multi-tenant support. Contact Penguin Computing to learn more.