[FEAT] Workflow scoped secret management

[domingogomez-asto]

Is your feature request related to a problem? Please describe.
Vault secrets can be accessed in a given step of a job and then they are available for the context of that job (subsequent steps). Unfortunately if you try to downstream secrets from one job to another job they get skipped or leaked depending if you set-mask them or not. That is GitHub Actions current behaviour and is probably a sensitive one but leaves little options but accessing vault from every job you need the secret or persist the secret as files in your workspace.

The idea is having workflow scoped secrets.

Accessing vault on every job is not a problem, just a bit verbose and probably fine for secrets whose scope is the repository (every workflow run). But there isn't specific support for secrets that are cascaded between jobs and whose scope is the workflow only.

Describe the solution you'd like
What I would love is an action that takes some github workflow id and creates a vault policy and secret for it. Then on every job that action loads as env variables (and set-mask) the workflow secrets. At the end of the job the post-action updates to the workflow secret the env variables on $VAULT_SECRETS (in a kind of similar way you can export to $GITHUB_ENV).

In a nutshell, an action that exposes as env variables all the fields of the workflow secret and updates them at the end of every job.

I'm not sure if this behaviour is generic enough to be supported by this action or maybe a new one, unfortunately composed actions are not yet supported by GitHub.

Describe alternatives you've considered
"Manually" manage get/set secrets at the beginning and end of each job.

Additional context
Forgive me if the aim of this request is beyond the scope of this project. Feedback on possible solutions also appreciated.

[vinay-gopalan]

Hi @domingogomez-asto! Apologies for the delayed response and thanks for opening this FR!

The vault-action plugin is meant to be a read-only action, and in general is not meant to modify Vault’s state (the only exception in this case might be the token). Since this FR expects vault-action to modify the Vault state, this is currently out of scope for this project. This could be added as a separate GitHub Action.

Please feel free to open a new issue if you would like to bubble up or continue the conversation, but for now we are going to close this issue since it is deemed out of scope. Thanks!