Role-Based Access Control System¶

As described in rbac_intro, the ClusterWare Role-Based Access Control system has 6 primary roles plus the "No Access" pseudo-role. A role is a set of 1 or more permissions, usually grouped according to an employee's job-related needs. E.g. 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. ClusterWare ships with a set of default roles, but admins can also create new roles or modify the existing ones.

Permissions¶

Every database object type has at least a Read and Write permission, and many have additional permissions specific to that object type. As an example, the Boot Configs-Read permission which 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.

Object Type	Permissions
Admin	AdminsRead	AdminsWrite
Attributes Groups	AttribGroupsRead AttribGroupsReadReserv	AttribGroupsWrite AttribGroupsWriteReserv
Boot Configs	BootConfigsRead	BootConfigsWrite
Certificates	CertsRead	CertsWrite
Distros	DistrosRead	DistrosWrite
Dynamic Groups	DynGroupsRead	DynGroupsWrite
Git Repos	GitReposRead	GitReposWrite
Head Nodes	HeadsRead	HeadsWrite
Hostnames	HostnamesRead	HostnamesWrite
Images	ImagesRead	ImagesWrite
Naming Pools	NamingPoolsRead	NamingPoolsWrite
Networks	NetworksRead	NetworksWrite
Nodes	NodesRead NodesExecCommand NodesReadReserv NodesWriteGroups	NodesWrite NodesPowerControl NodesWriteReserv
Repos	ReposRead	ReposWrite
State Sets	StateSetsRead	StateSetsWrite

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

Nodes and Attribute Groups have ReadReserv and WriteReserv permissions which allow reading/writing of the reserved attributes, including those attributes that control how the nodes boot (see Reserved Attributes).
Nodes have an additional permission to allow execution of code and ssh access, NodesExecCommand, and another one to allow power control through the BMC or IPMI, NodesPowerControl.
Nodes also have NodesWriteGroups to allow changing which group(s) a given node is joined to (this permission allows addition and removal of groups).

Roles¶

The default set of roles provided by ClusterWare 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.

Note

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

Role	Permission Set
AuthUser	all Read permissions for all Object types
FullAdmin	all Read and Write permissions for all Object types; all special permissions for all Object types
NoAccess	all permissions are revoked; account is blocked
ImagingEngineer	all Read permissions for all Object types, plus: ImagesWrite, NodesReadReserv, AttribGroupsReadReserv
Manager	all Read permissions for all Object types, plus: AdminsWrite, NodesReadReserv, AttribGroupsReadReserv
OnsiteEngineer	all Read permissions for all Object types, plus: NodesPowerControl, NodesWrite
ProductionEngineer	all Read permissions for all Object types, plus: AttribGroupsReadReserv, AttribGroupsWriteReserv NodesWrite, NodesWriteGroups, NodesWriteReserv, NodesPowerControl, AttribGroupsWrite, ImagesWrite NamingPoolsWrite, BootConfigsWrite, GitReposWrite, NodesPowerControl

Modifying the Role-Permissions Mapping¶

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).

Note that all roles automatically have all Read permissions to all object types, and 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, ClusterWare must be restarted on every head node. To avoid any disruption in cluster services, admins should restart ClusterWare on one head node at a time, waiting for it to become fully operational before issuing the restart on the next head node.

Note

ClusterWare 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 ClusterWare database.

Note

Admins are strongly encouraged to work with ClusterWare staff when looking to modify this file since misconfiguration could lead to non-functioning cluster head nodes.