Been thinking about the same, but perhaps instead of a generic rule about containing password, we could have a property somewhere for what paths to hide.
Thanks Jan Høydahl for the feedback! I was also thinking of a pattern-based parameter masking for input password. I prepared a patch with a RedactionUtils that I will extend with external parameters and upload it shortly.
I would also like to hide the content of some ZK nodes such as security.json, and there may also be other places where passwords are exposed through props or APIs...
I was not aware of the security.json exposing password, I created a separate jira for that as well (SOLR-10100).
Ideal would be if this could be coupled with Authorization, so that certain info could be controlled through group membership in AuthorizationPlugin?
In general, I would not add password visibility based on privileges. I think passwords should not be revertible, as that would expose them to the reliability of the authorization plugin and the admin users' cautiousness. For me it would somewhat beat the purpose of this jira: reducing the exposure of the security credentials. Do you see any business-case when you would grant certain roles to view these passwords?