Add recommendations for runner groups and labels#91
Conversation
Signed-off-by: Thomas Sjögren <konstruktoid@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Updates the “Securing GitHub Actions Workflows” guidance by adding runner-segregation recommendations and expanding ruleset guidance, while marking the page as draft.
Changes:
- Set the page to
draft: trueand added an additional author. - Added “Segregate runners” as a top-level recommendation and a dedicated section with implementation details.
- Added a repository ruleset recommendation to require workflows to pass before merging.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Signed-off-by: Thomas Sjögren <konstruktoid@users.noreply.github.com>
Signed-off-by: Thomas Sjögren <konstruktoid@users.noreply.github.com>
konstruktoid
had a problem deploying
to
development
GitHub Actions
Failure
Signed-off-by: Thomas Sjögren <konstruktoid@users.noreply.github.com>
| 10. **Use `head.sha` instead of `head.ref`**: Where possible, reference by commit SHA instead of a user-provided branch name or tag (ref), especially in sensitive contexts (such as `run` steps). If require, use environment variable to store `head.ref` and reference it to prevent injection attack. | ||
| 11. **Use caution with public repositories**: Anyone can suggest changes to public repositories. Review workflow triggers, and never use self-hosted runners with public repositories. | ||
| 12. **Restrict allowed actions**: Use the [*Allow enterprise, and select non-enterprise, actions and reusable workflows*](https://docs.github.com/en/enterprise-cloud@latest/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#controlling-access-to-public-actions-and-reusable-workflows) setting to control which actions can run. | ||
| 13. **Segregate runners**: Use runner groups and labels to separate high-privilege runners (with access to secrets, sensitive resources or host access) from low-privilege runners. |
There was a problem hiding this comment.
can you clarify secrets use here? you can't restrict github actions secrets per runner/runner. You can however restrict runner usage to selected workflows/reusable
You can also restrict them to a subset of repos
There was a problem hiding this comment.
i was referring to using eg "selected repositories" in a runner group.
and yes, the runner itself isn't restricted per se, but limiting certain repositories to a specific group of runners limits the access of too many secrets.
|
|
||
| Use [runner groups](https://docs.github.com/en/actions/concepts/runners/runner-groups) and [labels](https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/apply-labels) to separate high-privilege runners from low-privilege runners. High-privilege runners may have access to sensitive resources or direct host access, while low-privilege runners should not. | ||
|
|
||
| This separation provides more granular control over [which repositories can access different runners](https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/manage-access#changing-which-repositories-can-access-a-runner-group) and which [jobs can access specific runners](https://docs.github.com/en/actions/how-tos/write-workflows/choose-where-workflows-run/choose-the-runner-for-a-job). It also reduces the risk that a compromised or misconfigured workflow could gain access to sensitive resources. |
There was a problem hiding this comment.
Can you clarify the "which jobs can access specific runners" ? this cannot be enforced once a repo has access to a given runner (you can restrict which workflows can use the runner but not the jobs) any job can use it.
Unless you restrict the workflows that can access a runner if a user can author workflows in a repo which has access to the runner it can use it.
There was a problem hiding this comment.
yeah, it's actually workflows but https://docs.github.com/en/actions/how-tos/write-workflows/choose-where-workflows-run/choose-the-runner-for-a-job#choosing-self-hosted-runners says "To specify a self-hosted runner for your job, configure runs-on in your workflow file with self-hosted runner labels." and "When you combine groups and labels, the runner must meet both requirements to be eligible to run the job." (https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/use-in-a-workflow#using-labels-and-groups-to-route-jobs).
|
|
||
| - A runner group for container image build runners, limited to only the repositories that require those privileges. | ||
| - A runner group for runners with access to restricted networks. | ||
| - A separate low-privilege runner group for tasks such as linting and static analysis, with no access to secrets or sensitive resources. |
There was a problem hiding this comment.
What is the mechanism you are considering to prevent a runner from having access to actions secrets?
There was a problem hiding this comment.
that needs rewording, what i meant to say was that if a repository only have workflows that perform linting, code analysis that in many cases doesn't need access to any secrets or privileged runners (container-in-container for example) secrets shouldn't be present in the repository at all or at least in seperate environments.
Signed-off-by: Thomas Sjögren <konstruktoid@users.noreply.github.com>
| 10. **Use `head.sha` instead of `head.ref`**: Where possible, reference by commit SHA instead of a user-provided branch name or tag (ref), especially in sensitive contexts (such as `run` steps). If require, use environment variable to store `head.ref` and reference it to prevent injection attack. | ||
| 11. **Use caution with public repositories**: Anyone can suggest changes to public repositories. Review workflow triggers, and never use self-hosted runners with public repositories. | ||
| 12. **Restrict allowed actions**: Use the [*Allow enterprise, and select non-enterprise, actions and reusable workflows*](https://docs.github.com/en/enterprise-cloud@latest/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#controlling-access-to-public-actions-and-reusable-workflows) setting to control which actions can run. | ||
| 13. **Segregate runners**: Use runner groups and labels to separate high-privilege runners (with access to secrets, sensitive resources or host access) from low-privilege runners. |
There was a problem hiding this comment.
Generally speaking, labels are not a best practice and tend to create long-term administrative difficulty. They are currently only available with self-hosted runners, which are also not recommended over GitHub-hosted from a security perspective
| 13. **Segregate runners**: Use runner groups and labels to separate high-privilege runners (with access to secrets, sensitive resources or host access) from low-privilege runners. | |
| 13. **Segregate runners**: Use runner groups to separate high-privilege runners (with access to sensitive resources) from low-privilege runners. |
There was a problem hiding this comment.
Very true, but they are in use when it comes to GitHub Enterprise servers and regarding labels so are they also the only options if you don't have organizations available as a user.
There was a problem hiding this comment.
I meant to write, that they, as in self-hosted runners, are in use when it comes to GitHub Enterprise servers
…ecurity/index.md Co-authored-by: Ken Muse <kenmuse@users.noreply.github.com>
This pull request makes several improvements to the documentation on securing GitHub Actions workflows. The most significant updates include adding new recommendations for segregating runners, enhancing repository ruleset guidance, and updating author attribution.
Enhancements to security recommendations:
Documentation and metadata updates:
authorslist in the document metadata to include Thomas Sjögren (konstruktoid).