Access control of GitHub actions to repository Secrets

Hi all,

I have been working on testing out running GitHub Actions for some of my organisation’s CI/CD needs. Certain steps in our CI/CD pipeline could involve running production changes with terraform. However, there is a blocker preventing us from doing it safely:

We want to enforce change control by deploying to production via CI/CD, which means that committers with write access to the repository must still raise a PR, and get it approved by another committer with write access (with branch protection) before the change can be deployed to production.

However, because GitHub Secrets are accessible to workflows running in either protected branches (e.g. master) or feature branches, if any committer’s credentials are compromised, an attacker can simply push an unreviewed workflow into a feature branch of the repository, before they can export any production secrets in the repository’s Secrets and thus gain production access.

I’ve looked at some past discussions around access control to secrets, such as [1]; as well as the item on GitHub’s road map to add support for manual approvals of workflows [2]. While [1] will not solve the problem of a single committer being able to retrieve repository Secrets, [2] – if applicable to all workflows in all branches – could solve this problem.

Please may I check:

  1. Is the plan for [2] to allow a repository admin to require all workflows in any branch to be subject to approval?
  2. Are there any plans for fine-tuning API permissions of workflow runners so that certain secrets can only be accessed by workflow ran from protected branches (e.g. master)?

Let me know if this is the wrong place, thank you.

[1] Secrets on Team and Organization level
[2] https://github.com/github/roadmap/issues/99

2 Likes

Hi @chongyangshi,

Glad to see you in Github Community Forum!

Please raise a feedback ticket in below link to confirm about the plan details:

https://support.github.com/contact/feedback?contact[category]=actions

Thanks

I’ve done that, thanks @weide-zhou

Hi,

one way to protect your secret from collaborators is to run the workflow from another repository.

Let’s say your repository is called MYPROJECT. As you already stated, any collaborator can extract and use existing secrets in their own workflows and do all kind of shenanigans.

You could create another repository called MYPROJECT-ADMIN which defines the secret and runs the workflow. This project could be private and if you choose to you could not have any other collaborators on this project so nobody would be able to access the secret. Or you can have a different set of collaborators.

This is probably easiest if the trigger is a schedule.
But if the trigger depends on actions from MYPROJECT this comment has some suggestions how to make this possible Triggering by other repository

This is really important as any developer can access all the secrets if they want to. I also think most developers probably don’t realize how insecure this is.

Separate secrets for protected branches would be a good way to fix this.