Deprecation info

[nicholasgibson2]

@BALAGA-GAYATRI can you provide more information on why this action was deprecated? This action is heavily used by my organization, and the recommended replacement action (azure/cli@v1 action) is not sufficient. If I'm not mistaken this action will treat the returned values as plaintext, not obfuscated secrets. Additionally this action doesn't even work on self-hosted runners (Azure/cli#71).

Even stranger, the official Microsoft documentation is still using get-keyvault-secrets in the code example, but soon after the depreciation someone updated the action marketplace link to a non-verified action maintained by a single developer.

[andyfeller]

@BALAGA-GAYATRI : Could you provide an update on this issue including:

• Reasoning for the deprecation originally

  (there was no issue nor additional details in the changes that explain why this might be necessary)

• Examples of how the suggested azure/cli action might be used as a suitable replacement

  (as @nicholasgibson2 mentions, I'm not 💯 how this is as easy of a migration given the use of outputs versus a free-form script)

I realize this action has largely been in maintenance mode since the few issue template changes you made approximately a year ago. Maybe some of the other contributors might have ideas about this given past experience.

cc: @kanika1894 @tspascoal @rakku-ms @romil07 @artsheiko

[BALAGA-GAYATRI]

@andyfeller
It is not like a total deprecation. The action keeps working even after archiving this repo. So existing workflows are not impacted and new workflows also work fine.
We can come up with more information around the reason for deprecation, roadmaps, and investments in this action soon along with the workaround CLI script.

[lotaezhao]

I would never use a deprecated action in any workflows even if they will still work after archiving. You should provide full details of alternatives or have a replacement action available when issuing a deprecation notice.

In any case I managed to get it working in a rudimentary way with Az CLI below:

env:
  keyvaultName: myvault
  secretName1: foo
  secretName2: bar
steps:
  - name: Az Keyvault Secrets # Using az cli to query keyvault as Azure/get-keyvault-secrets@v1 is deprecated
    id: keyvault
    run: |
      secrets=($secretName1 $secretName2)
      for secretName in ${secrets[@]}
      do
        value=$(az keyvault secret show --name $secretName --vault-name $keyvaultName --query value --output tsv)
        echo "::add-mask::$value"
        echo "::set-output name=$secretName::$value"
      done
    working-directory: ./

Output values have the same names as the secrets and are masked.

[jku-sr]

I would never use a deprecated action in any workflows even if they will still work after archiving. You should provide full details of alternatives or have a replacement action available when issuing a deprecation notice.

In any case I managed to get it working in a rudimentary way with Az CLI below:

env:
  keyvaultName: myvault
  secretName1: foo
  secretName2: bar
steps:
  - name: Az Keyvault Secrets # Using az cli to query keyvault as Azure/get-keyvault-secrets@v1 is deprecated
    id: keyvault
    run: |
      secrets=($secretName1 $secretName2)
      for secretName in ${secrets[@]}
      do
        value=$(az keyvault secret show --name $secretName --vault-name $keyvaultName --query value --output tsv)
        echo "::add-mask::$value"
        echo "::set-output name=$secretName::$value"
      done
    working-directory: ./

Output values have the same names as the secrets and are masked.

this is what I do as well, and it works well between steps of the same job, but when attempting to pass that masked secret to a 2nd job in the same workflow, the value can become unmasked in the GH Logs

[andyfeller]

but when attempting to pass that masked secret to a 2nd job in the same workflow, the value can become unmasked in the GH Logs

@jku-sr: as far as I know, actions/runner will not allow you to pass outputs between jobs that are secrets: https://docs.github.com/en/actions/using-jobs/defining-outputs-for-jobs

[chokhareganesh]

but when attempting to pass that masked secret to a 2nd job in the same workflow, the value can become unmasked in the GH Logs

@jku-sr: as far as I know, actions/runner will not allow you to pass outputs between jobs that are secrets: https://docs.github.com/en/actions/using-jobs/defining-outputs-for-jobs

@andyfeller sharing secret across jobs works, may be you are missing output section for job

  job1:
    runs-on: ubuntu-latest
    # Map a step output to a job output
    outputs:
      output1: ${{ steps.step1.outputs.test }}
      output2: ${{ steps.step2.outputs.test }}
    steps:
      - id: step1