Security

RunsOn handles security very differently from competitors or alternative ways of self-hosting runners:

• only ephemeral, fully-isolated VMs, so that nothing can leak from workflow to workflow.
• application, code, secrets, and runners stay in your AWS account.
• special care to only issue the most restrictive set of IAM permissions to the RunsOn application, and runners.
• regularly updated application (part of why we ask for a subscription).

The problem with self-hosted runners

People looking for cheaper or faster runners often choose one of the following routes:

1. keep using GitHub official runners. Pay premium price, and have limited access to more powerful runners. Perfect until you start hitting 10min+ workflow times and your developers suffer.

2. switch to a third-party SaaS tool like BuildJet or Warpbuild to get cheaper and more powerful self-hosted runners. It’s only 2x cheaper though, and might be slower for some workloads that require fast bandwidth. On top of that you are relinquishing access to some of your most precious assets:

   • your source code ;
   • github action secrets, which often include privileged access to artefact repositories, cloud providers, or even other github repositories.

3. maintain a pool of self-hosted runners: problem is that those are often permanent and require constant patching, as well as introducing huge attack ↗ vectors ↗, especially on public repositories.

A strong design rule of RunsOn is that it always spawns a new runner for each workflow run (what is called “ephemeral runners”), so that you can be certain that nothing can leak into subsequent workflow runs.

And since RunsOn and its runners all live in your own AWS account, your code and secrets never leave your infrastructure.

SSH access to the runners can also be restricted to a specific CIDR block, or simply disabled.

How RunsOn handles security

Public base images (AMI)

RunsOn maintains public AMIs for the base images used by the runners, in each region where RunsOn is officially available. These images are built from this repository ↗ and are updated regularly, within 48h of an official new release by GitHub.

If you want to ensure the maximum supply chain security, you can build your own images from the provided templates, or generate entirely custom AMIs.

RunsOn server (AppRunner)

The server is a deployed from a docker image built by RunsOn, available in a public ECR registry (public.ecr.aws/c5h5o9k1/runs-on/runs-on). The server container runs in your own AWS account, using the AppRunner AWS service.

• For v1, the source code is fully available in the public repository ↗, and the only functionality that talks to RunsOn servers is the license check ↗. This check executes again an API endpoint that I control, and receives the org name, license key, app version, and region.

• For v2, the source code for the Server component is only available if you buy a Sponsorship license. The only functionality that talks to RunsOn servers is still the license check.

RunsOn agent (EC2 instance)

Since v2, an agent lives on the EC2 instances launched by the server (either launched by the base AMI if preinstalled, or downloaded at runtime if not present). This ensures faster boot times for workflow jobs, and simplifies metadata generation in logs, spot interruption detection, and more generally the overall handling of the workflow job on the runner.

This agent has a telemetry functionality: on every job start, it sends a request to an API endpoint that I control, with:

• the time of execution
• org name
• app version
• architecture
• instance type
• region

This is used to understand how users are using the product, and in the near future to display some kind of ~live counter to brag about of how many jobs have been executed by RunsOn.

The source code for the Agent component is only available to Sponsorship licenses.

Vector attacks for RunsOn, and remediations

Supply chain security in software is important, and below are the risks and measures you can take to remediate them:

• malicious code injected into the base AMIs, by either RunsOn or upstream GitHub: can be remediated by either auditing the published AMIs, or building your own from the provided templates (using packer tool).

• malicious code injected into the server component: can be remediated by either auditing the source code, published docker images, or building your own docker image from the source code and updating the CloudFormation template to point at it.

• malicious code injected into the agent component (v2 only): can be remediated by either auditing the source code, published docker images, or building your own docker image from the source code and updating the base AMIs and CloudFormation template to point at it.

• malicious code injected into the runs-on.com API components for license check and telemetry: those endpoints are append-only. Telemetry response is discarded. License response is only used to update the license status in the server logs and emails sent to the ops team of the client.

• server endpoint compromised by third-party: by design, the server endpoint is exposed to the internet since it needs to receive webhooks from GitHub. This service is managed by AppRunner, with an AWS-managed load-balancer (envoy) in front. RunsOn ensures that the component is regularly updated with the latest security patches, and provide upgrades for the users to apply. This endpoint also runs with a limited set of IAM Permissions, so that in the case of a compromise, the damage is limited to API calls authorized to the server. A default CloudWatch alarm is also enabled, which will immediately alert you if usage is higher than a configurable threshold.

Conclusion

We hope this overview clarifies how RunsOn approaches security and the measures in place to protect your infrastructure and workflows. If anything in this documentation seems unclear or you notice any discrepancies, please don’t hesitate to reach out by sending an email to our operations team: [email protected].