-
Notifications
You must be signed in to change notification settings - Fork 41.2k
RabbitProperties addresses field is not sanitized by default and may contain sensitive information #19626
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
I will take a look this evening @mbhave |
Ok - this is only an issue if you in fact set the user/pass in the spring.rabbitmq.addresses: amqp://user:pass@host1:port,amqp://user:pass@host2:port I did not realize I could put the user/pass in the top-level properties (which is sanitized) and still have multiple addresses (but they get their creds from the top-level properties) and leave out of the address such as spring.rabbitmq.username: user
spring.rabbitmq.password: pass
spring.rabbitmq.addresses: amqp://host1:port,amqp://host2:port Should probably add a warning in docs somewhere (even javadoc of the RabbitProperties.addresses) that its not sanitized and user/pass will be shown if included in those fields directly. |
#8293 doesn't work in this case because the property is |
Preventing these types of secrets from being leaked is pretty important. I think the implementation should be updated to support a field named |
We've decided to add |
@mbhave sounds good. Is this something the team wants to handle internally? If not, I will have some cycles this weekend to get an MR together. Just lmk. Thx. |
@Bono007 A PR would be most welcome, thank you. |
@mbhave I see this is on the |
It was fixed in |
@mbhave, PR is in. |
Closing in favor of #19999. |
Problem:
The actuator
configprops
andenv
endpoints showRabbitProperties#addresses
in un-sanitized form.Workaround:
These endpoints expose the
keys-to-sanitize
property and I could set that property to the current defaults plusaddresses
. However, this is not desirable asIt feels like this is something that should be handled out-of-box.
Couple of options:
Update default keys-to-sanitize to include an expression for
addresses
.Add an
additional-keys-to-sanitize
to allow adds to the defaults and set that property in my applications.Add an annotation that can be set on a
@ConfigurationProperties
field (such as@Sensitive
) that would automatically get that field excluded from the endpoint reports.Do nothing. Use the existing
keys-to-sanitize
property w/ the current coded defaults and addaddresses
to it. Repeat this in each application. Update each application when/if the defaults happen to change in the endpoint code.I am happy to submit a merge request for any of these options.
The text was updated successfully, but these errors were encountered: