Description
In Spring Boot 3, the Actuator security settings have changed somewhat, specifically with regard to the sanitization of potentially sensitive properties. Part of the reasoning for this (role-based vs. key-based) is given in #32156, which I do not question as being an improvement.
We currently use Spring Boot Admin and require an SSO administration login to see the UI which is populated by a service role with the monitoring role. This and other correctly configured monitoring tools now, per default, would show sensitive fields.
Specifically given a previous config of
management.endpoint.env.show-values=WHEN_AUTHORIZED
and a request matcher similar to the following:
httpSecurity. // ...
.and()
.authorizeHttpRequests()
.requestMatchers("/actuator/**").hasAnyRole("MONITORING")
.and() // ...
which would semantically map to the new:
management.endpoint.env.show-values=WHEN_AUTHORIZED
management.endpoint.env.roles=MONITORING
...would exhibit behaviour that is a drastic departure from the previous one w.r.t. sensitive information.
This is great for development - no doubt, but it was a bit of a shock to see it in action without an explicit and far more prominent warning that there is no default sanitizing function.
Since Spring Boot itself has a very opinionated approach to configuration, why do common-sense approaches allow us to use proper security practices (WHEN_AUTHORIZED with a specific system role) and still have potentially unsafe behaviour? The fact that a developer may need to be able to check a runtime configuration property does not immediately imply that they need access to sensitive values, with a sensible-looking configuration, per default.
IMO it would be much better to require a sanitizing function when WHEN_AUTHORIZED is used, and perhaps - at the very least, provide a NoOpSanitizingFunction that logs a suppressable warning. No one likes a silent breaking change.