[FEAT] Support for retrieving secrets with configuration options

[rhughes1]

Is your feature request related to a problem? Please describe.

As part of the Terraform workflow, I'd like to be able to dynamically generate credentials (Terraform Cloud, AWS/Azure/GCP, Consul, PKI, etc) so that I can generate short lived credentials for CI/CD purposes. This would be useful for Terraform module testing where you would want to actually deploy the infrastructure in question vs using mocks.

I know it's been clearly documented within the README about the action only supporting GET requests without parameters.

Describe the solution you'd like

After logging into the Vault cluster, there should be a configuration option with the action which allows you to pass in either a role field or a configuration map for the given path.

The role field would be there to resolve the Terraform Cloud, Consul, Nomad, AWS, Azure, and GCP.

The config field would be there to resolve PKI.

Describe alternatives you've considered

One solution would be to write this out in Bash as part of the pipeline. However, this feels like a dirty approach.

[austingebauer]

Hi @rhughes1. Thanks for this request. It looks like we'd be able to support credential generation for a number of our Vault integrations today using GET requests. For example, you should be able to generate dynamic credentials using a GET for Azure, AWS, and GCP secrets engines (+ more). Note that the role parameter is often a component of the URL path and additional input can be supplied as query parameters.

I'm curious if you tried this and ran into issues with vault-action?

[melonger]

@austingebauer, what Ryan explains has been tested, but it's a poke and prod attempt with no real direction or success (other than build custom reusable actions leveraging the Vault binary).

The idea described, would have a two prong affect using dynamic secrets:

1. is for generating dynamic credentials, to which we can use later in other actions
2. using it as a method for auth when doing a secrets extraction (in the KV).

Then, have all tokens and creds revoked in a later custom action (as the current vault-action does not support any form of revocation of tokens or creds) using the Vault binary.

ex: The documentation README, is very limited in explanation for AWS auth or if this is even a capability in tangent. It implies using an id/key, but that's not how it would primarily be used (and would defeat the purpose of the dynamic secrets). Using the IAM Authentication method, generating all the data that the Vault binary performs (vault login -namespace= -method=aws role=) would be beneficial in the payload to be translated into the action itself.

Being able to piggy back off the same "action request" (AWS/Azure/GCP Auth), to then extract data from vault, would be highly beneficial. Rather than currently using the binary to translate the request, extracting the token, applying it to the vault-action using the token auth method and pointing to the secrets wanted to be extracted.

[snocorp]

The PKI portion of this would be solved by #564 but I didn't have a use case for other engines so I kept the changes as minimal as possible.