GitHub Actions to Manage Secrets & Environment Variables

Only a GitHub repository is needed to create & run a GitHub Actions workflow. This tutorial explores the use of GitHub Actions for managing encrypted environment variables known as secrets:

During deployments, you would often need certain keys (AWS, Azure, etc.), passwords, or tokens to authenticate to various systems. These should not be displayed in the console when the workflow is run.

GitHub Actions can save these as secrets.

What are GitHub Actions Secrets

GitHub Secrets are encrypted environment variables that are normally created in GitHub organizations or repositories. These secrets can be passwords, AWS /Azure credentials, Docker Hub credentials, tokens, etc. We can reference these secrets which are created in GitHub Action Workflows.

Any user with collaborator access to the repositories can use the secrets in the workflows. Secrets can be created at the Organization or at the Repository level.

By default, in the free plan, Organization secrets can be used in Public Repositories only and not in private repositories. You will need to upgrade your plan if you need to use organization-level secrets in private repositories.

Note: If the same secret exists at the Org and Repo level then the secret at the Repo level will take precedence.

Limit on GitHub Secrets:

The limit is 100 secrets that can be created at the Organization and Repository level.

Let’s start by creating GitHub secrets and see how to reference the same in GitHub Actions Workflows.

Creating GitHub Secrets in a Repository

Follow these steps:

#1) On the main page of the repository, click on the Settings tab.

#2) On the left-hand sidebar, click on Secrets -> Actions

#3) Click on New Repository secret.

#4) Click on Add secret. Two more secrets are added.

Further Reading => Managing GitHub Repository – A Complete Study

Tips on naming secrets:

Secrets will be used in the GitHub Actions workflow, so it’s best to name them after the platform for convenience. E.g. to authenticate to the Artifactory platform I can use JFROG_USER, JFROG_PASSWD, and so on.

#5) On the Linux runner few commands have to be run post-Docker installation. I am using an AWS Ubuntu instance and the login ID is ubuntu.

Using Secrets in Workflow

To use the above secret in the workflow, you will need to reference it using the secret context. To reference the above secret, we would use as ${{ DOCKERHUB_PASSWORD }} in the workflow, as shown below in the example.

name: GitHub Secret Example
on:
push:
branches: [ master ]
jobs:
    Docker_Login_Check:
    runs-on: self-hosted
    steps:
       - name: Login to Docker Hub
          uses: docker/login-action@v1
         with:
               username: ${{ secrets.DOCKERHUB_USERNAME }}
               password: ${{ secrets.DOCKERHUB_TOKEN }}
      - name: List docker images
         run: docker ps -a

Here in this example, I am using the docker login action from GitHub Actions Marketplace, as shown below.

An alternate way to login to Docker Hub is by running the docker commands using the GitHub secret DOCKERHUB_PASSWORD

name: Github Secret Example
on:
  push:
    branches: [ master ]
jobs:
  Docker_Login_Check:
    runs-on: self-hosted
    steps: 
      - name: Login to Docker Hub
        run: |
            docker login -u vniranjan1972 -p ${{ secrets.DOCKERHUB_PASSWORD }}
            docker ps -a
            docker logout

So you can see that the secrets in the output is replaced by Asterix and is completely safe to use in the workflow.

GitHub Secrets are one way to manage and reference environment variables, as we have seen. In the next section, we will see how to create and use custom environment variables using the env keyword in the workflows.

Recommended Reading => GitHub Projects – Review of New Beta Features

Creating GitHub Actions Secrets in Organization

GitHub Actions Secrets can be created and shared across specified repositories for use in the workflows. To create a secret in GitHub organization, go to Organization -> Settings -> Security-> Secrets and Variables -> Secrets.

What are GitHub Actions Environment Variables

GitHub actions environment variables store information such as login credentials, passwords, tokens, API keys, etc. In this section, we will see how to create and use custom environment variables to store information and reference them in your workflows.

How to use Environment Variables

We will look at below three scenarios on the usage of environment variables:

• Access common environment variables in all jobs within the workflow
• Make environment variables accessible specific to a job (All Steps) in the workflow
• Make environment variables accessible specific to a job (Specific Step only) in the workflow

Further Reading => GitHub Advanced Security – A Complete Guide

Rules for naming Environment Variables

Environment variables should always start with a letter and can contain alphanumeric characters and underscores. It cannot start with GITHUB_ or SECRETS_ as these are internal to GitHub. Environment variables cannot start with a number and are case-sensitive.

Scenario #1: Create a yml file and add the below code. The below example uses a common custom environment variable and can be referenced in multiple jobs within the workflow.

Note here that env keyword is mentioned above the jobs and not within.

name: Environment Variables Example
on:
  push:
    branches: [ master ]
env:
    VN_KEY: ABCDEFGHIJKEY
jobs:
  Env_Var_Check:
    runs-on: self-hosted
    steps: 
      - name: Print Niranjan's Key
        run: echo "Niranjan's key is ${{env.VN_KEY}}"

Scenario #2: Let’s look at using the env variable within the job. In this case, there are 2 jobs but the key is referenced only I the first job.

name: Environment Variables Example

on:
  push:
    branches: [ master ]
jobs:
  Env_Var_Check1:
    env:
     VN_KEY: ABCDEFGHIJKEY
    runs-on: self-hosted
    steps: 
      - name: Print Niranjan's Key
        run: echo "Niranjan's key is ${{env.VN_KEY}}"

  Env_Var_Check2:
    runs-on: self-hosted
    steps: 
      - name: Print Niranjan's Key
        run: echo "Niranjan's key is ${{env.VN_KEY}}"

Commit the file and look at both the jobs output.

Env_Var_Check1 job Output

The key is printed in this job.

Env_Var_Check2 job Output

The key is NOT printed in this job, as the key was specific to the first job and is blank.

Scenario #3: In this example, let us look at how to make environment variables accessible only in a specific step within the job

name: Environment Variables Example

on:
  push:
    branches: [ master ]
jobs:
  Env_Var_Check1:
    
    runs-on: self-hosted
    steps: 
      - name: Print Niranjan's Key in step 1
        env:
          VN_KEY: ABCDEFGHIJKEY
        run: echo "Niranjan's key is ${{env.VN_KEY}}"

      - name: Print Niranjan's Key in step 2
        run: echo "Niranjan's key is ${{env.VN_KEY}}"

Lastly, in part 1 of the article I have mentioned how to access default environment variables with example code. Click here for a list of default variables.

Note: While creating the yml file a caution is to maintain the indentation else you will see multiple errors.

Limits in GitHub Actions Secrets and Environments

One can store up to 1000 organization secrets, 100 repository secrets, and 100 environment secrets. These are the limits for which can be accessed in a workflow. Secrets are limited to 48KB only in size.

Conclusion

In this article, we have seen how GitHub Actions can be used to manage secrets which are encrypted environment variables which is normally created in GitHub organizations or repositories. These secrets that are created can then be referenced in GitHub Action Workflows.

We have also seen environment variables to create and use custom environment variables to store information and reference them in your workflows.

Thank you for reading.