Roles
This article explains the available roles in the Run:ai platform.
A role is a set of permissions that can be assigned to a subject in a scope.
A permission is a set of actions (View, Edit, Create and Delete) over a Run:ai entity (e.g. projects, workloads, users).Roles table
The Roles table can be found under Tools & Settings in the Run:ai platform.
The Roles table displays a list of predefined roles available to users in the Run:ai platform. It is not possible to create additional rules or edit or delete existing rules.
The Roles table consists of the following columns:
Column | Description |
---|---|
Role | The name of the role |
Created by | The name of the role creator |
Creation time | The timestamp when the role was created |
Customizing the table view¶
- Filter - Click ADD FILTER, select the column to filter by, and enter the filter values
- Search - Click SEARCH and type the value to search by
- Sort - Click each column header to sort by
- Column selection - Click COLUMNS and select the columns to display in the table
- Download table - Click MORE and then Click Download as CSV
Reviewing a role¶
- To review a role click the role name on the table
- In the role form review the following:
- Role name
The name of the role - Entity
A system-managed object that can be viewed, edited, created or deleted by a user based on their assigned role and scope - Actions
The actions that the role assignee is authorized to perform for each entity- View If checked, an assigned user with this role can view instances of this type of entity within their defined scope
- Edit If checked, an assigned user with this role can change the settings of an instance of this type of entity within their defined scope
- Create If checked, an assigned user with this role can create new instances of this type of entity within their defined scope
- Delete If checked, an assigned user with this role can delete instances of this type of entity within their defined scope
- Role name
Roles in Run:ai¶
Run:ai supports the following roles and their permissions:
Under each role is a detailed list of the actions that the role assignee is authorized to perform for each entity.
Notes
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 backwards 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 backwards compatibility, users with the role of 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.
Permitted workloads¶
When assigning a role with either one, all or any combination of the View, Edit, Create and Delete permissions for workloads, the subject has permissions to manage not only Run:ai native workloads (Workspace, Training, Inference), but also a list of 3rd party workloads:
- k8s: StatefulSet
- k8s: ReplicaSet
- k8s: Pod
- k8s: Deployment
- batch: Job
- batch: CronJob
- machinelearning.seldon.io: SeldonDeployment
- kubevirt.io: VirtualMachineInstance
- kubeflow.org: TFJob
- kubeflow.org: PyTorchJob
- kubeflow.org: XGBoostJob
- kubeflow.org: MPIJob
- kubeflow.org: MPIJob
- kubeflow.org: Notebook
- kubeflow.org: ScheduledWorkflow
- amlarc.azureml.com: AmlJob
- serving.knative.dev: Service
- workspace.devfile.io: DevWorkspace
- ray.io: RayCluster
- ray.io: RayJob
- ray.io: RayService
- ray.io: RayCluster
- ray.io: RayJob
- ray.io: RayService
- tekton.dev: TaskRun
- tekton.dev: PipelineRun
- argoproj.io: Workflow
Using API¶
Go to the Roles API reference to view the available actions.