GitHub Actions Day 11: Secrets

This is day 11 of my GitHub Actions Advent Calendar. If you want to see the whole list of tips as they're published, see the index.

Yesterday we set up a workflow that triggered based on paths being changed; it's goal was to publish documentation. If you looked carefully, at the bottom of the workflow, we referenced a variable. It looked sort of like how we referenced matrix variables but instead was referencing a secret.

You'll often need things like tokens or passwords in deployment scenarios - GitHub Actions supports savings these as secrets in your repository.

To set up a secret, go to your Repository Settings page, then select Secrets. Your secret's name will be used in your workflow to reference the data, and you can place the secret itself in the value.

To use that secret, you can reference it using the secrets context within your workflow. If you had a secret named SECRET_KEY, you could reference that as ${{secret.SECRET_KEY}}.

The GITHUB_TOKEN

GitHub Actions automatically sets up a secret within your repository for every workflow run, the GITHUB_TOKEN. This token lets you interact with your repository without needing to create a new token yourself, or set up a secret.

This token gives you limited access to read and write to the repository itself, to issues, and to GitHub Packages. But it does not give complete access to everything -- you can't work with other repositories in your organization or publish to GitHub Pages -- so for some workflows you may still need to set up a token.

Secret Safety

GitHub tries to keep your secret safe from prying eyes. In the output log, any secrets that you have defined are scrubbed and replaced with asterisks before the log is output.

This helps keep your secrets safe from prying eyes - especially from tools that dump out their values. But it's not perfect, of course, and you should be careful about keeping your secrets secure.

Forks

If your project makes use of forks to accept pull requests from contributors -- if you're working on an open source project, for example -- you may be wary of using secrets in your workflow.

GitHub explicitly disables giving secrets to workflows that originate from a fork. That means that when a user opens a pull request on your project from a fork, no secrets are provided to this workflow.

This helps prevent users from modifying the workflow itself - or any scripts that the workflow calls - to try to get a copy of your secrets. The secrets simply aren't available.

(The special GITHUB_TOKEN is still provided to forks so that they can clone your repository -- in order to build it -- but it's been downgraded to a read-only token to prevent fork workflows from making changes in your repo.)