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.
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_inapplication-prd.properties:
SharedPassword={cipher}BobLoblawProperty1=${SharedPassword}Then when we get the properties for
prdprofile, it is returned with the value from the default file:Property1=Fill_me_inThe 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 totrue. We would call it withfalsefor 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.