A way to manage access around who can edit contents of `.github/workflows/`

[timharris777]

Enhancement: Provide role separation around who can edit contents of .github/workflows/

Reasoning: In an organization setting you have a lot of people who have write access to repositories. Add github actions workflows and secrets manager (think org level secret manager when it is released) and every person with write access could change a workflow file or create a new workflow file to print out the contents of a secret. Being able to limit the people who can edit workflows would be a huge plus in the security front.

@ds0440 @josephshanahan-cfa

[Eldrick19]

https://github.com/github/roadmap/issues/52 Required workflows will likely help with this. Create a workflow/Action in a private repo that checks what directory is being edited. If it's the .github/workflows directory, fail. Put branch protection rules to require all checks to pass for a merge

[FOSSgeek]

@deutmeyerbrianpfg that exactly why I'm here looking for any protection mechanism for my repos, do you have any workaround to protect my repos

[FOSSgeek]

guys i think what did @deutmeyerbrianpfg mention in his comment:

Another big concern with not having access controls is that a contributor can change the workflow trigger from on pull request to be on push. That would allow the workflow to run without any approvals! We've configured an environment for the production deployment, however, if someone removed that and changed the trigger to be push, the workflow would run in its entirety, bypassing the approvals.

this is very dangerous to be possible for our repos any workaround ? I'm scared that my action secrets would be leaked or stolen

[jgwinner]

Tagging onto this feature request.

I realize that, to a developer, hacking around with RAM is always a possibility to grab secrets, but honestly any protection would be better than none.

It's like the old joke about locks keeping the honest people honest. The main thing, it would prevent accidents.

I'm building a CI/CD step that will spin up servers on a PR so that the Lead can see the code in a running environment. It would be nice if dev's couldn't just arbitrarily spin up resources, or push to production!

(actually it's serverless but it's easier to think of as spinning up a server).

In another app I have a separate CI/CD repo, where I do things like spin up servers, but in this case we wanted a PR or a code push to do things, so that's usually got to be in the same repo. (private repos). I guess I could build some kind of action that's trigger on a PR close, that activates a REST API that then does something else from some other repo, but that seems excessively complicated.

Some other good tips in this thread, I'll go back to lurking.

[13013SwagR]

I opened a feature that would solve this and seems fairly simple to implement, see https://github.com/orgs/community/discussions/53430

[TheArtheist]

Should now be possible via push rules.

[fpvandoorn]

Push rules are not available on public repositories ☹️