Awesome
Table of contents
<!--ts-->- About the project
- Confidentiality
- Integrity
- Availability
- Authentication
- Authorization
- Audit
- Checklist
- Support section
- Contributing
- License
- Contact
About the project
Looking for a guideline to configure your GitHub Self-Hosted Runners in a secure way?
Here is a :fire: list of things to do!
<!-- CONFIDENTIALITY -->Confidentiality
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
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
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
Ensure that the host machine always uses the latest version of the self-hosted runner.
https://github.com/actions/runner/releases/latest
<!-- AVAILABILITY -->[!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
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
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 -->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 -->Audit
<!-- CHECKLIST -->Checklist
- 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
Support section
Github Enterprise Support offers very usefull assistance on everything you search. :+1:
Also, GitHub offers a Premium Support with a 24/7 hours of operation availability time.
<!-- CONTRIBUTING -->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.
- 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
License
Distributed under the MIT License. See LICENSE.txt for more information.