Roles

A Role is a named entity that has an associated set of permissions. Roles can be associated with users or groups.

A Permission associated with a role consists of a string defining the object or objects that the permission applies to, and the name of an action that is being permitted.

A role typically has one or more permission rules associated with it. Each permission rule consists of an action string pattern and an object string pattern, as well as a resulting effect, either Allow or Deny.

A role bound to a user or group can apply to a specific namespace or all namespaces.

• If a role is bound to a specific namespace, the permissions only have an effect for access control requests that explicitly reference that namespace.
• If a role is bound to all namespaces, then the permissions have an effect on any access control request, regardless of the namespace it specifies.
  This includes access control requests that specify no namespace, including access control requests for non-namespaced entities such as Users and Groups.

The Roles page displays a list of current Altair SLC Hub roles.

The page can be used to create new roles by clicking the New button. Existing roles can be modified by clicking the displayed name. This opens the the Edit Role pages. Clicking the more (...) button at the end of the role row enables the role to be deleted, renamed or duplicated.

Built-in roles

Altair SLC Hub contains the following built-in roles that were added with the move to Keycloak authentication. These roles separate administrative responsibilities to provide more granular access control and improve security.

Admin

Provides full management permission in Altair SLC Hub. This role replaces the broad responsibilities previously associated with HubAdministrator.

Users with the Admin role can perform any action in Altair SLC Hub.

Do Not Bind Admin Role to Groups

Never bind the Admin role to a group. Always assign it directly to individual users or service accounts only.

If you bind Admin to a group, any user with the UserManager role can add themselves to that group and gain full administrative access to Altair SLC Hub, bypassing your intended access controls. This is a privilege escalation vulnerability.

RealmAdmin (Keycloak realm role, not a Altair SLC Hub role)

RealmAdmin is a Keycloak realm role, not a Altair SLC Hub RBAC role. It does not appear on the Roles page and cannot be bound to Altair SLC Hub users or groups from the portal.

It grants access to the Keycloak Admin Console for the realm used by Altair SLC Hub, allowing configuration of:

• Identity providers (LDAP, SAML, OIDC)
• User federation and synchronization
• User and group management in Keycloak itself
• Authentication policies and security settings

The bootstrap admin user created with hubctl admin create is automatically granted this Keycloak role, in addition to the Altair SLC Hub Admin role. There is currently no way to grant the RealmAdmin Keycloak role to additional users from the portal; it must be assigned directly in Keycloak.

UserManager

Provides user and group management capabilities in Altair SLC Hub, including:

• Adding, editing, and deleting local users
• Adding, editing, and deleting local groups
• Sending user invites
• Resetting user passwords

Note

The UserManager role intentionally does not include the ability to modify sensitive user attributes such as:

• Email address
• Username (UPN)
• Unix username
• User password

This restriction is a security measure. If a user could modify these sensitive attributes, they could take control of another user's account and run jobs as that user. See Security considerations for group bindings below for more details.

Only users with the Admin role, or the Keycloak RealmAdmin realm role, can modify these sensitive attributes. For most organizations, only a small number of trusted administrators should have these roles.

HubAdministrator (removed)

The HubAdministrator role has been removed as part of the move to Keycloak.

If you are upgrading from a previous version: Users who previously had the HubAdministrator role will not automatically receive new roles. After upgrading, an administrator must explicitly assign new roles using the role names above.

Replacement roles:

• For full Altair SLC Hub administration: assign Admin
• For user and group management without sensitive attribute changes: assign UserManager

Role permissions

The Permissions tab in the Edit Role pages displays a list of all permissions associated with the currently selected role.

To add a new permission to the role, click New. Existing roles can be modified or deleted using the more (...) option.

Object

An access control request contains a string identifying the object on which the action is being performed. The defined object for the role can be:

