Guideline of best practices to follow to use Github Self-Hosted Runners in a secure way.
Report an issue
- About the project
- Confidentiality
- Integrity
- Availability
- Authentication
- Authorization
- Audit
- Checklist
- Support section
- Contributing
- License
- Contact
Looking for a guideline to configure your GitHub Self-Hosted Runners in a secure way?
Here is a 🔥 list of things to do!
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.
Restrict the use of self-hosted runners to specific repositories only.
https://docs.github.com/en/free-pro-team@latest/actions/hosting-your-own-runners/managing-access-to-self-hosted-runners-using-groups
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.
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.
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.
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/
Ensure that the host machine always uses the latest version of the self-hosted runner.
https://github.com/actions/runner/releases/latest
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.
Since self-hosted runners are essential to talk with the internal network of an enterprise, they need to be highly available.
https://github.com/philips-labs/terraform-aws-github-runner
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.
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.
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.
- Using self-hosted runners only in trusted GitHub Actions
- Limit access to self-hosted runners
- Disable forks
- Enabling branch protections
- Run the self-hosted runner on hardened hosts only
- Use the latest and greatest runner
- High Availability
- Automatically clear and remove workspaces
- Secure the authentication token of the self-hosted runner
- Only use the technologies you need
Github Enterprise Support offers very usefull assistance on everything you search. 👍
Also, GitHub offers a Premium Support with a 24/7 hours of operation availability time.
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.
- Fork the Project
- Create your Feature Branch (
git checkout -b feature/AmazingFeature) - Commit your Changes (
git add . && git commit -m 'Add some AmazingFeature') - Push to the Branch (
git push origin feature/AmazingFeature) - Open a Pull Request
Distributed under the MIT License. See LICENSE.txt for more information.