cloud-vault | PGP-based password manager | Frontend Framework library

As pointed put by Nicoll, With Spring Cloud Vault 3.0 and Spring Boot 2.4, the bootstrap context initialization (bootstrap.yml, bootstrap.properties) of property sources was deprecated. This can be fixed in one of the 2 ways

1. Use Spring Boot 2.4.0 Config Data API to import configuration from Vault
2. Enable the bootstrap context either by setting the configuration property spring.cloud.bootstrap.enabled=true or by including the dependency org.springframework.cloud:spring-cloud-starter-bootstrap

1. Use Spring Boot 2.4.0 Config Data API

Move bootstrap.yml configuration to application.yml and define spring.config.import to import all profiles. And it looks like below

When you get an error about could not resolve dependencies in gradle, then there are several things you need to check.

1. Proxy settings (should be inside gradle.properties)
2. Permission for creating directories (particularly in %GRADLE_HOME%\caches\modules-2\files-2.1)

For the problem of proxy setting, simply set values for the following fields inside gradle.properties

You are missing the annotations on DatabaseConfig.java

Which will be something like this.

I fixed this issue after updating my vault policy with the below configuration:

The root cause of the problem can be found form this error message:

It was the policy setting. I updated it to below and it worked! Specific path instead of *.

Spring Cloud Configuration integrations use the bootstrap context for their configuration. Bootstrap context is configured before spinning up the application context so configuration integrations can load and initialize PropertySources that are then used in the application context.

As a consequence, rename your application.properties to bootstrap.properties.

The expiry threshold controls the renewal time at which the lease is renewed.

For example: it seems pretty clear to me that if the lease TTL is 10 minutes, and if the expiry-threshold is set to 1 minute, then 9 minutes after the lease is acquired spring-cloud-vault would renew the lease.

Your understanding is correct.

What's about min-renewal?

When the remaining validity time of your lease is less than 1 minute (say 30 seconds), then the calculated renewal time would be 30 seconds in the past (or now, as we cannot schedule things to happen in the past). min-renewal helps to debounce renewal requests. This is because, in such a scenario, refresh happens immediately.

Once renewed, SecretLeaseContainer schedules a subsequent renewal that reports a lease validity of slightly less than 30 seconds. We don't want to create a loop that hammers your Vault server with renewal requests if the remaining lease duration is less than expiry-threshold.

Example:

• expiry-threshold: 60 seconds
• min-renewal: 10 seconds

The following list of events shows with a time correlation what happens at which time assuming the TTL is final and cannot be extended:

• 10:00:00 Lease obtained. TTL 10 minutes (600 seconds). Schedule lease renewal in 9 minutes (10 minutes TTL - 1 minute expiry threshold -> 9 minutes)
• 10:09:00 Lease renewed. Remaining TTL 1 minute (60 seconds). Schedule lease renewal in 10 seconds (1 minute TTL - 1 minute expiry threshold -> 0 minutes. Fall back to 10 seconds min-renewal as that is the larger value -> 10 seconds).
• 10:09:10 Lease renewed. Remaining TTL 50 seconds. Schedule lease renewal in 10 seconds (50 seconds TTL - 1 minute expiry threshold -> -10 seconds. Fall back to 10 seconds min-renewal as that is the larger value -> 10 seconds).
• (continue until reaching 10 seconds)
• 10:09:50 Lease renewed. Remaining TTL less than 10 seconds. Min-renewal is greater than the remaining TTL and the lease is considered expired.

Example where expiry threshold is greater than min-renewal:

• expiry-threshold: 5 minutes (180 seconds)
• min-renewal: 6 minutes (360 seconds)

The following list of events shows with a time correlation what happens at which time assuming the TTL is final and cannot be extended:

• 10:00:00 Lease obtained. TTL 10 minutes (600 seconds). Schedule lease renewal in 6 minutes (10 minutes TTL - 5 minute expiry threshold -> 5 minutes. Min-renewal is set to 6 minutes to issue a renewal at most once in 6 minutes -> 6 minutes)

• 10:06:00 Lease obtained. TTL 4 minutes (360 seconds). Schedule lease renewal in 6 minutes (4 minutes TTL - 5 minute expiry threshold -> -1 minutes. 6 minutes min-renewal as that is the is greater than the remaining TTL so the lease is considered expired)

As I mention in my response to spensergibb, I have had some success in resolving this myself. Based on his comments I will clarify my intent as it will help with a common understanding of the issue. I am attempting to do two things:-

1. Stand up a configuration server that uses Vault as a backend, (as opposed to the default GIT backend) and expose the Vault API to client applications (over TLS) so that they can retrieve their own secrets. I do not want all my client applications to connect to Vault directly. I want them to get their configuration from a config server by having the config server connect to Vault. Until last night I was unable to achieve this goal, unless I set everything up as default with TLS disabled and using loopback address, port 8200 for the Vault software etc. Obviously defaults are not practical for any of our deployed environments. I will mention that the link posted by spencergibb does help me understand why this was not working but the subtlety of the reason is why I missed it before. Read on for my explanation.

2. I want the config server to configure itself from Vault directly. That is, connect to Vault via Spring Cloud Vault Config. This worked right away for me as described in the documentation. However this goal is somewhat trivial as I do not have a real use case at this time. But I wanted to understand if it could be done since I saw no real reason why not and it seemed like good first steps in integrating Vault.

The distinction between these two capabilities helped me understand that the problem derives from the fact that Spring Cloud Config Server and Spring Cloud Vault appear to be using two different beans to inject the Vault configuration properties. Spring Cloud Config Server uses VaultEnvironmentRepository annotated with @ConfigurationProperties("spring.cloud.config.server.vault") and Spring Cloud Vault uses VaultProperties annotated with @ConfigurationProperties("spring.cloud.vault").

This caused me to add two different configs to my bootstrap yml.