I'm evaluting GitHub actions for my project, and I'm currently having some question about security.
This is our current working mode:
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:
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.
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:
@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?