I’m evaluting GitHub actions for my project, and I’m currently having some question about security.
This is our current working mode:
- each developer has his own fork of the repo, and once his code is ready for testing, a new pull request to develop branch is created, which triggers an automatic deployment on test environment, under a specific path with the pull request id.
- when the code review is done and the single feature is approved, the pull request is merged to develop together with the other features waiting for be released all together.
- when ready to release, a new pull request is created from develop to master branch, and once merged, this triggers the automatic deployment to production.
Developers have access to test and dev environments, but not to production, neither to the server used to build/deploy.
We are currently evaluating the idea of switching to GitHub actions, and get rid of the server, but now the problem come:
- in order to sobstitute the current server, we need to be able to deploy to test/dev/prod
- to do so, we need to move some secrets to access test/dev/prod configuration (or extra secrets) in the repo
- even tho, developers have no access to the secrets in the repo, they can potentially create a new workflow (or change the content in their branch) which can trigger a deployment to prod instead of test/dev
- even tho they work on their own fork (which do not contains the secrets), when a new PR is created, this can still trigger a deployment, and their workflow can have a different content then the one in master
Is there a way to avoid this?
I’d need to understand a little bit more data about your process - in particular, who does the pull request from develop to master, and whether that person is trusted - to understand completely, but it sounds like your developers are working from forks, which is ideal for your setup.
Forks do not have access to your repositories secrets. So if one of your developers creates a pull request that modifies a workflow, they will not be given a copy of the secrets. If you created a workflow that deployed to a dev environment on pull request, then you would need to provide a copy of the secrets necessary to do that deploy to the developers to configure for themselves. Otherwise, they have no access to the secrets in the main repository.
Then, once merged into the master branch, the workflow running in the main repository will have access to the production secrets and able to deploy.
Note that this does mean that whomever opens the pull request from develop to master will have access to the production secrets if that pull request is opened directly from the main repository. (You could open this from a fork to limit this exposure.)
Thank you for your answer, let me clarify our flow.
- Each developer has his own fork of the repo
- Commits in master branch requires a pull request review
- Ideally we would have 3 workflows:
- prod: this would be triggered by push in master branch, or upon a new release
- dev: this would be triggered by push in develop branch
- pr: this would be triggered by pull request creation to develop branch
From your feedback it seems the pr workflow will not be able to make any deployment since in this case the secrets will not be available, I guess my confusion come from that, I was expecting to access secrets upon pull request creation.
You mentioned in your comment, that I should provide to develoopers a copy of the secrets needed in order to let the pr workflow work, so I’ve created a secrets with the same name in the forked repo, but also in this case the secret is not accessible from the upstream pr workflow. Having an action, on the forked repo would not be a solution in our case, because the PR number is used to create a path on the test environment, for allowing testers to perform test omn that specific code change, and having a number which changes in each fork, is not a good solution in our case.
Do you have any suggestion for how to cover this scenario?
A potential solution I was thinking of, is to create a custom action, which contains all the secrets and the code to build and deploy. It may also enforce the use of a specific branch, so that when a production deployment is triggered, it forces to use the code from master branch. Do you think this approach make sense? Do you see any side effects? Would it be possible for the calling workflow to see the logs of the invoked custom action?
I would also like to highlight a couple of things I’ve noticed:
- since there is no actions-level settings, when somebody creates a pull request to a public repo, any users may introduce custom workflow to execute arbitrary code
- based on previous point, would those runs increase the repo’s owner costs?
@ethomson The forking method seems like it adds a bunch of unecessary overhead for internal devs on a project. I feel like it’s a common enough use case on projects to have devs that need write access but not deployment access on repos.
Bitbucket has a feature that supports this: https://bitbucket.org/blog/build-trust-in-your-deployment-workflow-with-deployment-permissions
I was wondering if github had any plans to implement similar functionality?
And here it is, in December 2020 GitHub has launched such a feature! See related question: How to prevent repository collaborators from triggering workflow - #7 by anantakrishna