Role based access control¶

User authorization to system resources and entities is managed using Role-based access control (RBAC). RBAC is a policy-neutral access control mechanism defined around roles and privileges. The components of RBAC make it simple to manage access to system resources and entities.

RBAC components¶

Run:ai uses the following components for RBAC:

Subjects¶

A Subject is an entity that receives the rule. Subjects are:

Users
Applications
Groups (For tenants that use SSO authentication)

Roles¶

A role is a group of permissions that can be granted. Permissions are a set of actions that can be applied to entities. Run:ai supports the following roles:

Role	Description
Environment administrator	Create, view, edit, and delete Environments. View Jobs, Workspaces, Dashboards, Data sources, Compute resources, and Templates.
Credentials administrator	Create view, edit, and delete Credentials. View Jobs, Workspaces, Dashboards, Data sources, Compute resources, Templates*, and environments.
Data source administrator	Create, view, edit, and delete Data sources. View Jobs, Workspaces, Dashboards, Environments, Compute resources, and Templates.
Compute resource administrator	Create, view, edit, and delete Compute resources. View Jobs, Workspaces, Dashboards, Environments, Data sources, and Templates.
System administrator	Controls all aspects of the system. This role has global system control and should be limited to a small group of skilled IT administrators.
Department administrator	Create, view, edit, and delete: Departments and Projects. Assign Roles (Researcher, ML engineer, Research manager, Viewer) within those departments and projects. View Dashboards (including the Consumption dashboard).
Editor	View Screens and Dashboards Manage Departments and Projects.
Research manager	Create, view, edit, and delete: Environments, Data sources, Compute resources, and Templates. View Projects, related Jobs and Workspaces, and Dashboards.
L1 researcher	Create, view, edit, and delete Jobs, Workspaces, Environments, Data sources, Compute resources, Templates, Deployments. View Dashboards.
ML engineer	Create, edit, view, and delete Deployments. View Departments, Projects, Clusters, Node-pools, Nodes, Dashboards.
Viewer	View Departments, Projects, Respective subordinates (Jobs, Deployments, Workspaces, Environments, Data sources, Compute resources, Templates), Dashboards. A viewer cannot edit Configurations.
L2 researcher	Create, view, edit, and delete Jobs, Workspaces. An L2 researcher cannot create, edit, or delete Environments, Data sources, Compute resources, and Templates.
Template administrator	Create, view, edit, and delete Templates. View Jobs, Workspaces, Dashboards, Environments, Compute resources, and Data sources.
Department viewer	View Departments, Projects, assigned subordinates (Jobs, Deployments, Workspaces, Environments, Data sources, Compute resources, Templates), and Dashboards.

Note

Keep the following in mind when upgrading from versions 2.13 or earlier:

Admin becomes System Admin with full access to all managed objects and scopes.
Research Manager is not automatically assigned to all projects but to Projects set by the relevant Admin when assigning this role to a user, group, or app.
To preserve backward compatibility, users with the role of Research Manager are assigned to all current projects, but not to new projects.
To allow the Department Admin to assign a Researcher role to a user, group, or app, the Department Admin must have VECD permissions for Jobs and Workspaces. This creates a broader span of managed objects.
To preserve backward compatibility, users with the role Editor, are assigned to the same scope they had before the upgrade. However, with new user assignments, the Admin can limit the scope to only part of the organizational scope.

Scope¶

A Scope is an organizational component which accessible based on assigned roles. Scopes include:

Projects
Departments
Clusters
Tenant (all clusters)

Asset¶

RBAC uses rules to ensure that only authorized users or applications can gain access to system entities. entities that can have RBAC rules applied are:

Departments
Projects
Deployments
Workspaces
Environments
Quota management dashboard
Training

RBAC enforcement¶

RBAC ensures that user have access to system entities based on the rules that are applied to those entities. Should an asset be part of a larger scope of entities to which the user does not have access. The scope shown to the user will appear to be incomplete because the user is able to access only the entities to which they are authorized.

Access rules¶

An Access rule is the assignment of a Role to a Subject in a Scope. Access rules are expressed as follows:

<subject> is a <role> in a <scope>.

For example:
User [email protected] is a department admin in Department A.

Access Rules Table¶

The Access Rules table provides a list of subjects (users, SSO groups, applications) that have been assigned access to the platform. Use Add filter to add one or more filter results based on the columns that are in the table. In the Contains pane, you can use partial or complete text. Filtered text is not case sensitive. To remove the filter, press X next to the filter.

The table contains the following columns:

Type—the type of subject assigned to the access rule (User, SSO group, or Application).
Subject—the user, SSO group, or application id of the subject with role assignments.
Role—the name of the role assigned to the user.
Scope—the scope to which the user has rights. Press the name of the scope to see the scope and related children.
Authorized by—the user who granted the access rule.
Creation time—the timestamp for when the rule was created.
Last updated—the last time the rule information was updated.

Create or delete rules¶

To create a new access rule:

Press the icon, then Access rules & Roles.
Choose the ACCESS RULES tab, then press NEW ACCESS RULE.
Select a subject type from the dropdown. Choose from:
1. User—a user that has been created in the platform, or a known SSO user listed in your IDP. Enter an email address to select a user.
2. SSO Group—a known group listed in your IDP server.
Note

To add SSO users and groups, you must enter a user id, or group id that is recognized by the configured IDP.
1. Application—an application that has been created in the platform.
Select a [Role] from the dropdown.
Press the icon and select a scope, and press SAVE RULE when done.

Note

You cannot edit access rules. To change an access rules, you need to delete the rule, then create a new rule to replace it. You can also add multiple rules for the same user.

To delete a rule:

Press the icon, then Roles and Access rules.
Choose Access rules, then select a rule and press Delete.