Add query parameter to skip property value decryption (e.g. "decryptProperties=false")

[marnee01]

Is your feature request related to a problem? Please describe.
Yes, this is related to a problem. We make use of the endpoint that returns resolved properties in ".properties" format. We do this for our prod profiles for all of our applications once a month before release. We provide these to our dev teams to aid troubleshooting. We can't have the sensitive encrypted property values appear in these files. Therefore, we put the request to the config server in one of our lower environments.

The issue is that when a property references another property which is encrypted, the result is not as we'd like.

Example:

Default File:

SharedPassword=Fill_me_in

application-prd.properties:

SharedPassword={cipher}BobLoblaw
Property1=${SharedPassword}

Then when we get the properties for prd profile, it is returned with the value from the default file:

Property1=Fill_me_in

The reason being that it can't decrypt SharedPassword, it sets it to invalid.SharedPassword. When Property1 is resolved, it finds only the one in the default file. This can be misleading. This is just one example. We get undesired results in different scenarios due to this.

Describe the solution you'd like
We'd like to have the endpoint support a query parameter like decryptProperties. It would default to true. We would call it with false for creating our reports. When false, the endpoint logic would skip the decryption step and leave the values with the {cipher} tag.

And thus, in our example, it would return the value as-is: Property1={cipher}BobLoblaw.

I looked at making this change myself. However, I believe this change would entail touching many subclasses of EnvironmentRepository. I am not set up to test all of those. I am also unsure which of these support encrypted values. Except where it is obvious that it does, it would require more time to investigate than my company would allow me to take.

Workaround
Posting our planned workaround (in case it helps someone else). Our plan is to add @Profile("!noencrypt") to our beans that provide the decryption logic. We will run a special config server with "noencrypt" profile and call that when generating these resolved-properties reports. Note that encrypted properties are returned in their encrypted form, but are not returned with the "{cipher}" tag.

[ryanjbaxter]

I want to make sure I completely understand your use case.

Is it that sometimes you want the properties files to return the decrypted values and sometimes you don't? By default serving plain text files will not return the decrypted values unless you set spring.cloud.config.server.encrypt.enabled=true and spring.cloud.config.server.encrypt.plainTextEncrypt=true. I am assuming you have both set to true? I would think you could run a special config server with these properties set to false and achieve what you need without using the profile you suggested in your workaround.

[marnee01]

Yes, I want to sometimes decrypt and sometimes not. Ideally on the same ConfigServer with a decryptProperties query param.

I wasn't aware of these properties: spring.cloud.config.server.encrypt.enabled=true and spring.cloud.config.server.encrypt.plainTextEncrypt=true. We are not setting them.

I am not discussing the endpoint that provides the original/plain text file. We are calling the one that resolves it all into a final set of properties, resolving variables, then returning in format of .properties, .json, or .yml.

For example, the EnvironmentController method jsonProperties that has the @GetMapping("{name}-{profiles}.json") annotation. I believe there are six methods for this type of request (3 that take a label, 3 that don't, and then for JSON, YAML, and properties format).

I tried setting spring.cloud.config.server.encrypt.enabled=true and spring.cloud.config.server.encrypt.plainTextEncrypt=true in both the application.yml file and the bootstrap file, and it still returned decrypted values. (We're using the old bootstrap file approach still.)

Either way, standing up a new service for this one need is not ideal on our end. However, this might be such an obscure requirement that I understand if it's not worth the effort to implement my feature request here.