[jira] [Comment Edited] (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 edited comment on ZOOKEEPER-2014 at 8/22/16 8:52 PM:
-----------------------------------------------------------------

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:
* Fix Security:
#* Enforce an ACL on /zookeeper/config, such that only users that have write permission to it can reconfig the cluster. /zookeeper/config is by default readable to anyone so zookeeper (none-admin) clients can load balancing on client side either manually (current behavior) or automatically (ZOOKEEPER-2016). 
#* ZooKeeper users are responsible for properly configure the ACL such that only a limited set of admin users are part of the ACL with write access. The authentication of these users will be delegated to existing mechanisms ZooKeeper already supports, such as SASL client login, so not much work here except documentation on such a requirement to use reconfig feature.
#* The default behavior is such that if /zookeeper/config node has no associated ACLs, then no one is allowed write access except super user. 
* Fix API:
#* Create a new class ZooKeeperAdmin that inherits ZooKeeper class.
#* Move reconfig and getConfig API into ZooKeeperAdmin class.
* Introduce a new zoo.cfg option to switch reconfiguration feature on or off. The new configuration option will be set as 'disable reconfig' by default when 3.5.3 shipped, and user who wants reconfig has to enable reconfig option explicitly.

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

CC [~shralex], [~rgs]


was (Author: hanm):
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)