Add support for Key/Value backend version 2 (versioning enabled) #209
Comments
We now provide configuration support for the versioned key-value backend introduced with Vault 0.10.0. This backend uses configuration properties prefixed with spring.cloud.vault.kv and defaults to the secret mount path. It resembles configuration properties from the generic secret backend. Using the versioned key-value backend requires disabling the generic secret backend (spring.cloud.vault.generic.enabled=false). The versioned key-value backend can be configured programmatically through SecretBackendConfigurer.add(KeyValueSecretBackendMetadata.create(…)) which will add data path segments and unwrap nested data elements from the response. See gh-209.
|
Vault folks have removed request downgrading (by using the However, clients have to be aware they are reading from the versioned key-value backend. |
|
I just faced the same problem that the current spring-cloud-vault can only obtain data via vault's K/V version 1, but it seems the default K/V version is 2 from vault 0.10.0, and there're some config tasks to change the K/V version to 1. Thus, may I know to which version/milestone will the new feature of spring-cloud-vault be released? Thanks a lot. |
|
Spring Cloud Vault support for the versioned backend will come with Spring Cloud Vault 2.0 GA (see https://github.com/spring-cloud/spring-cloud-release/milestones for dates). A general notice: Vault versions are still 0.x so we should anticipate future (non-backward compatible) changes. The upcoming 0.10.1 release comes with breaking changes in terms of interop between versioned and non-versioned key-value backends. |
|
I have a stop-gap solution for now that creates the legacy V1 store and confiugres
bootstrap.properties For easy migration to the v2 store I've created another v2 store:
|
|
Request downgrading has been removed. We introduced with the |
mp911de
changed the title
|
I see that this is now supported in VaultTemplate, what about ReactiveVaultTemplate? |
|
As I see, reactiveVaultTemplate is not supported. I think this issue should be reopened |
We now provide configuration support for the versioned key-value backend introduced with Vault 0.10.0. This backend uses configuration properties prefixed with spring.cloud.vault.kv and defaults to the secret mount path. It resembles configuration properties from the generic secret backend. Using the versioned key-value backend requires disabling the generic secret backend (spring.cloud.vault.generic.enabled=false). The versioned key-value backend can be configured programmatically through SecretBackendConfigurer.add(KeyValueSecretBackendMetadata.create(…)) which will add data path segments and unwrap nested data elements from the response. See gh-209.
Spring Cloud Vault is not usable with Vault's versioned Key/Value backend introduced with 0.10.0. The versioned backend is enabled by default which adds another level of severity.
The versioned Key/Value backend entirely changed its API (nested responses, e.g.
{data: { data: { here comes the actual payload }}, changed API paths e.g.secret/data/secret-nameinstead ofsecret/secret-name). It is possible to read from…/data/…paths but referencing secrets requires a${data.…}prefix to unwrap nesting.Using the Key/Value backend allows a uniform API even if versioning is disabled by setting an HTTP header (
X-Vault-Kv-Client: v2) but the client has to be aware it's reading from a key-value backend.Using a newer format (paths, unwrapping) breaks compatibility with older Vault versions and isn't really a good option.
The text was updated successfully, but these errors were encountered: