We have a Spring-Boot application in which we are using Eureka to discover Spring Cloud Config and retrieve configurations. We are integrating Vault to inject secure/sensitive information and are experiencing issues with loading and resolution of parameters. The project which we are using as Vault client is vault-spring-boot-starter and it works great as long as we aren't using it together with config-server via eureka.
In specific, the Eureka access URL contains parameters/credentials which are retrieved from Vault. With all of the components enabled, the Eureka request fails when DiscoveryClient attempts to access the URL in which the parameters haven't yet been populated/replaced.
( Example: http://${user}:${pass}..... )
Trying to specify @Order and
@AutoConfigureBefore({EurekaClientAutoConfiguration.class, DiscoveryClientConfigServiceAutoConfiguration.class})
in the vault-spring-boot-starter's VaultBootstrapConfiguration do not seem to have any impact. I believe that the issue is related to the ordering in which the PropertySources are processed, but I'm not able to successfully inject the Vault's PropertySource ahead of Eureka's. How can we instruct the custom/Vault PropertySourceLocator logic to execute before DiscoveryClient and configuration server access?
Update
We are using spring-cloud version Angel.SR6.
I've added the @Order(Ordered.HIGHEST_PRECEDENCE) annotation to VaultPropertySourceLocator as recommended, but the parameter resolution still doesn't work. With Spring debug logging enabled I believe that the Vault PropertySource is actually there, but for some reason isn't being used. I've modified the code so that VaultConfiguration implements SmartLifecycle and Ordered (with order=0 and phase=Integer.MIN_VALUE) which could be affecting things. I'll have to do more debugging to try to isolate what is going on.
I was able to resolve my issue. I tried few different approaches including Spring AOP and LTW which didn't work as trying to instantiate the aspects too early - in order for the VaultPropertySource to be available prior to Eureka's DiscoveryClient making a call.
My working solution includes:
For instantiating the Vault beans earlier than Eureka bean and configuration starts instantiating:
@Ordered
or implementing PriorityOrdered
in the VaultPropertySourceLocator
. My VaultPropertySourceLocator
also includes implementing SmartLifecycle
as I was seeing nondeterministic output with parts of Eureka bean instantiation sometimes taking place ahead of Vault beans. My order is Ordered.HIGHEST_PRECEDENCE
and phase is Integer.MIN_VALUE
.For registering VaultPropertySource
as a PropertySource that is used to resolve parameters when Eureka beans/configuration wiring takes place:
VaultPropertySource
which self-registers itself in the list of the environment's PropertySources and is there when Eureka beans instantiate and sets the serviceUrl
property during instantiating and unwrapping/resolving EurekaClientConfigBean
properties.If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With