User authorization to system resources and entities is managed using Role-based access control (RBAC){target=_blank}. 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.
Run:ai uses the following components for RBAC:
A Subject is an entity that receives the rule. Subjects are:
- Users
- Applications
- Groups (For tenants that use SSO authentication)
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, Projects and Data Volumes (including sharing). Assign Roles (Researcher, ML engineer, Research manager, Viewer) within those departments and projects. View Dashboards (including the *Consumption dashboard). |
| Data Volumes administrator | Create, view, edit, and delete: Data Volumes, Data Volumes sharing list View: Account, Department,Project, Jobs, Workloads, Cluster, Overview dashboard, Consumption dashboard, Analytics dashboard, Policies, Workloads, Workspaces, Trainings, Environments, Compute resources, Templates, Data source, Inferences |
| Editor | View Screens and Dashboards Manage Departments and Projects. Create: Data Volumes |
| Research manager | Create, view, edit, and delete: Environments, Data sources, Compute resources, Templates, Data Volumes (including sharing), and Projects View related Jobs and Workspaces, and Dashboards. |
| L1 researcher | Create, view, edit, and delete Jobs, Workspaces, Environments, Data sources, Compute resources, Templates and Data Volumes. View Dashboards. |
| ML engineer | Create, edit, view, and delete Deployments. View Departments, Projects, Clusters, Node-pools, Nodes, Dashboards and Data Volumes. |
| Viewer | View Departments, Projects, Respective subordinates (Jobs, Deployments, Workspaces, Environments, Data sources, Compute resources, Templates), Dashboards and Data Volumes. 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. View: Data Volumes |
| 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),Dashboards and Data Volumes (including sharing). |
!!! Note Keep the following in mind when upgrading from versions 2.13 or earlier:
1. *Admin* becomes *System Admin* with full access to all managed objects and scopes.
2. *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.
3. To preserve backward compatibility, users with the role of *Research Manager* are assigned to all current projects, but not to new projects.
4. 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.
5. 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.
A Scope is an organizational component which accessible based on assigned roles. Scopes include:
- Projects
- Departments
- Clusters
- Tenant (all clusters)
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
- Inference
- Workspaces
- Environments
- Quota management dashboard
- Training
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.
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.
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.
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:
- 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.
- 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.
- 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.