[
https://issues.apache.org/jira/browse/SOLR-4580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13602146#comment-13602146
]
Per Steffensen commented on SOLR-4580:
--------------------------------------
Early implemention thoughts
* You have to actively do something to use protective ACLs - default will still
be ZooDefs.Ids.OPEN_ACL_UNSAFE allover
* Separate ACL-provider/factory component (for nice "separation of concern")
with a default implementation (in time, if someone needs it, we can expose the
ACL-provider/factory-implementation to be replaceable/pluggable from "the
outside" - e.g. though solrconfig.xml). Default implementation could be
something like this:
** Operate with two sets of "digest"-credentials (username/password-based) to
be used for ZK access - internal-user and client-user
*** internal-user: Will be allowed to do anything in the solr-space in ZK
*** client-user: Read-only. Either allowed it to read-only anything in the
solr-space in ZK, or tighten it a little and only allow it to read-only
"whatever is necessary for a CloudSolrServer to operate" (e.g. not access to
read Overseer stuff and configuration stuff)
* Solr-nodes will need to know about both internal-user and client-user
credentials
** internal-user to be used for its own connetions to ZK, and to create
"everything"-ACLs for this internal-user on every znodes it creates
** client-user to create "read-only"-ACLs for this client-user on every (or
selected) znodes it creates
* CloudSolrServers used outside Solr-nodes will need client-user only, to be
used on its ZK-connections, to be able to read necessary stuff
* ZkCLI needs to know about internal-user credentials to be used for its own
connections to ZK, and to create "everything"-ACLs for this internal-user on
every znodes it creates
> Support for protecting content in ZK
> ------------------------------------
>
> Key: SOLR-4580
> URL: https://issues.apache.org/jira/browse/SOLR-4580
> Project: Solr
> Issue Type: New Feature
> Components: SolrCloud
> Affects Versions: 4.2
> Reporter: Per Steffensen
> Assignee: Per Steffensen
> Labels: security, solr, zookeeper
>
> We want to protect content in zookeeper.
> In order to run a CloudSolrServer in "client-space" you will have to open for
> access to zookeeper from client-space.
> If you do not trust persons or systems in client-space you want to protect
> zookeeper against evilness from client-space - e.g.
> * Changing configuration
> * Trying to mess up system by manipulating clusterstate
> * Add a delete-collection job to be carried out by the Overseer
> * etc
> Even if you do not open for zookeeper access to someone outside your "secure
> zone" you might want to protect zookeeper content from being manipulated by
> e.g.
> * Malware that found its way into secure zone
> * Other systems also using zookeeper
> * etc.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
