How to pass masked secrets between steps and jobs in Github Actions

[ogomozov-godaddy]

I have below syntax. Since custom action has no access to secrets\env or other context of parent workflow, I have to pass this secret as input. However, this secret is produced in previous step. I need to pass this secret from step1 to step2, I made it via outputs, but it is not masked in with: parameters and dumped into console logs. I tried to export and pass it as env var, but env vars are not shared between steps. If course I can’t set env var on job level since it’s only in step1. Also I can’t merge step1 and step2 , cause I can’t use both run and uses in same step per Github Actions syntax

jobs:
  myjob:
    runs-on: self-hosted
    env:
      env_var: some-value
    steps:
      - name: step1
        shell: bash
        run: |
          export SECRET1=some value
  - name: step2
    uses: some-reusable-action
    with:
      token: ${{env.SECRET1}}

[airtower-luna]

There is a workflow command for masking customs strings. Does using that together with the step output solve your problem?

[ogomozov-godaddy]

yes. masking worked. My code looks like this

jobs:
  myjob:
    runs-on: self-hosted
    env:
      env_var: some-value
    steps:
      - name: step1
        shell: bash
        id: first_step
        run: |
          TOKEN1=some_value
          echo "::add-mask::$TOKEN1"
          echo "::set-output name=some-token::$TOKEN1"
  - name: step2
    uses: some-reusable-action
    with:
      token: ${{steps.first_step.outputs.some-token}}

[roman-sigma]

Hello, but this structure has a GitHub Action validation mistake:

