Disable requesting secrets from paths without active profiles

[djkeh]

Is your feature request related to a problem? Please describe. According to the reference, generic backend tries to scan available vault secrets following these rules:

/secret/{application}/{profile}
/secret/{application}
/secret/{default-context}/{profile}
/secret/{default-context}

so if I have a single secret in vault server with default application name like this:

secret/application

and if I am running the spring boot project in alpha profile, spring cloud vault tries at least 2 requests.

Created GET request for "https://vault.server:8200/v1/secret/application/alpha"
Created GET request for "https://vault.server:8200/v1/secret/application"

I see the second trial stands for default setup just in case there's no active spring profile. I understand this is reasonable, but for me it may sometimes become a little bit redundant. What if I don't want to place a default secret in path secret/application because the active profiles are always guaranteed? Still does spring cloud vault try to reach and fail with http status code 403 or 404, as the request is forbidden or the secret is not even there.

Describe the solution you'd like I want to manually control the behavior of requesting vault secrets from various paths.

Describe alternatives you've considered One example I came up with is to have control with properties like:

spring.cloud.vault:
    secret-without-profile: (true/false)

if false, the scanning behavior of spring cloud vault would be:

/secret/{application}/{profile}
/secret/{default-context}/{profile}

Additional context Before asking this question, I found a conversation #179 Thanks.

[mp911de]

Thanks for your effort. We have VaultConfigurer and SecretBackendConfigurer in place for fine-grained configuration of config backends. The default context can be disabled by configuring it to a empty value. Everything beyond that point is too specific for a global configuration.

That being said, we’re not going to add further configuration properties at the moment but rather wait until this feature request gets at least another ten votes.

[djkeh]

I understand. I hope this is still worth voting, but for now I agree that we can close this issue. Thank you for your kind explanation.

[djkeh]

@mp911de one another quick question, is it not possible to use Spring Cloud Vault version 1.1.x on Spring Boot version under 1.5? I found information from Spring Cloud intro page that says Spring Cloud Camden runs on Spring Boot 1.4, and in starter list of Camden there's no Vault. Seems like Spring cloud Vault starts from Dalston, and it runs on Boot version 1.5. If I force to do it, I will see the exception message Cannot find class [org.springframework.boot.autoconfigure.context.PropertyPlaceholderAutoConfiguration], because it's not there in Boot 1.4.

Somehow I managed to do it, however, now I feel like there's no option to use cloud Vault on Boot 1.4.

• https://spring.io/projects/spring-cloud

[mp911de]

Spring Cloud Vault was introduced with Spring Cloud Dalston which requires Spring Boot 1.5.

Boot 1.5 is EOL since August 2019. You could try using Spring Vault 1.x with Spring Boot 1.4 as these dependencies should not conflict. In any case, you would be required to configure the property source yourself.

[wsams]

I was about to create an issue about this and discovered this one. I was going to suggest two new properties. One to define the exact backends, and another the exact profiles to use.

spring.cloud.vault.kv.use-paths: /secret/{application}/{profile},/secret/{default-context}
spring.cloud.vault.kv.use-profiles: dev

I have the following defined,

spring.profiles.active: dev
spring.cloud.vault.kv:
  enabled: true
  backend: dept/div/team
  application-name: appname
  default-context: appname/all

My application has read access to these two paths/secrets,

dept/div/team/appname/dev
dept/div/team/appname/all

So I'm getting a 403 for things like dept/div/team/appname/all/dev and dept/div/team/appname. And additionally other profiles may be active that I don't want used.

Thanks, adding my vote.

[nublikasa]

We need this as the default behavior causes a lot of unnecessary logs. Thanks

[mp911de]

Probably, the easiest approach would be introducing spring.cloud.vault.generic.profiles/spring.cloud.vault.kv.profiles defaulting to spring.profiles.active.

[bhattankit]

@mp911de -- Setting default-context or backend to empty throws an error. Is there something wrong I am doing?

[mp911de]

The override spring.cloud.vault.kv.profiles is now in place. Please give it a try.

[igavrysh]

Even after setting spring.cloud.vault.kv.profiles equals to empty string, application still checks secret/application path upon launch

[Mcfloy]

You can manually set the vault secrets to load with a quick workaround. Let's my application is named my-app in the yml and you want to load the config, config-a and config-b secrets instead. (No space between the names, it's case sensitive)

spring.cloud.vault:
  kv:
    enabled: true
    default-context: config
    application-name: config-a,config-b

Now if you want to only want to load one config specifically, just use the same value on default-context and application-name like this:

spring.cloud.vault:
  kv:
    enabled: true
    default-context: custom-secret
    application-name: custom-secret

You don't need to use default-context or application-name outside of this for "manual" retrieving from Spring Vault. Though I would recommend keeping the spring.application-name for yourself, Spring Vault won't try to load it anyway.