Role-Based Access Controls#

Note

The ICE ClusterWare™ system supports the Keycloak authentication system that may be helpful in linking to existing enterprise identity management systems. For more info, see Integrating Keycloak with ICE ClusterWare for RBAC

Prior to version 12.2.0, the ClusterWare platform only had the concept of an "admin" who could perform any action on any of the ClusterWare database entries. The ClusterWare platform now has Role-Based Access Controls (RBAC) to allow different "classes" of administrators, some of whom may have signicantly reduced sets of actions that they may perform. There are 6 system-provided Roles plus a "No Access" pseudo-role, described below. A given admin user can be assigned one or more Roles, with each Role granting a specific set of Permissions (roles are additive; if one role grants a permission, then, in general, another role cannot remove it).

By default, the first admin user added to the system will be assigned to the "Full Admin" Role and thereby gain permission to take any action within the system. When creating additional admin users, by default, they will inherit the same roles as their creator. This means that a Full Admin will create other Full Admins - the same as the default on prior versions of the ClusterWare platform.

The current ClusterWare roles are:

  • Authenticated User

    • Any admin account will have this role which simply grants read-only access to the system. Auth-Users can read nearly any object in the ClusterWare database, with the exception of reserved attributes. This role may be useful for admins who need to report on cluster status and configuration, or perhaps for "power users" who may have some knowledge of cluster operations but should not be able to modify or change the configuration.

  • Onsite Engineer

    • The Onsite Engineer role is aimed at technical staff who may need to interact with the machines physically, e.g. to power on/off the machines, or to rack/unrack the machines. In addition to the “read” permissions from Auth-User, the Onsite Engineer is able to issue power-control commands through scyld-nodectl, and to write/update node information.

  • Imaging Engineer

    • The Imaging Engineer is primarily responsible for the creation of new images or modification of existing ones. To better assist them in that role, they are also given permissions to read reserved attributes (to see what nodes are booting into what images).

  • Production Engineer

    • For most day-to-day operations, the Production Engineer role might be the most useful. It grants several permissions: to update/modify nodes, including power-control functionality; to update regular and reserved attributes; to create/modify images and boot configs; to create/modify naming pools; and to create/modify git repositories.

  • Manager

    • In addition to the Auth-User (read-only) permissions, a Manager can create new admins in the system and view reserved attributes. This role may be useful in larger organizations where the creation and removal of admin accounts could be managed by less technical staff.

  • Full Admin

    • The Full Admin role grants all possible permissions to the admin so they can read/write any object, do full power-control on nodes, update, or delete any object, etc.

    • Permissions that are only granted to Full Admins: control over distros and repos; control over dynamic groups and state sets; control over head nodes; control over hostnames and networks; and control over the cluster configuration itself.

  • No Access

    • While not a "role" per se, the ClusterWare platform uses the No Access pseudo-role to enforce a block on an account. If an admin has the No Access role, then they will not be able to perform any actions, regardless of any other role they may have.

    • It is certainly best practice to remove such blocked accounts from the ClusterWare platform entirely, and to also remove them from any authentication system that feeds the software (such as Keycloak). However, it is sometimes helpful to have "helper" accounts that can be enabled and disabled quickly. For example, in larger sites, there may be contractors or vendor support staff that need access to a system to help with a problem; but when the problem is resolved, those accounts can be deactivated with the "No Access" role but left in-place in case another support event arises later.

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

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

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

scyld-adminctl -isally update roles=Manager

Note

For organizations not wishing to utilize RBAC, simply assign every admin user to the "Full Admin" Role; this is the default and will then mimic the behavior of previous ClusterWare versions.

For more information, including a full description of the Roles and Permissions, see Role-Based Access Control System.