spring-cloud-config: Cannot override encrypted properties in the repository using plaintext properties locally
Version: Spring Cloud Version Finchley.RC1
Problem: Cannot override encrypted properties in the repository using plaintext properties locally with spring.cloud.config.override-none=true and client side decryption.
Case: We have a plan to store all configuration in our git config-repo (served by config-server), and have the ability to override properties locally in the clients application.properties for development/testing without requiring pushing branch with configuration changes. Client side decryption is used as well.
We noticed that we could not override remote ciphers with local plaintext properties (However local ciphers do seem to override correctly).
For example: the remote config-repo will server a spring.datasource.password={cipher}abc123 (with the encrypted production password), but we want to be able to specify spring.datasource.password=mypassword for local development in our IDE’s application.properties and override regardless of profile activation.
Sample project to recreate the issue: https://github.com/jamorin/spring-cloud-config-server-issue
Start the configserver and then start the democlient. The democlient will log
2018-05-15 13:21:54.821 INFO 23141 --- [ main] c.e.democlient.DemoclientApplication : prop.cipher: Overriden, Hooray!!!
2018-05-15 13:21:54.821 INFO 23141 --- [ main] c.e.democlient.DemoclientApplication : prop.plain: I still exist but should have been overriden :(
I hope this explanation makes sense. I guess the problem can be avoided by moving encrypted properties into profile specific files, and not using those profiles locally. However, it was just confusing when we ran into this behavior, and would be nice if overriding worked regardless of mixture of plaintext and encrypted values.
About this issue
- Original URL
- State: open
- Created 6 years ago
- Reactions: 4
- Comments: 16 (6 by maintainers)
I agree, this is something different, because after some more testing I found out that the overriding of
security.user.passwordindeed does work.