Skip to main content

Access Control

When using cirun.io in an organization, quite often you need the ability to control access to runners per repository to control usage, cost and availability. Cirun provides a way to access control runners via the following mechanism:

You'd create a repository named .cirun in your organization and create a couple of config files to control access.

1. .cirun.global.yml​

This is the file where you'd define all the runner configurations you'd want to use in the organization. The format of this file is same as .cirun.yml, for example:

runners:
  - name: gpu-runner
    cloud: openstack
    instance_type: gpu_large
    machine_image: ubuntu-2204-nvidia-docker-20221229
    region: RegionOne
    labels:
      - cirun-openstack-gpu
      - openstack-gpu-runner

  - name: cpu-runner
    cloud: openstack
    instance_type: ci_medium
    machine_image: ubuntu-2204-cloud-jammy-20221104
    region: RegionOne
    labels:
      - cirun-cpu-runner
      - openstack-cpu-runner

  - name: aws-runner
    cloud: aws
    instance_type: t2.medium
    machine_image: ami-06fd8a495a537da8b
    preemptible: true
    labels:
      - cirun-runner

2. .access.yml​

This is the file, where you'd define the rules for access control. Let's take an example to understand how it works:

version: 1

policies:
  - id: cirun-sandbox-policy
    repo: cirun-sandbox
    teams:
      - core
      - alpha
      - beta
  - id: cirun-demo-repo-policy
    repo: cirun-demo
    teams:
      - core
      - demo

access_control:
  - resource: gpu-runner
    policies:
      - cirun-demo-repo-policy
  - resource: cpu-runner
    policies:
      - cirun-sandbox-policy
      - cirun-demo-repo-policy
  - resource: aws-runner
    policies:
      - cirun-demo-repo-policy
      - cirun-sandbox-policy

Let's try to understand this configuration:

  • policies: A policy is a set of a repository and teams.
  • access_control: Access control defines which policies have access to resource.

To simplify which combination of repository and teams have access to a resource. In other words, if there is an event of a workflow job and that requires cirun to spinup a resource (runner), it will only spinup a runner if that workflow job was triggered by a member of the given team on a given repository in a policy defined on that resource.

From the above example:​

If a workflow job is triggered on aktechlabs/cirun-demo and it requests the resource gpu-runner, then it must have been triggered by a member of demo or core teams to be authorized get a gpu-runner.

API Client​

There is an API client to manage the .access.yml file programmatically as well. https://github.com/AktechLabs/cirun-py