Limit self-managed runners to protected branches

Our current workflow in GitLab has different runners with different levels of permissions.

One set of runners for dev, which service all branches in a project.

And one set of runners for QA and one set of runners for Prod that only run after a merge to master.

With the protected runner approach, we can safely have prod credentials in our protected runners and we know they are not accessible from branches, intentionally or accidentally.

Even if a developer uses the “prod” label for a runner in their branch, the runner won’t run that job. In combination with CodeOwners and other strategies we can safely assume that the master brach pipeline is safe and that branches are not.

Without this feature, we can’t move forward with GitHub actions because they is no way to guarantee that production won’t be affected by a branch.

What is the recommended deployment security separation in GitHub? From what I have been able to read so far there is no control that can’t be easily bipassed. Hoping to find that I am wrong :slight_smile:

Hi @davidgamba ,

Limit self-managed runners to protected branches is not supported, they are per repository or per organization currently. 

And encypted secrets(credentials) are also per repo not per branch, any collaborator with write access can use the secrets. Hence, there’s no way to guarantee the production won’t be affected by a branch since dev can create a new branch with same secrets, same yaml file and same runner.

As an alternative, you can sperate dev branch, QA branch, prod branch apart into different repository, then secrets and self-hosted runner can be limited to current repo.

If you’d like to add this feature for self-hosted runner, you are always welcome to raise a feature_request ticket here where github product manager will take a review. 

Thanks.

This is a dealbreaker when coming from a CI where this is supported… there really needs to be a way to enforce that untrusted (unmerged) code cannot be run on runners that handle critical workloads such as deployments.