I have created a scenario where I need a password
property loaded from configtree:
to use for the config server client, which is secured.
I noticed when the configserver:
ConfigDataLoader is not marked optional it will fail because the password is not resolved yet in org.springframework.boot.context.config.ConfigDataEnvironment#processInitial
but only later in org.springframework.boot.context.config.ConfigDataEnvironment#processWithProfiles
see https://github.com/lorenzbaier/spring-config-server-client-test
I think that the properties should be added to the context as soon as they are available at org.springframework.boot.context.config.ConfigDataImporter#load
Comment From: philwebb
This is a little counter intuitive, but is actually an intentional design decision. We don't want to apply the properties to the Environment
until they have all been loaded.
Having said that, the configserver:
import can access already loaded properties as they are available from the Binder
provided to the ConfigServerConfigDataLocationResolver
. The problem is that the current algorithm doesn't deal very well with multi-line imports.
I think we can improve things, but this is quite a complex area of the codebase and we might not be able to do much until Spring Boot 4.0 has been released.
In the meantime, you can workaround the problem by changing your application.yml
to the following:
spring:
application:
name: demo-secrets-config-client
config:
import:
- "configserver:"
---
spring:
application:
name: demo-secrets-config-client
config:
import:
- "optional:configtree:./secret-config-root/"
cloud:
config:
uri: http://localhost:8888
password: # ./secret-config-root/spring/cloud/config/password
server:
port: 9333
This will work because the lower document is fully loaded before the upper one. This gives the ConfigServerConfigDataLocationResolver
a chance to read the configtree
import.
Comment From: lorenzbaier
Ok thanks for the quick reply, I will try the workaround.
Is there any good documentation which covers this? because I could not find any but I think it is a common use case to load some secret from e.g. "configtree" which will be used in a client like the config server
Comment From: philwebb
The documentation isn't great in this area, but I don't think the problem has been raised before. I'd keep the workaround out of the documentation since it looks a little odd and I'd rather fix the underlying problem.