-
Notifications
You must be signed in to change notification settings - Fork 41.2k
Programatically Declare "keys-to-sanitize" #27296
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Have you seen the support that we added for this in 2.5? |
Correct me if I'm wrong but that feature still requires yml/properties to be set. I'm not sure how that could be used by a custom "starter" library to define additional keys to sanitize. |
You can call |
Judging by the 👍, I think we're good here. Closing as a duplicate of #25384. |
sorry, for the delay. I was just testing a few things and you're right, we're good here. Thanks for your help. |
Problem I am looking to solve:
I am building a library that exposes configuration properties and some of these configuration properties would be seen as sensitive. So we'd want these properties to be masked on the
/configprops
endpoint. I would prefer for the library to be the source that declares these properties as sensitive and not push that responsibility down to each spring boot application using this library.Current Solution
Each application using this library needs to be aware that they need to update the
management.endpoint.configprops.keys-to-sanitize
property to ensure sensitive information is not leaked. This results in this responsibility being managed in many places, instead of one.Proposed Solution(s)
Below are a couple suggestions but more than welcome to suggestions.
1 .Introduce a mechanism to define additional
keys-to-santize
programmatically.2 .Introduce a way to tag a field within a
@ConfigurationProperties
class as "should be santized"More than happy to find out this functionality already exists in Spring Boot and I've just missed it.
The text was updated successfully, but these errors were encountered: