How to prevent repository collaborators from triggering workflow #27110
-
According to https://help.github.com/en/github/automating-your-workflow-with-github-actions/authenticating-with-the-github_token, Anyone with write access to a repository can create, read, and use secrets. Suppose there is a GitHub repository secret that contains a token for deploying to the staging (or even production) environment. Any collaborator with write permissions can create a new GitHub workflow file, use the repository secret to deploys to staging/production environment in that workflow file, push the changes into any branch and thus trigger this workflow. As a result, an arbitrary version of the code will be deployed. Is it possible to prevent this and allow triggering deployment only to authorized users? |
Beta Was this translation helpful? Give feedback.
Replies: 6 comments
-
I have the same thought. If I want to use actions for deployments, I’d want to make sure that only master could be deployed to production. master can then be protected with branch protection to ensure that changes to workflow files must be approved by the relevent CODEOWNERS. |
Beta Was this translation helpful? Give feedback.
-
According to https://github.community/t5/GitHub-Actions/Question-on-actions-security/m-p/35028/ it seems that in order to achieve desired security boundaries we have to use forks. |
Beta Was this translation helpful? Give feedback.
-
@anantakrishna we have exactly the same problem. Have you figured out a solution without creating the overhead of a forked repository for every developer? I have found this GitHub application: GitHub - eladchen/protected-workflows: A Github application that cancels unauthorized workflow runs. I also found that BitBucket has this problem solved: Build trust in your deployment workflow with deployment permissions - Bitbucket Thank you. |
Beta Was this translation helpful? Give feedback.
-
No, I have no news in this regard since then. So either use forks for collaborators (which is a pain, I should say) or move the deployment scripts (pipeline) to some other platform like Travis. Maybe having a separate repository on GitHub with the deployment actions might work, yet I have not tried it. Anyhow, not very convenient. |
Beta Was this translation helpful? Give feedback.
-
Critical workflows and secrets can be put behind an environment that requires approval before running. The required approvers can be restricted to non-collaborators. See Environments - GitHub Docs This way any contributor could still queue the run, but there is an extra layer of protection and a mandatory review/approval would be required before the workflow would run. |
Beta Was this translation helpful? Give feedback.
-
Indeed, this is something new! Thank you, @konradpabjan. GitHub has released this feature just one month after me asking the question here: The GitHub BlogGitHub Actions: Environments, environment protection rules and environment...GitHub Actions: Environments, environment protection rules and environment secrets (beta) Here is a couple of follow-up blog posts about how to use this new feature: The GitHub BlogGitHub Actions: Limit which branches can deploy to an environment | GitHub...GitHub Actions: Limit which branches can deploy to an environment Implementing least privilege for secrets in GitHub Actions | The GitHub BlogGitHub Actions provide several features to help your organization effectively implement a secret management strategy based on least privilege. Now I’m eager to adopt this feature in my projects! |
Beta Was this translation helpful? Give feedback.
Critical workflows and secrets can be put behind an environment that requires approval before running. The required approvers can be restricted to non-collaborators. See Environments - GitHub Docs
This way any contributor could still queue the run, but there is an extra layer of protection and a mandatory review/approval would be required before the workflow would run.