Secrets design with branch-deploy action
bendwyer opened this issue · 2 comments
Details
Hi,
The production-secrets vs production environment split makes sense to me, but I am struggling with where to place secrets if I will be using workflows in addition to branch-deploy that depend on environment secrets.
For example, if I have environment-specific secrets for two different environments (dev, prod) and I create development-secrets and production-secrets, I can tell the branch-deploy workflow where to pull secrets from and where to deploy to. If I have a workflow that runs on a schedule and interacts with either of the -secrets environments, then as far as I can tell the deployment will be tracked against one of the -secrets environments, not production or development. Is there a way to avoid this?
I’ve been going through some of the live examples, and found ci.yml in tarkov-data-manager is deploying to the production environment, while branch-deploy.yml is pulling secrets from production-secrets and deploying to production.
How are secrets handled for the ci.yml workflow? Are they somehow pulled from production-secrets, or are they stored instead as repository secrets?
If they are stored as repository secrets, then what is the purpose of theproduction-secrets environment in the tarkov-data-manager repo?
👋 Hello @bendwyer!
I can help answer some of these questions, especially about the tarkov-data-manager repo as I am an owner in that repo.
Things were kinda tossed around in that project early on as an experiment and what we landed on might not work the best but it works.
The branch-deploy workflow uses the production-secrets environment to inject secrets into the workflow. On the other hand, the ci workflow just uses plain production as the environment to pull secrets from. These environments are more or less the same and there isn't really a reason for this that I can recall. It probably could have just been one environment and perhaps the tarkov-data-manager isn't the most well kept project to look at for inspiration here 😅
example of what our environments look like (pretty much the same)
Now the main reason to be using environments to store your secrets (apart from just repository secrets), is due to the fact that you can configure rules to protect your environments. This means that you can lock it down so that only the main branch has access to the secrets in your environment (see screenshot below for an example)
And since all branch-deploy commands, run from the context of the main branch (as noted here) then your secrets will be extra safe. This even helps protect against malicious outside contributors that try to edit your workflow file to switch the trigger from issue_comment: to something like push:. The issue_comment: trigger is bound to the main branch by default so if it is switched to something like push:, workflow runs won't be coming from main and hence the secrets will not be loaded into the CI job. This adds an extra layer of safety and ensures that invocations of the branch-deploy Action are only really coming from the workflow file that is checked in on the main branch and that is how we inject secrets as well.
Hopefully that helps!
Hi @GrantBirki
Thank you for the detailed response!
I guess repository secrets are my best fit for now because I have secrets for multiple cloud environments that are regularly rotated via a composite action.
Storing secrets as environment secrets and using the composite action to rotate them results in secret rotation counting as a deployment for the associated GitHub environment. I was unsure how well this would co-exist with the branch deploy action, so I decided to simplify and store credentials as repository rather than environment secrets. It's not quite as secure as your excellent example, but for now it works.
Thanks for writing such a useful and well documented action.