[Error: .github#] reusable workflows should be referenced at the top-level 'jobs.*.uses' key, not within steps

Would you mind sharing more details implementation for this, please?

[rogarciaa]

Is this still a viable solution? The documentation specifically says: "after you mask a value, you won't be able to set that value as an output."

[legal90]

@rogarciaa your right, that solution doesn't work anymore. GitHub Actions prevents us from exposing the masked value in an output.
From the workflow log:

Warning: Skip output 'MY_TOKEN' since it may contain secret.

There is another solution proposed below: https://github.com/orgs/community/discussions/25225#discussioncomment-6776295

[airtower-luna]

Nice, and thank you for sharing your solution! 🙂

[rohanbas95]

does any one know how to share masked secrets between jobs
we have two jobs one to get details from azure keyvault and this we mask and try to output and use in our second job.

i see that masked values cannot be outputed so how to handle this situation

[enricoribelli]

found a way, added an answer

[tanepiper]

We have the same issue - want to use azure/login action in a reusable workflow, but cannot pass the secrets from the parent workflow, or access the ones in the repo settings from within the reusable workflow.

[rdhar]

Same here, but for aws-actions/configure-aws-credentials action instead.

[rdhar]

Finally came across a solution that bridges the gap between ephemeral/login-action secrets in the caller workflow and passing them securely into the reusable workflow. Shared the solution with more details and examples here.

[rohanbas95]

hii for now we got one work around
we needed those credentials to be passed in a powershell script
what we saw that if your powershell script has a parameter named password , then when you run it from github action , its is hidden

this is what was earlier
Scripts\POHSQLInstallation.ps1 -DBServer $DB_SERVER -DBName $DB_NAME -DBPassword $DB_PWD -ServiceHost ${{ github.event.inputs.serviceHost }}
This is what I am suggesting
Scripts\POHSQLInstallation.ps1 -DBServer $DB_SERVER -DBName $DB_NAME -password ${{ needs.GetAzureKeyVaultSecrets.outputs.DBPassword}}

the change is highlighted in bold letters

[enricoribelli]

Found out a hack to make this happen. Consists on temporarily "obfuscating" the secret to the eyes of Github.

In the job where I retrieve the secret I encode it and export it to GITHUB_OUTPUT:

TOKEN_BASE64=`echo -n <my_secret> | base64 -w 0`
echo -n "API_TOKEN=$TOKEN_BASE64" >> $GITHUB_OUTPUT

In the job where I need the secret I decode it (and use successfully where needed):

API_TOKEN=`echo -n ${{needs.get-auth-token.outputs.API_TOKEN}} | base64 --decode`

[airtower-luna]

The get-auth-token job doesn't define any job outputs, you'd need to do that (based on the step output you already have).

However, your token will be visible to anyone with access to the workflow logs (in base64, but that's easily decoded). Make sure to consider the security implications. ⚠️

[hawkeyetwolf]

As @airtower-luna pointed out, this does not actually add security to your workflow, it just prevents the secret value from being searchable in the logs. Anyone with access to the logs can copy the base64 encoded secret and base64 decode it 🙃

The only secure way to transfer secrets between jobs is with a "secret store" as described in the GitHub docs here.

[airtower-luna]

I don't see the point of using an external service, especially considering you'll have to store credentials for it as secrets. Why not store a (random, long, high entropy) key as a secret, use that to encrypt the data you want to transfer, carry the encrypted data over as an output or artifact (with a short lifetime), and then decrypt in the next job? 🤔

[hawkeyetwolf]

@airtower-luna after I commented above, I had the exact same thought as you :D I'm now storing a passphrase in the GitHub repo secrets, and using it to encrypt the secret value with gpg! Still working out some kinks, will try and post back here once complete.

[hawkeyetwolf]

@airtower-luna see my solution using gpg encryption posted below!

https://github.com/orgs/community/discussions/25225#discussioncomment-6888354

[hawkeyetwolf]

Here's the github documention for it for how to do it between jobs/workflows securely:

https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#example-masking-and-passing-a-secret-between-jobs-or-workflows

[rdhar]

BACKGROUND CONTEXT

Although there are now docs on masking and passing secrets between jobs or workflows (as @hawkeyetwolf linked), it didn't meet requirements like:

• Storing and retrieving from a secret store seems a tad over-the-top (as @airtower-luna mentioned).
  • The same goes for encrypted artifact upload/download.
• For ephemeral, temporary OIDC tokens, it's not feasible to dynamically store/retrieve those secrets (as @tanepiper raised).

PROBLEM STATEMENTS

With these factors in mind, the main blockers are:

• Per docs, to prevent accidental disclosures, GitHub Actions redacts any configured secrets as well as common encodings of those values, like Base64.
• For dynamically-generated secrets, those have to remain masked from the caller workflow to the reusable workflow to avoid exposing their their values in the workflow logs.

PROPOSED SOLUTION

1. Before going to output secrets from the caller workflow, Base64 encode the values twice.
   1. This enables GitHub Actions to output the secrets without exposing them.
2. Per docs, pass the encoded values to the reusable workflow as secret inputs.
   1. This enables the reusable workflow accept and treat the encoded values as secrets.
3. In the reusable workflow, decode the values from Base64 twice before masking them.
   1. This ensures that the secrets remain masked in the workflow logs throughout.
   2. They can now be populated as environment variables for use in the subsequent steps of the reusable workflow.

WORKING EXAMPLE

These methods are sourced from TF-via-PR repository, which hosts a reusable workflow to run Terraform commands via PR comments, like a CLI.

As a bonus, any number of secrets can be securely passed into the reusable workflow to be used as environment variables, for example. The repository also contains recent GitHub Actions workflow runs to verify that the secrets remain masked throughout.

# caller-workflow.yml

jobs:
  credentials:
    runs-on: ubuntu-latest
    outputs:
      CREDENTIAL1: ${{ steps.credentials.outputs.CREDENTIAL1 }}
      CREDENTIAL2: ${{ steps.credentials.outputs.CREDENTIAL2 }}
    steps:
      - name: Output encoded credentials
        id: credentials
        env:
          CREDENTIAL1: ${{ secrets.CREDENTIAL1 }}
          CREDENTIAL2: ${{ secrets.CREDENTIAL2 }}
        run: |
          echo "CREDENTIAL1=$(echo $CREDENTIAL1 | base64 -w0 | base64 -w0)" >> $GITHUB_OUTPUT
          echo "CREDENTIAL2=$(echo $CREDENTIAL2 | base64 -w0 | base64 -w0)" >> $GITHUB_OUTPUT

  reusable-workflow:
    needs: credentials
    uses: reusable-workflow.yml
    secrets:
      env_vars: |
        CREDENTIAL1=${{ needs.credentials.outputs.CREDENTIAL1 }}
        CREDENTIAL2=${{ needs.credentials.outputs.CREDENTIAL2 }}

# reusable-workflow.yml

on:
  workflow_call:
    secrets:
      env_vars:
        required: true
jobs:
  parse-credentials:
    runs-on: ubuntu-latest
    env:
      env_vars: ${{ secrets.env_vars }}
    steps:
      - name: Decode credentials as environment variables
        run: |
          for i in $env_vars; do
            i=$(echo $i | sed 's/=.*//g')=$(echo ${i#*=} | base64 -di | base64 -di)
            echo ::add-mask::${i#*=}
            printf '%s\n' "$i" >> $GITHUB_ENV
          done
      - name: Validate credentials
        run: |
          # Secrets are now available as masked environment variable.
          echo $CREDENTIAL1 # or ${{ env.CREDENTIAL1 }}
          echo $CREDENTIAL2 # or ${{ env.CREDENTIAL2 }}

Where:

• base64 -w0: Ensures that the encoded values are outputted in a single line, regardless of the length of the input.
• base64 -di: Decodes the values from Base64, ignoring any newlines from echo'd strings.
• echo ${i#*=}: Removes the key of the key-value pair using parameter expansion, leaving only the value.
• sed 's/=.*//g': Removes the value of the key-value pair, leaving only the key.
• echo ::add-mask::${i#*=}: Masks the value of the key-value pair without outputting.

FLAWS

• If the workflow is (re-)run in debug mode, then secrets from credentials job specifically are output in the workflow log.
• The reusable workflow needs to be configured with the steps under parse-credentials job.

[hawkeyetwolf]

this is great! Thank you for this solution, I dig it.

In my case, it would mean having two workflows for each "real" workflow (one to trigger, and another that receives the secret), which isn't ideal for my project. I'm going to post a separate answer that provides a single action to handle the encryption and decryption of a secret passed between jobs.

[fractiunate]

When i need to export a [dynamic read secret], aka i require secrets: inhert in the caller workflow i cannot use this.

Sadly this also does not work for passing secrets between jobs. When passing between jobs the secret as b64 is exposed in the env variables in the github workflow logs...

Not usable for ciritcal data...

[rdhar]

Hi @fractiunate, you're spot-on, (re-)running the workflow in debug mode does output secrets in the credentials job, where it's isolated. And some level of control is required over the reusable workflow in order to parse the encoded credentials from the caller workflow.

I've now listed both of these flaws in the original post to ensure users are made aware, just as raised elsewhere.

[jshields]

This clearly explains the problem including functionality gaps in GitHub Actions, and is a good solution for many situations, however it will not work for services containers that reference an image from ECR because steps are required to decode the secrets. For it to work with an ECR image, the secret would need to be available as the job is starting.

[hawkeyetwolf]

Here is an example of an action that handles encrypting and decrypting a generated secret, passed securely between jobs in encrypted cache. The steps are:

1. Look for encrypted secret in cache
2. If found, decrypt
3. If not found:
   a. generate secret
   b. encrypt it (gpg symmetric encryption)
   c. save encrypted secret to cache for use by later job

One day I'd like to publish an action that handles the encryption/decryption of a generated secret in a more generic way. But for now, feel free to copy from my Terminus use-case linked above :D

[AndresPinerosZen]

Sadly, this only works if the credentials CAN be decrypted. I'm currently trying to generate dynamic credentials for:

my_job:
    name: My Job
    runs-on: ubuntu-latest
    container:
      image: private-repo/private-image:v1.0.0
      credentials:
        username: oauth2accesstoken
        password: <DYNAMIC_ACCESS_TOKEN_HERE>
   steps:
   ...
   ...

[jshields]

I have the same problem as @AndresPinerosZen . The official docs for aws-actions/amazon-ecr-login show the password being passed unmasked because there is no way to pass a masked output to another job without requiring additional steps to decrypt it. A private ECR image for a container requires that the credentials be available when the job starts, before the steps begin, so additional decryption steps will not work to solve the issue.
https://github.com/aws-actions/amazon-ecr-login?tab=readme-ov-file#run-an-image-as-a-service

On top of that, GitHub Actions does not currently support a custom startup command (only options) for a Docker container, meaning that even simple customizations require a new Dockerfile with a specified CMD, and therefore require an ECR (or other private) image, in closed source contexts like GitHub Enterprise customers.

[runofthemill]

@AndresPinerosZen I found a workaround (though the secret isn't masked) that's specific for Google Artifact Registry + Workload Identity Federation, but the idea should be transferrable for other registries: google-github-actions/auth#309 (comment)

[vegardx]

Could we potentially use a pre-job script to decrypt the values before the job is started? This way you can pass the credentials encrypted, decrypt them as part of the pre-job, and then reference the decrypted values in places like credentials for a container image on a job.

This would only work for self-hosted runners, but at least it would be a step in the right direction. I'm still trying to wrap my head around what exactly all these things are supposed to protect us from, as it seems quite theoretical, and the imaginary solution (their words, not mine) doesn't even address how you would use this in contexts such as using a container registry for container image in a job.

https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/running-scripts-before-or-after-a-job