[
https://issues.apache.org/jira/browse/SOLR-15525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Potter resolved SOLR-15525.
-----------------------------------
Resolution: Fixed
> 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: 2h 50m
> 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: [email protected]
For additional commands, e-mail: [email protected]