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.
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:
- name: gpu-runner
- name: cpu-runner
- name: aws-runner
This is the file, where you'd define the rules for access control. Let's take an example to understand how it works:
- id: cirun-sandbox-policy
- id: cirun-demo-repo-policy
- resource: gpu-runner
- resource: cpu-runner
- resource: aws-runner
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
then it must have been triggered by a member of
core teams to be authorized get a
There is an API client to manage the
.access.yml file programmatically as well.