Limiting who in an org can disable workflows


We’re setting up GitHub Actions workflows and are looking to lock down permissions via workflows. In particular, looks promising for limiting the ability of anyone to contribute to the .github/workflows/ directory. However, anyone in the org with write access, even as a non-admin, has the ability to just disable any workflow, which would render that workflow useless.

How would I limit the ability to disable/enable workflows to just repo/org admins?

I think, this is what you’re looking for.

Only admins have access to secrets. It should work.

Could you expand on what you mean here? Only admins have access to secrets, but I don’t see the connection between secrets usage and the ability to enable or disable a workflow (from the Repo → Actions tab → Workflow → Enable/Disable Workflow).

An option:

Branch protection rules and a Codeowners file. In the CodeOwners file, you specify a person or a team that owns the workflows folder. Then create a branch protection rule that requires codeowners approvals. If anyone adds or modifies the files in the workflows folder, the owners will be automatically added to the PR and required.

ahh, but you also asked about enable/disable workflows via the GUI

Let me look into that one

So yep, you are correct, write access to a repo let’s you enable/disable workflows. I’ve asked internally if there is any way around that, but looking at the permission structure, I don’t think there is.

That said, it does show up in the audit log that it was disabled and who disabled it, so you would be able to track it.

Thanks for confirming. To add some context here, the bigger problem we want to solve is: how can we limit the ability for anyone with write access to a repository to creating a new workflow in .github/workflows/malicious_workflow.yml (and setting it to run on: pull_request) in a way that it can take advantage of the permissions we’ve granted to our self-hosted runners? We’re doing all we can to limit the permissions of the self-hosted runners themselves, but ultimately we’ll need to grant some permissions that make us want to fully lock down who can arbitrarily run a workflow via a pull request.

The reason the PR Regex Exclude action looked promising was that it could effectively block anyone (except from a protected branch, which would have a codeowners attached) from putting up their own workflows via .github/workflows/.

Do you have any thoughts on the best practice here? We don’t have GitHub Enterprise so we don’t have audit log API access so listening to the audit log isn’t a viable option (not that we’d prefer a retroactive response instead of a proactive limitation). We could run a cron job that constantly enables the workflow so no manual disabling will work, and then lock down access to shutting off/disabling the cron job, but that feels a bit hacky.

Some of this is me just talking off the top of my head, so sorry for the rambling. :slight_smile:

So my first response to this when I hear it from customers (and I have heard it before) is that is that something you really are concerned about (which implies a bigger culture issue and discussion)? Or is it something that hasn’t ever happened before, but we are playing “what if”. I always advocate highly for trusting your developers and team members to do the right thing in your DevOps journey, and then, if they don’t, then figure out the appropriate punishments and how to stop it in the future. That said, if you have already been burned by something like this, then I get it.

Second is that you have to be careful with giving people too much permission on self-hosted runners, for exactly that purpose :slight_smile: I know, easier said than done.

So, let’s move on to “yes, we need to try and do something”. The problem you run into (which I know you know, but I’m restating for the broader audience), is that you can add a workflow to your branch, triggering on PR, and when you create your PR, it runs the workflow. So even the PR Regex Exclude action doesn’t help you here, because it is a workflow that triggers on a PR. So while it might be able to stop your PR from merging to main, it can’t stop that malicious workflow file from running because the PR was created.

Have you looked into environments? With environments, you can specify secrets, manual approvals, and even which branches can target that environment. I don’t think they will 100% solve this problem, but the manual approvals before the job can run might be able to help.

A really hacky option: Have an Action workflow or a GitHub App that listens for every push to the repo. Then have it examine the commits, and see if anything was added/modified/deleted from the workflows folder. If so, it could notify you. Again, not ideal.

I’m gonna throw this one at my team and see if they have any other thoughts. Sorry for the rambling.