Use versioning (Key Value backend v2) features for configuration properties

[mp911de]

We should investigate how and whether it makes sense to use Vault's versioning features to consume older versions of secrets through the versioned Key-Value backend.

[suhas-joshi]

I see this as a valuable feature from vault and needs to be part of spring-vault as well. Some part of code is already there to support this function. (class VaultVersionedKeyValueTemplate-doRead() method. String secretPath = version.isVersioned() ? String.format("%s?version=%d", createDataPath(path), version.getVersion()) : createDataPath(path); isVersioned code public boolean isVersioned() { return version > 0; } Will you please let us know if there is much work needs to be done?

[mp911de]

The main question here is how we want to address versioning. Specifying a static version bears little complexity. Using Vault in combination with rotation is a much more interesting arrangement.

Incurring dynamic decisions about a secret version to use reflects a more natural approach to deploy configuration changes without the need to shutdown/restart the actual application.

[mp911de]

For now we decided to not do anything about versioning. We will revisit this topic at a later time with real use-cases and requirements.

[dspaeth-breuni]

Hi, has there been any update on this?

Currently I got a use case for this feature. I want to rotate my secrets. For instance, when you have Basic Auth within my app, I can update the password within vault for the server. Before I notify all the clients of the change.

When a client tries to connect with an old password, because this client hasn't been restarted yet or is not using vault. I can check the old password version.

Within vault I can specify how many numbers of secrets I want to keep. The really old versions will not be allowed anymore. Further more I can use the metadata to specify a valid until date to expire old versions within my app.

It would be really nice to have such a feature.

[mp911de]

How would you configure the application? With a static variant (vault://my/secret?version=42), we could target only a particular version but we do not have any indicator how or when to switch to a different/the latest version.

[dspaeth-breuni]

I don't know if it is possible, but I think of some thing like this:

@Value("${security.users.password}")
 private String password;

then it should use the current version.

and when it is like this:

@Value("${security.users.password}")
private VaultKV2 password;

I would expect an object containing all versions (lazy loaded?) with all meta data

[mp911de]

In a scenario, where you have:

@Value("${security.users.token}")
private VaultKV2 token;

@Value("${security.users.password}")
private VaultKV2 password;

calling something like token.getLatest() and password.getLatest() can quickly result in a race condition where the latest versions are no longer consistent.

In any case, this is an interesting approach and I'm going to reopen the ticket.

[dspaeth-breuni]

calling something like token.getLatest() and password.getLatest() can quickly result in a race condition where the latest versions are no longer consistent.

good we have version ;)

in this case you need to specify who the master is

token_current = token.getLatest();
password_current =  password.getByVersion(token_current.getVersion());

this requires that both have the same version.

Or meta:

token_current = token.getLatest();
password_current =  password.getByMetaTag(token_current.getMetaTag("xyz"));

[AndreKoepke]

How would you configure the application? With a static variant (vault://my/secret?version=42), we could target only a particular version but we do not have any indicator how or when to switch to a different/the latest version.

This solves my issue.
Maybe my is use-case is a bit different from @dspaeth-breuni because we need versioned secrets for the app (to use e.g. external systems) and not that a user tries to authenticate with old passwords.