Do I need to pass each secret to my GitHub Actions workflow file?

Question

I have a number of secrets, stored in Settings/Secrets/Action of my repo.

The various secrets are used by my application but none of them are used in the command.

name: BuildCheck

on:
  push:
  pull_request:
    branches: [main]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 14
      - run: npm ci
      - run: npm run build

Do I need to add all the variables under env top level map in the config file above in order for the action to use them?

This seems to break my automated flow of managing secrets with Doppler.

Is there a way to inject all secrets, without explicitly specifying them? (I did look at the docs but failed to find if this is possible)

Coming from Vercel, which does this it feels like a bit of a step back.

Answer 1

Do I need to add all the variables?

Not necessarily. If you have many secret entries, you may prefer to store them as a single file(normally in json format) and encrypt them to single GitHub Secret entry, that you can pass to action and parse to individual values from json in your code.

There is an example how to do it in Google services json file for github actions?

Disadvantage of keeping many entries in a single file is that when your need to change one value, you have to resubmit the whole secret file. Keeping individual secrets as separate entries reduce impact if file will be compromised or corrupted (e.g. missing comma in json)

Note that Secrets are limited to 48 KB in size. If your total size of secrets exceed the limit, split them into a few smaller json collections, or follow https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#storing-large-secrets

Answer 2

Firstly: Split configuration from secrets:

• Using configuration files for configuration options.
• Using secrets for secret keys or other credentials.

There is now another option:

GitHub Actions – Support for configuration variables in workflows (Jan. 2023)

Today, we are adding support for configuration variables in GitHub Actions

Previously, you needed to store this configuration data as encrypted secrets in order to reuse values in workflows.
While extremely secure, this method did not allow for easy storage and retrieval of non-sensitive configuration data such as compiler flags, usernames, server names etc.

Configuration variables allows you to store your non sensitive data as plain text variables that can be reused across your workflows in your repository or organization.

You can define variables at Organization, Repository or Environment level based on your requirement.

Configuration variables can be accessed across the workflow using a new vars context.

The following example shows how configuration variables can be used in a workflow.

jobs:
  display-variables:
    runs-on: ${{ vars.RUNNER }}
    steps:
    - name: Use variables
      run: |
        echo "Repository variable : ${{ vars.REPOSITORY_VAR }}"
        echo "Organization variable : ${{ vars.ORGANIZATION_VAR }}"

Note: Variables feature is in public beta

Learn more about configuration variables

Answer 3

There's a bit to unpack here.

Do I need to add all the variables?

The short answer: yes.

However what's good to consider is that secrets often only configure connections between system in the form of secret keys or application access using a license or credentials.

It is not common to add other configuration options inside the secrets.

Under env: top level map in the workflow file?

I would discourage putting secrets in the top level env.

Reason is that env will be exposed to all subsequent jobs. In case someone adds a job that's not trusted with this information (say an external action) it could become a problem.

So what's good practice?

Firstly: Split configuration from secrets:

• Using configuration files for configuration options.
• Using secrets for secret keys or other credentials.

Secondly: Using security first.

• Configure each workflow step with just the information it needs
• Explicitly pass secret variables to action parameters

Lastly: store configuration as close to the app as possible, optionally having multiple - each for a different environment.

Comparison with Vercel

Vercel abstracts away the workflow entirely and as a result can only do very specific things. The nature of each system is different and gives you different levels of flexibility.