[jira] [Commented] (ZOOKEEPER-2014) Only admin should be allowed to reconfig a cluster

["Michael Han (JIRA)" <ji...@apache.org>]

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

Michael Han commented on ZOOKEEPER-2014:
----------------------------------------

Had an offline discussion with [~phunt], [~fpj] yesterday regarding this issue, the conversation is captured as following points (with some of my thoughts as well):

* We can't fix security issue unless we enforce authentication and authorization. Just by moving client APIs around is not enough because at protocol level the server still open to reconfiguration and someone can exploit this easily (by writing their own ZK client instead of using ZooKeeper client for example.).

* That said though, the ZooKeeper::reconfig API should be moved out of ZooKeeper class (for Java client) anyway, because it's more about an admin feature rather than a client API. Moving reconfig out of ZooKeeper will also remove constraints we possibly put on normal ZooKeeper clients (such as having to use zookeeper.DigestAuthenticationProvider.superDigest), which is a bonus. Due to API backward compatibility concerns, this refactoring should happen before we move to beta.

* We'd like to introduce a new configuration option in zoo.cfg to turn off reconfig feature by default. ZK users who needs use this feature need turn it on explicitly. Because dynamic reconfig feature brings something new (e.g. cfg.dynamic file), have this feature off is good for 'the principal of least surprise'. Having the feature off by default will also buy us sometime to fortify and stabilize the feature without having it being a blocker issue.

The action items / plans I am thinking in the time frame of 3.5.3:
* Move ZooKeeper::reconfig into ServerAdminClient. ZooKeeper::getConfig will remain as is. 
* To run ServerAdminClient with reconfig command, clients need to use zookeeper.DigestAuthenticationProvider.superDigest and on server side we check superuser. This is basically what the current patch does today.  
* Introduce a new configuration option to turn on / off reconfig code path.

Are these good enough for now to address all security concerns or we still miss something?
Comments?

CC [~shralex], [~rgs]

> Only admin should be allowed to reconfig a cluster
> --------------------------------------------------
>
>                 Key: ZOOKEEPER-2014
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2014
>             Project: ZooKeeper
>          Issue Type: Bug
>          Components: server
>    Affects Versions: 3.5.0
>            Reporter: Raul Gutierrez Segales
>            Assignee: Michael Han
>            Priority: Blocker
>             Fix For: 3.5.3
>
>         Attachments: ZOOKEEPER-2014.patch
>
>
> ZOOKEEPER-107 introduces reconfiguration support via the reconfig() call. We should, at the very least, ensure that only the Admin can reconfigure a cluster. Perhaps restricting access to /zookeeper/config as well, though this is debatable. Surely one could ensure Admin only access via an ACL, but that would leave everyone who doesn't use ACLs unprotected. We could also force a default ACL to make it a bit more consistent (maybe).
> Finally, making reconfig() only available to Admins means they have to run with zookeeper.DigestAuthenticationProvider.superDigest (which I am not sure if everyone does, or how would it work with other authentication providers). 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)