[ 
https://issues.apache.org/jira/browse/SOLR-12976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681781#comment-16681781
 ] 

Gus Heck edited comment on SOLR-12976 at 11/9/18 6:12 PM:
----------------------------------------------------------

Monitoring leaks is what the metrics stuff is about, right? So that makes 
sense. It's the UI stuff that concerns me. The list of properties should only 
hide things if they are hidden well and good across the board. 

A "schema-admin" role is basically what you are talking about at the end of 
your comment. That's an interesting idea. Probably it should be driven by a 
read-secret-sysprop 
[permission|https://lucene.apache.org/solr/guide/7_5/rule-based-authorization-plugin.html#rule-based-authorization-plugin]
 (or maybe part of the security-read permission?), which would then imply UI 
redaction, Schema update(and other) prohibitions on use of secret property 
expansion (input validation) and secret redaction for responses from API's. I'm 
not yet familiar with the authorization plugin, so I don't quite know what my 
suggestion implies though.


was (Author: gus_heck):
Monitoring leaks is what the metrics stuff is about, right? So that makes 
sense. It's the UI stuff that concerns me. The list of properties should only 
hide things if they are hidden well and good across the board. 

A "schema-admin" role is basically what you are talking about at the end of 
your comment. That's an interesting idea. Probably it should be driven by a 
read-secret-sysprop 
[permission|https://lucene.apache.org/solr/guide/7_5/rule-based-authorization-plugin.html#rule-based-authorization-plugin],
 which would then imply UI redaction, Schema update(and other) prohibitions on 
use of secret property expansion (input validation) and secret redaction for 
responses from API's. I'm not yet familiar with the authorization plugin, so I 
don't quite know what my suggestion implies though.

> Unify RedactionUtils and metrics hiddenSysProps settings
> --------------------------------------------------------
>
>                 Key: SOLR-12976
>                 URL: https://issues.apache.org/jira/browse/SOLR-12976
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: security
>            Reporter: Jan Høydahl
>            Priority: Major
>
> System properties can contain sensitive data, and they are easily available 
> from the Admin UI (/admin/info/system) and also from the Metrics API 
> (/admin/metrics).
> By default the {{/admin/info/system}} redacts any sys prop with a key 
> containing *password*. This can be configured with sysprop 
> {{-Dsolr.redaction.system.pattern=<regex>}}
> The metrics API by default hides these sysprops from the API output:
> {code:java}
>     "javax.net.ssl.keyStorePassword",
>     "javax.net.ssl.trustStorePassword",
>     "basicauth",
>     "zkDigestPassword",
>     "zkDigestReadonlyPassword"
> {code}
> You can redefine these by adding a section to {{solr.xml}}: 
> ([https://lucene.apache.org/solr/guide/7_5/metrics-reporting.html#the-metrics-hiddensysprops-element])
> {code:xml}
> <metrics>
>  <hiddenSysProps>
>    <str>foo</str>
>    <str>bar</str>
>    <str>baz</str>
>  </hiddenSysProps>
> </metrics>{code}
> h2. Unifying the two
> It is not very user firiendly to have two different systems for redacting 
> system properties and two sets of defaults. This goals of this issue are
>  * Keep only one set of defaults
>  * Both metrics and system info handler will use the same source
>  * It should be possible to change and persist the list without a full 
> cluster restart, preferably though some API
> Note that the {{solr.redaction.system.pattern}} property is not documented in 
> the ref guide, so this Jira should also fix documentation!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to