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}}

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

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.

Found out a trick 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`

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 DevSecTop/TF-via-PR (permalink) 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.

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