Tighter reins on self-hosted runners
GitHub Actions is adding a new layer of access control for self-hosted runners, letting administrators pin a runner group to only the workflows they explicitly approve. The update is aimed at shops that keep production secrets on self-hosted machines but have been forced to let every job in a repository—including low-risk tasks like an issue labeller—reach those runners. Now, that’s no longer the default.
The feature fits alongside the deployment-security tooling GitHub has shipped recently, such as OpenID Connect and reusable workflows. For teams not ready to make the jump to OIDC, this restriction is a more direct way to keep privileged runners out of reach of arbitrary workload code.
The key capability: in a runner group’s settings, admins can specify which workflows may access that group. Combined with reusable workflows, this becomes a governance mechanism. Instead of granting every developer’s bespoke deploy script access to a runner holding production credentials, an organization can declare a single reusable deployment workflow. Any other workflow that tries to use the runner group will be blocked unless it invokes that sanctioned workflow.
The intended setup pattern:
- Write a reusable workflow that defines the required steps for a production deployment.
- In the runner group’s configuration, set Repository access to All repositories.
- In the same settings, set Workflow access to Selected workflows and point it at the reusable workflow you just created.
Once saved, anyone in the organization can run jobs on that production runner group—but only if they are executing the referenced reusable workflow at the pinned ref, for example monalisa/automation/workflows/deployment.yaml at v1. This lets an org enforce a standard deployment path and its associated runner configuration across every team, without opening the door to arbitrary, less-vetted jobs.
