You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Our use case for this action in many scenarios is that we wish to authenticate to Vault via a JWT auth backend, using the ID token provided by Github. We're not interested in the rest of the functionality - we just want the token. We can currently do that with exportToken, but that breaks certain use cases. For example, if you are authenticating to 2 different namespaces, to get 2 different tokens, this will not work because you only get one VAULT_TOKEN environment variable. The same is true if, for example, you wish to authenticate to 2 different environments in the same workflow.
We should be able to use vault-action to obtain a Vault token, and use it in a scoped fashion rather than as a global environment variable. This is especially true as you cannot unset environment variables in a Workflow Job.
Describe the solution you'd like
The action should allow us to (optionally) access the Vault token as an output of the step, so that we can get that Vault token and store it in a well scoped variable rather than a global one. This also reduces the potential for confusion when considering that the VAULT_TOKEN environment variable takes precedence over all else with regards to SDKs and other tooling like Terraform. However, the environment variable should remain supported for existing use cases.
Describe alternatives you've considered
Either write our own, or fork and maintain. Currently, because this caused an issue, we replaced your action (which we were wrapping) with cURL to achieve the same result. But we would like to come back to using the official Vault Action if possible. This is not possible until we can control how we consume that Vault token.
Additional context
PR Incoming
The text was updated successfully, but these errors were encountered:
Hey @TomNorth, thanks for the detailed explanation and PR.
I agree that a well scoped variable is more flexible and secure than a global environment variable. Especially given that VAULT_TOKEN is a variable that has a special meaning that can interfere with other tools as you explained.
I also agree that using the action only to fetch a Vault token to be reused in other steps is a legitimate use case. However people should be careful and aware that once outputted we cannot protect how this token is used. Github Actions rely on a list of best practices for secrets to be adequately protected which are our of our control once the token is referenced by other steps.
I have 1 small suggestion to change on the PR you opened for this issue and I believe there are small merge conflicts. Once these are resolved I'd be happy to merge this enhancement!
Is your feature request related to a problem? Please describe.
Our use case for this action in many scenarios is that we wish to authenticate to Vault via a JWT auth backend, using the ID token provided by Github. We're not interested in the rest of the functionality - we just want the token. We can currently do that with
exportToken
, but that breaks certain use cases. For example, if you are authenticating to 2 different namespaces, to get 2 different tokens, this will not work because you only get oneVAULT_TOKEN
environment variable. The same is true if, for example, you wish to authenticate to 2 different environments in the same workflow.We should be able to use
vault-action
to obtain a Vault token, and use it in a scoped fashion rather than as a global environment variable. This is especially true as you cannotunset
environment variables in a Workflow Job.Describe the solution you'd like
The action should allow us to (optionally) access the Vault token as an output of the step, so that we can get that Vault token and store it in a well scoped variable rather than a global one. This also reduces the potential for confusion when considering that the
VAULT_TOKEN
environment variable takes precedence over all else with regards to SDKs and other tooling like Terraform. However, the environment variable should remain supported for existing use cases.Describe alternatives you've considered
Either write our own, or fork and maintain. Currently, because this caused an issue, we replaced your action (which we were wrapping) with cURL to achieve the same result. But we would like to come back to using the official Vault Action if possible. This is not possible until we can control how we consume that Vault token.
Additional context
PR Incoming
The text was updated successfully, but these errors were encountered: