README.md

Guideline of best practices to follow to use Github Self-Hosted Runners in a secure way.

Report an issue

Looking for a guideline to configure your GitHub Self-Hosted Runners in a secure way?

Using self-hosted runners only in trusted GitHub Actions

Self-hosted runners are using the dedicated host as the runner. Only verified GitHub Actions must use self-hosted runners to reduce the use of a potential malicious open-source GitHub Action that might access our private network.

Limit access to self-hosted runners

Disable forks

Disable forks since forks of your public repository can potentially run dangerous code on your self-hosted runner machine by creating a pull request that executes the code in a workflow.

Enabling branch protections

Obviously, we don't want anyone to add changes to a GitHub Action. A great way to have more control over your GitHub Actions is to create branch protection on your repositories. Having a mandatory approver to a PR will reduce the chances of someone trying to force push code changed.

Do not store secrets in the host runner

When a GitHub Action uses the self-hosted runner, it clones the code in a workdir _work.
We must ensure that no secrets (application, system, ..) are accessible in this folder.

Run the self-hosted runner on hardened hosts only

The host of the self-hosted runner must be a hardened OS. Hardening of the OS is the act of configuring an OS securely, updating it, creating rules and policies to help govern the system in a secure manner, and removing unnecessary applications and services. This is done to minimize a computer OS's exposure to threats and to mitigate possible risk.
https://www.cisecurity.org/cis-benchmarks/

Integrity

Use the latest and greatest runner

Tip

If it works with your GitHub Actions workflows, consider using a rootless dind action runner provided by GitHub as a base self-hosted runner image.

Availability

High availability

Automatically clear and remove workspaces

Since the self-hosted runner clones the source code in a workspace, we need to ensure that this workspace doesn't get overpopulated and consumes all the available space of the host.

Authentication

Secure the authentication token of the self-hosted runner

The authentication token used to configure the runner needs to be secured and restricted since it has write-access permissions on the repository.
Using Hashicorp Vault may be a good solution for this.

Authorization

Only use the technologies you need

Keep the self-hosted runner simple and authorize only the things you need. For example, if you don't need npm don't install it inside the runner.

Audit

Checklist

Support section

Also, GitHub offers a Premium Support with a 24/7 hours of operation availability time.

Contributing

Contributions are what make the open source community such an amazing place to be learn, inspire, and create. Any contributions you make are greatly appreciated.