Mastering GitHub Actions: Using Secrets Safely and Effectively

GitHub Actions is a powerful tool that has reshaped the way developers think about continuous integration and deployment (CI/CD). It allows us to automate various software workflows directly within our GitHub repositories. One of the challenges with automating workflows, especially deployment workflows, is that they often require sensitive data. Thankfully, GitHub has addressed this with their "secrets" feature. In this blog post, we'll dive into how to use secrets in GitHub Actions, based on .

What Are GitHub Secrets?

A secret is a piece of sensitive information that you don't want to expose in your code or workflow files. This can include API keys, database passwords, or deployment credentials. Instead of hardcoding these directly into your code, you can define them as secrets in your GitHub repository, and then reference them in your GitHub Actions workflows.

How to Set Up a Secret in GitHub:

How do we use secrets in Github?

Once the secret is there, you can use it in your workflow files by referencing it with the secrets. For example, if you've created a secret named DEPLOYMENT_KEY, you can reference it in your workflow file like this:

yamlCopy code
steps:
  - name: Deploy to server
    run: deploy-to-server --key ${{ secrets.DEPLOYMENT_KEY }}

When the workflow runs, GitHub will automatically replace ${{ secrets.DEPLOYMENT_KEY }} with the actual value of the secret, ensuring that sensitive information is never exposed in logs or to the public.

Imagine you're working on a big coding project, something you're really passionate about. As your project grows, so does the complexity of managing all the pieces, especially when it comes to automating tasks with GitHub workflows.

That is why I like to divide workflows to pull-request.yaml dev and staging in main.yaml and have a seperate workflow for prod_deploy.

Best Practices I have found:

Avoid hardcoding secrets: Always use the secrets context to reference secrets. This ensures that the secret's value is never visible in logs.

Limit access: Only provide access to secrets for actions that absolutely need them. You can use variables for some cases, this is to avoid a bloated secrets section.

Review code carefully: Ensure that third-party actions you use in your workflows are trustworthy, as they could potentially access the secrets you provide.

Rotation: Regularly rotate and change your secrets, especially if you believe they might have been compromised. For example an API token that has been shared in a chat.

Scoped secrets: GitHub also provides repository-scoped and organization-scoped secrets. Use the appropriate scope for your secrets depending on where and how they're used.

Avoid exposing secrets in logs: Be careful with scripts or tools that might print sensitive data to the console. GitHub automatically removes secrets printed to the logs, but it's a good practice to avoid printing them at all.