Security: specifying which self-hosted runners to use for pull requests

We use the development model where developers can create PRs with feature branches that can be merged to master/main or a release branch when the required checks pass and reviewers aren’t too grumpy that day. With Jenkins, we have different on-site build boxes that have access to different things, one can deploy to production, the other is just there to do linter/phpcs checks and perhaps echo funny quotes from co-workers we collected over the years.
Obviously we only let pull requests run their jobs on the latter only, and reserve the production builders for merged code only, by blocking build agents on certain branch patterns using a complex Jenkins configuration that only admins can modify.

How do I replicate this with Actions? I want to say: if PR, then only run the build on runners with label X, so that untrusted code only able to run on a location that we control. The workflow file itself obviously cannot be trusted until it is merged, so specifying the runners there is not an option.

Is it somehow possible to separate concerns here depending on whether or not it is a PR, without everyone able to circumvent this by editing the workflow itself?

Hi @sfynx,

I’m not sure 100% follow, firstly, it’s recommended to use self-hosted runner for private repository, 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(more details here).

Secondly, since the developers can create PRs with feature branches, if they can modify the workflow yaml on the feature branch, workflow could use different label runner. Currently it’s not supported to limit the runners unless there is only one.

Admin can create branch protection rules, to prevent direct commit to the target branch.
Typically admin will add required status check & required reviews, only when all passed, it’s safe to merge. Please refer to official doc below for more details.
https://docs.github.com/en/github/administering-a-repository/defining-the-mergeability-of-pull-requests

Thanks

We use private repositories, where developers develop on a feature branch and then create a PR to merge to the main branch eventually. No forks are involved.

Secondly, since the developers can create PRs with feature branches, if they can modify the workflow yaml on the feature branch, workflow could use different label runner. Currently it’s not supported to limit the runners unless there is only one.

This is exactly my problem. Developers are able to change the labels in the workflow file in the PR before it is reviewed and merged, so they can run it on any runner they wish. I want to make sure PR’s are only executed on our runners that are not responsible for critical workloads and therefore have no access to critical infrastructure.

In Jenkins I was able to do that by creating multiple GitHub organization folders, where one only responds to pull request builds and has separate credentials and approved build agents / clouds (so even if a developer would set a different build agent in the Jenkinsfile it would simply fail the build).

Hi @sfynx,

In Github, we can specify the runner group to the repository in organization setting, only allow that repository to use the runner. However, it’s not supported to limit the runner only for event ‘pull_request’.

You can raise a feature request ticket in below link where github product manager will take a review.
https://support.github.com/contact/feedback?contact[category]=actions

Thanks