Skip to content

Setup Project-based Researcher Access Control


By default, Run:AI is configured to allow all Researchers access to all Jobs and Projects. This document provides step-by-step instructions on how to enable access control. Run:AI access control is at the Project level. When you assign Users to Projects - only these users are allowed to submit Jobs and access Jobs details.

This document explains how to set up Researcher Authentication in an Air-gapped or connected environment where the Run:AI backend is installed on the customer's cluster. The process for the cloud-based Run:AI is detailed here.


The Air-gapped/Connected version of Run:AI uses an Identity Provider called Keycloak.


See the Prerequisites section for the creation of a DNS entry admin.runai.<company-name>.

How it works

The Run:AI command-line interface uses a Kubernetes configuration file residing on a client machine. The configuration file contains information on how to access the Kubernetes cluster and hence the Run:AI

Authentication setup works as follows:

  • Administration User Interface Setup. Enable the feature.
  • Client-side: Modify the Kubernetes configuration file to prompt for credentials.
  • Server-side: Modify the Kubernetes cluster to validate credentials against the Run:AI Authentication authority.
  • Assign Users to Projects using the Run:AI Administration UI. See here.

Administration User Interface Setup

Enable Researcher Authentication

Under admin.runai.<company-name>/general-settings settings, enable the flag Researcher Authentication.

Assign Users to Projects

Assign Researchers to Projects:

  • Under admin.runai.<company-name>/users add a Researcher and assign it with a Researcher role.
  • Under admin.runai.<company-name>/projects, edit or create a Project. Use the Users tab to assign the Researcher to the Project.

Client Side

To control access to Run:AI (and Kubernetes) resources, you must modify the Kubernetes configuration file. The file is distributed to users as part of the Command-line interface installation.

When making changes to the file, keep a copy of the original file to be used for cluster administration. After making the modifications, distribute the modified file to Researchers.

Under the ~/.kube directory edit the config file, and add the following:

- name: runai-authenticated-user
        airgapped: "true"
        auth-flow: cli
        realm: runai
        client-id: runai
        idp-issuer-url: https://auth.runai.<company-name>/auth/realms/runai
      name: oidc

Under contexts | context | user change the user to runai-authenticated-user

You must distribute the modified certificate to Researchers.

Server Side

Locate the Kubernetes API Server configuration file. The file's location may defer between different Kubernetes distributions. The default location is /etc/kubernetes/manifests/kube-apiserver.yaml

Edit the document to add the following parameters at the end of the existing command list:

  - command:
    - --oidc-client-id=runai
    - --oidc-issuer-url=https://auth.runai.<company-name>/auth/realms/runai
    - --oidc-username-prefix=-
    - --oidc-groups-claim=email

Verify that the kube-apiserver-<master-node-name> pod in the kube-system namespace has been restarted and that changes have been incorporated. Run:

kubectl get pods -n kube-system kube-apiserver-<master-node-name> -o yaml

And search for the above oidc flags.

Edit Rancher cluster.yml (with Rancher UI, follow this). Add the following:

      always_pull_images: false
        oidc-client-id: runai
        oidc-groups-claim: email
        oidc-issuer-url: 'https://auth.runai.<company-name>/auth/realms/runai'
        oidc-username-prefix: '-'

You can verify that the flags have been incorporated into the RKE cluster by following the instructions here and running docker inspect <kube-api-server-container-id>, where <kube-api-server-container-id> is the container ID of api-server via obtained in the Rancher document.


  • Run: runai login
  • You will be prompted for a username and password.
  • Once login is successful, submit a Job.
  • If the Job was submitted with a Project for which you have no access, your access will be denied.
  • If the Job was submitted with a Project for which you have access, your access will be granted.

Last update: October 6, 2021