Affects: \2.5.x+
Motivation
The org.springframework.boot.actuate.autoconfigure.context.properties.ConfigurationPropertiesReportEndpointProperties and org.springframework.boot.actuate.autoconfigure.env.EnvironmentEndpointProperties classes provide additionalKeysToSanitize, which are sanitized after the defaults. There are cases where sanitizing keys BEFORE the defaults would be preferable.
Example
The database_uri property below is a connection string that includes credentials. Because "database_uri" matches one of the org.springframework.boot.actuate.endpoint.Sanitizer.URI_USERINFO_KEYS but the value doesn't match org.springframework.boot.actuate.endpoint.Sanitizer.URI_USERINFO_PATTERN, the credentials in that property are exposed by the actuator. Attempting to have the whole property value sanitized using additionalKeysToSanitize doesn't work because the Sanitizer has already processed that property as part of the org.springframework.boot.actuate.endpoint.Sanitizer.DEFAULT_KEYS_TO_SANITIZE.
database_uri=jdbc:mariadb://dbhost/dbname?user=dbuser&password=dbpassword
A workaround is to redefine all keys to sanitize in application.properties, which is error prone and brittle to future changes. For example:
management.endpoint.configprops.keys-to-sanitize=database_uri,password,secret,key,token,.*credentials.*,vcap_services,^vcap\\.services.*$,sun.java.command,^spring[\\._]application[\\\\._]json$,uri,uris,url,urls,address,addresses
Proposed Solution
Add an optional initial-keys-to-sanitize property to org.springframework.boot.actuate.autoconfigure.context.properties.ConfigurationPropertiesReportEndpointProperties and org.springframework.boot.actuate.autoconfigure.env.EnvironmentEndpointProperties which is processed before the DEFAULT_KEYS_TO_SANITIZE. Then developers can still leverage the defaults and provide overrides if needed. With such a property, the very complex keys-to-sanitize above goes away and is replaced with
management.endpoint.configprops.initial-keys-to-sanitize=database_uri
Comment From: wilkinsona
Thanks for the suggestion.
Rather than providing a separate property, I wonder if we should prepend the additional keys rather than appending them. I'm struggling to see a downside as, other than the special treatment of URI-like keys which we would be improving, the ordering shouldn't matter.
I'll flag this for team attention as I'd like the rest of the team to take a look in case I have overlooked something.
Comment From: mrgrew
Prepending the additional keys works for me. I'll keep an eye on this issue and look to test the release candidate with this change.
Comment From: mrgrew
...or if I have some spare time I'll create a PR with that change.
Comment From: mbhave
Closing in favor of #32156.