Cannot override encrypted properties in the repository using plaintext properties locally

[jamorin]

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.

[ryanjbaxter]

Seems like this was also the behavior in Edgware as well, correct?

[ryanjbaxter]

I know why this does not work as you expect it would. Decrypted values are listed first in the property source list (they are actually extracted from the other various property sources and added to their own property source). Therefore regarless of whether you have spring.cloud.config.overrideNone set or not the decrypted value takes precedence. When you have a property that is decrypted both remotely and locally than things workout because we first decrypt the remote properties and then decrypt the local properties.

We could maybe do some checking as to see if we allow local overrides and if that property exists locally unencrypted dont add it to the decrypted property source list. However this seems like a very narrow edge case. Maybe if others run into the same issue they can comment here and give us a better idea if this is run into more often than we think.

[martinvisser]

I have the same problem here. We have an encrypted password stored for the config server. Locally this is overridden by just a plaintext value. In our case it's the property security.user.password that gives this error: No decryption for FailsafeTextEncryptor. Did you configure the keystore correctly?

For now I can handle this in our application by using encrypt.fail-on-error: false

BTW This is in Edgware

[ryanjbaxter]

Doesnt sound like this is the same issue

[martinvisser]

I agree, this is something different, because after some more testing I found out that the overriding of security.user.password indeed does work.

[fahimfarookme]

We avoided the same issue by moving encrypted properties (and config-repo url as well) to environment variables/ CICD tools - and then got .properties to read from there. i.e. having local env vars with plaintext properties.

spring.datasource.password=${env.var.xyz}

[indraneelb1903]

https://stackoverflow.com/questions/50710981/spring-cloud-config-with-spring-boot-1-4-5-precedence-of-encrypted-properties Same issue here.

[marcingrzejszczak]

Is the problem still there in Finchley.RELEASE?

[spring-projects-issues]

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.

[holandaleo]

I'm having the same issue with Finchley.SR2.

[spencergibb]

@holandaleo Can you provide a complete, minimal, verifiable sample that reproduces the problem? It should be available as a GitHub (or similar) project or attached to this issue as a zip file.

[holandaleo]

A few working/nonworking scenarios, always running with --spring.profiles.active=developer,local

Scenario 1: fails (expected: pass) :warning:

file application.yml:

spring:
  profiles: developer
  datasource:
    password: '{cipher}something-that-decrypts-to-wrong-dbpass'

file application-local.yml:

spring:
  datasource:
    password: 'valid-db-password'

Scenario 2: pass (expected: pass) :heavy_check_mark:

file application.yml:

spring:
  profiles: developer
  datasource:
    password: 'wrong-db-password'

file application-local.yml:

spring:
  datasource:
    password: 'valid-db-password'

Scenario 3: pass (expected: pass) :heavy_check_mark:

file application.yml:

spring:
  profiles: developer
  datasource:
    password: '{cipher}something-that-decrypts-to-wrong-dbpass'

file application-local.yml:

spring:
  datasource:
    password: '{cipher}something-that-decrypts-to-correct-dbpass'

Scenario 4: pass (expected: fail) :warning:

file application.yml:

spring:
  profiles: developer
  datasource:
    password: '{cipher}something-that-decrypts-to-correct-dbpass'

file application-local.yml:

spring:
  datasource:
    password: 'wrong-db-password'

Scenario 5: fails (expected: fail) :heavy_check_mark:

file application.yml:

spring:
  profiles: developer
  datasource:
    password: '{cipher}something-that-decrypts-to-correct-dbpass'

file application-local.yml:

spring:
  datasource:
    password: '{cipher}something-that-decrypts-to-wrong-dbpass'

[holandaleo]

@spencergibb , I'll work on a complete project on the weekend and make it available on github.

[holandaleo]

Hi @spencergibb Here is a project using spring boot 2.0.8 and spring cloud finchley.sr2. You can see that DemoApplicationTests .java has 3 scenarios. All of them were supposed to pass, but case2 fails. https://github.com/holandaleo/spring-cloud-bootstrap-issue

[holandaleo]

Adding a note here that this issue is not necessarily at spring cloud config. I'm not using spring cloud config server for this demo project that reproduces the issue. Could be the case that the bug is under spring-cloud/spring-cloud-config itself. I haven't had a chance to look deeper on dependencies etc. I added the sample here because this issue is google friendly. I also didn't want to open another issue under spring-cloud/spring-cloud-config without knowing where it really is.

[The-Crocop]

Same Here Any Suggestion on when this will be fixed or how we can put cipher properties after env variables in terms of precedence ?