• An exact path-like strings, for example, /Group/Developers or /Pipeline/DailyJobs/ManagementReport.
• An path-like expression that evaluates to one or more defined objects.
  For example, /Groups/* will apply this permission to all groups in the Groups object.

Matcher

A permission can define the object or objects to which the permission applies using a variety of matchers:

• Simple
• Doublestar
• Regular expression
• Hierarchy

Simple matcher

The object string can be specified as an exact string or as a wildcard. This is the default.

Some examples of object patterns:

Pattern	Description
/Groups/*	Matches /Groups/Developers, does not match /Groups
/Pipeline/*	Matches /Pipeline/DailyJobs and /Pipeline/DailyJobs/ManagementReport but not /Pipeline

Doublestar matcher

The doublestar matcher recognises that access control object strings are "file path like", that is, they are made up of a sequence of elements separated by forward slashes.

In the doublestar matcher, the following patterns can be used:

Pattern	Description
*	Matches any sequence of characters, not including the path separator (/)
/**/	Matches zero or more complete "directory" path elements
?	Matches a single character, not including the path separator (/)
[class]	Matches a single character in the given character class, not including the path separator (/)

• When specified, the doublestar pattern must be surrounded by path separators (/).
• To match any object string, specify the /**/* pattern.

The following character classes can be used:

Class	Description
[abc]	Matches a single character in the specified set.
[a-z]	Matches a single character in the specified range.
[!class] or [^class]	Matches a single character not in the given class.

Regular expression matcher

The syntax of the regular expressions accepted by the regular expression matcher is defined in RE2 syntax description.

The regular expression matcher matches the complete object string against the provided regular expression. That is, the matcher adds beginning of string and end of string anchors to the provided regular expression.

Hierarchy matcher

The hierarchy matcher recognises that access control object strings are "file path like", that is, they are made up of a sequence of elements separated by forward slashes.

The hierarchy matcher treats both the pattern string and the provided object string as path like strings. A match is retured if the object string is equal to, or a child path of the pattern string.

For example:

Pattern	Object string	Match
/Pipelines	/Pipelines	yes
/Pipelines	/Pipelines/Pipeline1	yes
/Pipelines/Folder	/Pipelines/Folder/Pipeline1	yes
/Pipelines/Folder	/Pipelines/Folder1/Pipeline1	no

Actions

An access control evaluation request contains a string giving the action that is being attempted. Action strings are conventionally single words. Each service defines its own set of action strings, but typical action strings are:

• Create
• Read
• Update
• Delete

Action specification

Permissions can define the actions to which the permission applies either as an exact string, or as a wildcard (*) that matches any action. The asterisk wildcard can be used and added to a string as suffix (for example. Read*) if a partial string match is required.

Effect

Specifies the outcome of an evaluation request for the role using the defined permission. The effect can be:

• Allow: A user to whom this role is attached can carry out the specified action against the identified object.
• Deny : A user to whom this role is attached is not permitted to perfom the specified action against the identified object.

For a permission rule to match the evaluation request, both the specified action and the object pattern have to match the evaluation request.

Role bindings

The Role Bindings tab in the Edit Role pages displays a list of the Altair SLC Hub users and groups associated to this role.

The list displays whether the binding applies to all namespaces or a specific namespace.

Security considerations for group bindings

Roles can be bound to either an individual user or a group. When a role is bound to a group, every current and future member of that group is granted the role's permissions. As a result, anyone who can add members to a group effectively controls what permissions those members receive, if the group has an elevated role bound to it.

This is particularly important for the built-in UserManager role, which is able to manage group membership as well as group metadata. This means:

• A user with the UserManager role can add themselves, or anyone else, as a member of any group, including a group that has Admin or another highly-privileged role bound to it. Doing so grants them that role's permissions.
• Adding permissions to a role that is already bound to a group immediately changes what every current member of that group is able to do.

Recommendations:

• Do not bind Admin, or any role with permissions to create/edit role bindings to groups. Users with the UserManager role can add themselves to groups and escalate their access to any role bound to that group. Only bind these roles directly to individual users or dedicated service accounts.
• Treat the UserManager role, and any custom role that can manage group membership, as a sensitive, admin-adjacent role. Assign it only to trusted administrators, and periodically review which groups exist and which roles are bound to them.
• Before adding permissions to an existing role, check the Role Bindings tab to see whether the role is bound to any groups, and consider the effect on all members of those groups.