You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Per Steffensen (JIRA)" <ji...@apache.org> on 2013/03/14 09:58:13 UTC
[jira] [Commented] (SOLR-4580) Support for protecting content in ZK
[ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org