Make properties vault.addr and vault.uri equivalent

[ae6rt]

Vault defines an environment variable VAULT_ADDR to hold the Vault URL for the vault command line reference client. Spring Vault defines an equivalent property vault.uri in its EnvironmentVaultConfiguration class.

Is it reasonable to enhance EnvironmentVaultConfiguration so that it treats vault.uri and a proposed vault.addr as equivalent, given VAULT_ADDR is an existing well-known name in Vault operation?

[mp911de]

From Vault-only perspective, it's a neat feature but that easily opens a can of worms as there are a lot of other properties (VAULT_TOKEN, SKIP_VERIFY, ...) that could be supported.

From a Spring perspective, it's common to have well-defined properties and a tool like Spring Vault has a single preferred approach to configuration. A more sophisticated approach features Spring Boot with property source ordering and config property normalization.

Can you tell us a bit of background where this proposal stems from so we can learn about the use-case?

[ae6rt]

Thanks, Mark.

If I am a Vault (human) operator, I want to put a common set of Vault environment variables into a client process environment and have those processes honor those standard names. No matter if the client is Java, Go, bash, or the Vault native reference client, I figured I could do no better at naming than the Vault docs themselves do. So it would be a nice creature comfort if all client species could honor the names Vault itself chooses for core Vault config. Having to configure Spring clients with vault.uri but native Vault clients with the equivalent of vault.addr (VAULT_ADDR) means I have to use different names for different clients to convey the same information.

My Spring is pretty rusty, so there may be a way I can elegantly affect the translation under the covers so my users don't have to know much about what I consider canonical names. But I'd rather not have to do that.

I also realize there are other VAULT_ -like properties Spring defines that Vault does not, which I (guess) think is fine(?).

Hope this helps clarify where I'm coming from (and realizing it may possibly not).

[mp911de]

Thanks a lot for the insight. From that perspective, it would make sense to investigate which Vault-supported environment variables apply also to Spring Vault and try to use these as fallback if the primary property defined by EnvironmentVaultConfiguration is not set.

We should not try to apply property name translation from system properties to environment variables, rather use constant env variable names.

Do you want to submit a pull request?

[amit181291]

@mp911de I have analysed the file EnvironmentVaultConfiguration and found out that only 2 vault specific properties are present in the file "vault.uri" and "vault.token" . Is there any other file where configuration are there (I couldn't find one).
Please let me know what should be the ideal way to implement the fallback. Shall we deprecate the method and add another one with "vault.uri" replaced to "vault.addr" or in the same method we can do something like this :

String uri = this.getProperty("vault.uri") ? this.getProperty("vault.addr") : null ;

If there is any other convention we follow in this project please let me know , i will be happy to take this up.

[mp911de]

vault.addr is the Spring Boot equivalent of the VAULT_ADDR environment variable. Since Spring Vault builds on top of Spring Framework and not Spring Boot, we need to fetch the VAULT_ADDR environment variable. Similar goes for VAULT_TOKEN, VAULT_NAMESPACE (not yet supported, but it would make sense), VAULT_CLIENT_CERT, and VAULT_CLIENT_KEY (both SslConfiguration).

Let me know whether that helps.

[DragonFSKY]

This is an older issue, but it still seems relevant and marked as ideal for contribution. I opened a small draft PR based on the earlier guidance to support VAULT_ADDR as a fallback for vault.uri, without introducing vault.addr or generic property-name translation.

Happy to adjust the scope or approach if you prefer a different direction.