Feature Request: Option to have Vault store the credential and return it on future requests

[dmedeiros204]

We are currently using the azure secret plugin with dynamic credentials in some of our github pipelines.

The Azure AD replication times have been taken into consideration and an additional wait/sleep has been built into the pipeline to allow for better success rates of the credentials being useable after a vault read.

However as our pipelines expand and we're starting to hit 3600 commits a day each of each would do a read on the vault role that small wait time is becoming increasingly noticeable and a bottleneck to teams.

Looking at the terraform cloud plug-in it offers some functionality with its role to store that credential until the ttyl expires without issue a new api key
https://www.vaultproject.io/docs/secrets/terraform#organization-and-team-roles

Any possibility we can have some similarly implemented so that if a option is enabled in the role configuration itself that it caches the credential instead of generating new each time?

[calvn]

Hi there @dmedeiros204! Would it be possible for you to expand on your use case a bit further? The Terraform Cloud Secrets Engine operate in such a way because of the constraint around only having one active token at any given time. In general, dynamic secrets are expected only be available during the original credentials generation request and are meant to be ephemeral.

However, we'd like to know if this is a similar flow to that of static roles on our Database Secrets Engines and other engines such as the OpenLDAP Secrets Engine, where an existing credential managed by Vault can return the same secret (e.g. the password) for a specific user or resource. More specifically, we'd like to know for you particular use case whether the credentials returned can be pre-existing service principals that are then given to be managed by Vault or whether the request is about a change in behavior for the dynamically generated credentials.

[dwizzle204]

Hi @calvn Azure AD replication has been notoriously inconsistent for our team. Sometimes it appears to replicate fairly quickly and sometimes it can take over 5 minutes. In some case our developers have had to generate dynamic credentials and store them in a keyvalue store so that when they need to run multiple jobs in sequence they don't have to wait 5 minutes each time a new spn is provisioned. My goal above was to eliminate them having to spin up a separate space to cache that credential. The idea is for it to still be a short term but avoid the wait times associated with azure ad replication times. We've also found that if use the other method of pre-creating the spn and just have the vault manage the client_secret actually takes longer to replicate then a brand new spn.

[TimHodkin]

A little off topic, but if you are using terraform to read the azure/creds/role then use this data source as it has the ability to check the creds before they are used. This might help but there would still be the issue of the wait on each run while Azure replicates.
https://registry.terraform.io/providers/hashicorp/vault/latest/docs/data-sources/azure_access_credentials
The check this performs requires the SPN to have access to an azure subscrption to verify the creds are ready for use.

The other way would be what you are already doing. Having longer TTLs (24 hours?) on the roles and performing a first read and storing it in a keypair for use until the TTL expires.

[dwizzle204]

A little off topic, but if you are using terraform to read the azure/creds/role then use this data source as it has the ability to check the creds before they are used. This might help but there would still be the issue of the wait on each run while Azure replicates. https://registry.terraform.io/providers/hashicorp/vault/latest/docs/data-sources/azure_access_credentials The check this performs requires the SPN to have access to an azure subscrption to verify the creds are ready for use.

That's a potential option for terraform runs, having a post task that generates the credential and all child runs do a data call. However that won't work for other pipeline type runs that require credentials not related to terraform.

The other way would be what you are already doing. Having longer TTLs (24 hours?) on the roles and performing a first read and storing it in a keypair for use until the TTL expires.

So that's basically the functionality I'm asking for...

Currently vault creates the credential passes you the client id, and client secret. After which it only tracks the id for the purpose of cleanup. It doesn't store the client_secret. So every read call is a new credential.

What about an option to keep the same client_id and client_secret for the length of the defined TTL? So every read within the TTL returns the same client_id and client_secret. Yes the initial call will potentially still suffer from the replication issues but every other call during the defined TTL would avoid it because it already exists.

[TimHodkin]

What about an option to keep the same client_id and client_secret for the length of the defined TTL? So every read within the TTL returns the same client_id and client_secret.

I like this idea.