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

Chris M. Hostetter commented on SOLR-15525:
-------------------------------------------

[~thelabdude]- i'm a little late to the party, but i'm curious why you 
implemented this as additions to VMParamsAllAndReadonlyDigestZkACLProvider and 
VMParamsSingleSetCredentialsDigestZkCredentialsProvider instead of just writing 
new impls?

The existing impls have it right in their name that they read the 
ACLs/credenetials from VMParams ... it seems like this new logic would make 
more sense in some FileBasedZkACLProvider and FileBasedZkCredentialsProvider ? 

(either that, or change the impls so that after reading from the file, they 
still checked the same sysprops to override/augment the file – so for example: 
you could put the passwords in the file but leave the usernames in sysprops on 
the command line ... then it would make more sense to have this functionality 
in the existing classes)
----
In general though i feel like if we're going to provide out of the box support 
for reading credentials and ACLs from a file, we should consider "thinking 
bigger" then just a simple properties file, and have something that can specify 
multiple acls of various types?

(i've been talking with some users who want to be able to do rolling restarts 
where they rotate credentials w/o risk of some solr nodes creating znodes that 
other solr nodes can't read during the rolling restarts, and having the ability 
to use a structured file to configure more then just one "ALL" and one "READ" 
ACL seems promising ... but again: i suppose that could be be done in other 
impls of the ACL/Crednetials Providers  if you feel strongly about also having 
a "simpler" Properties file based impls)

 

(Also, FWIW: see SOLR-15548 .. the fact that you had to modify two Provider 
classes, which users have to configure separately in order for any ACLs to 
work, seems insane to me)

> Provide zkCredentialsProvider and zkACLProvider that loads credentials from a 
> file or env vars instead of sys props
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: SOLR-15525
>                 URL: https://issues.apache.org/jira/browse/SOLR-15525
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: security
>            Reporter: Timothy Potter
>            Assignee: Timothy Potter
>            Priority: Minor
>             Fix For: main (9.0), 8.10
>
>          Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> Currently, the {{VMParamsSingleSetCredentialsDigestZkCredentialsProvider}} 
> and {{VMParamsAllAndReadonlyDigestZkACLProvider}} load ZK credentials from 
> Java system properties. Solr should provide an alternative impl to load this 
> information from a file (and maybe env vars too). This avoids leaking the 
> credentials in the JVM system properties that get logged as well as shown in 
> the UI.
> It would also be nice if this file could store the credentials encrypted, as 
> suggested by SOLR-11655, however that requires a global encryption password 
> (such as http://www.jasypt.org/) so is merely security through obscurity b/c 
> anyone with shell access could track down this encryption password and 
> decrypt the ZK credentials in the file. Of course every Solr node has its own 
> private key for the PKI auth frmk, but that's not helpful for this problem 
> because the encryption key needs to be shared among all the nodes so they can 
> decrypt the ZK creds. So I'm going to skip that part for now and just 
> implement loading the plain-text creds from a file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

Reply via email to