Limiting access to secrets for a public org with a permissive commit bit policy

I’m co-lead of the Cucumber · GitHub project. For a while now we’ve had a permissive commit bit policy, where we give commit access to the main repos to anyone who has a pull request accepted. Right now we have around 270 people in this group.

This is working well for us, but it does mean that the group of people who have commit rights are only semi-trusted, and shouldn’t be given access to the secrets we use for publishing packages. It would be too easy for someone to phone home with these secrets by pushing a change to a GitHub Actions.

I’m trying to work out how we can still automate package publishing in this context. It looks to me like the only way to do it would be to have separate repo(s) that only the trusted “inner circle” of maintainers have write access to, and put GitHub Actions workflows for publishing in there.

What do you think? Is anyone else doing something like this? Did I miss anything?

2 Likes

I’ve tried cross-posting this in the GitHub Actions category to see if that gets it any attention.

Ok, my cross-post was flagged as inappropriate, sorry mods!

This is something I believe Azure DevOps solves with service connection policies. Your trusted group of people would have their own repository of workflow files that only they had access to, your more public workflows would reference those trusted workflows and reuse them. Your secrets would have a policy referencing your trusted workflow files and versions that can only be used when called by those workflows (ideally even as a called workflow).

Secret policies are the one thing I think GitHub is missing for Enterprise or large scale teams. I would love to see them on repo, environment, and org level secrets so operations teams can more scalably manage secrets securely.