GitHub action security

This is mainly a high level overview of some best practices I've been thinking about while contributing to an open source project recently, and mainly a note for me on how to use some of the cool features I've been playing with 😅.  This is much more extensive documentation than my post will even aspire to be, so go check that out if you want more detailed info.

GitHub Environments

Here is the guide from GH talking about what environment variables are, and these environments are how you can add extra security around your GH actions.

You can create these by going to the Setting ➡️ Environments ➡️ New environment

Next you add in a name for your environment (i.e. production), and "Configure environment" (only button to go next).

After you get to the configuration page for the environment, there will be a few options. You can add as many secrets as you want, but I'd recommend (to help ensure manual intervention before accessing secrets) to at minimum click "Require reviewers". This will require manual intervention by people/teams to approve a workflow before allowing it to access the secret.

Next how to use those environment variables in GH actions.

The GH action config

While you can define the secrets outside of the environment, specifying the environment on the individual jobs will be what allows you to access those secrets inside the job. So, the important line to add to your GH action job is:

environment: <environment_name>
# example
environment: production

This'll require a team member to approve access to the environment by holding up the GitHub action like the picture below.

Once the team member clicks "Review deployments", you can select the environment you want to give them access to add a comment and then click "Approve and deploy".

This will leave an audit history below the workflow to show who approved it, and if they left a message with the approval. (as seen below)

More security...

In addition to the aformentioned required reviewers, if your concerned about other team members getting access to your secrets. Then you can restrict which branches the environment can be accessed on.

This would allow you to have protected branches (i.e. main and develop), which would PRs against or commits to be pushed to. Might be a bit excessive, but whatever fits your security model 🙂

Conclusion

Seems like you can really secure your GH actions from potentially malicious PRs against your repo 😁

If you'd like me to do a deeper dive and see which ways I could potentially reveal GitHub secrets, please comment and maybe I can do a post on my work's blog again it 🥳.