GitHub user hanm opened a pull request:

    https://github.com/apache/zookeeper/pull/118

    ZOOKEEPER-1634: hardening security by teaching server to enforce client 
authentication.

    ## Motivation
    Previously ZooKeeper server is open to the world as the server does not 
enforce client authentication - anonymous clients are allowed to establish 
session with server. This behavior raises a couple of issues from the 
perspective of performance and security for example:
    * It is easy to launch a DDoS attack to server, by having a fleet of 
anonymous clients connect to the ensemble, as each session would consume 
valuable resources (socket, memory, etc) from server. 
    * It is cumbersome to enforce certain security models with the presence of 
anonymous clients login - for example as clients are not trusted the root ACL 
has to be disabled for writes to world, among other configurations an admin has 
to do to secure a cluster in a multi-tenant environment.
    
    So the goal here is to address such issue by hardening ZooKeeper security 
to provide a more confined access option that user could opt-in, which in 
addition to the existing ACLs together could lead to more secured / resource 
optimal ensemble. 
    
    ## Design Abstract
    * Introduce a new server side Java property that if set, ZooKeeper server 
will only accept connections and requests from clients that have authenticated 
with server via SASL.            
    * Clients that are not configured with SASL authentication, or configured 
with SASL but fail authentication (i.e. with invalid credential) will not be 
able to establish a session with server. A typed error code (-124) will be 
delivered in such case, both Java and C client will close the session with 
server thereafter, without further attempts on retrying to reconnect.
    * This feature overrules the server property 
"zookeeper.allowSaslFailedClients". So even if server is configured to allow 
clients that fail SASL authentication to login, client will not be able to 
establish a session with server if this feature is enabled.
    * Only support SASL because only SASL authentication has the property that 
no operations will happen until SASL authentication process finished. Thus, the 
decision of whether to close the session or not can be quickly made on server 
side upon receiving a client connection request. We could later add support for 
other auth scheme via add_auth_info if that's desired (if we do, then a session 
has to be maintained until add_auth_info is invoked.).
    * As a side benefit, this PR fixes an issue mentioned in ZOOKEEPER-2346 by 
correctly propagate events from server to client side so a SASL auth failure 
will manifest as an auth / config failure rather than generic ConnectionLoss 
event.
    
    JIRA: https://issues.apache.org/jira/browse/ZOOKEEPER-1634
    The PR also covers (or part of):
    https://issues.apache.org/jira/browse/ZOOKEEPER-2462
    https://issues.apache.org/jira/browse/ZOOKEEPER-2526
    https://issues.apache.org/jira/browse/ZOOKEEPER-2346
    
    
    


You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/hanm/zookeeper ZOOKEEPER-1634

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/zookeeper/pull/118.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #118
    
----
commit 90beaa0396cb2238b40e4b93764bd1a396b9047b
Author: Michael Han <h...@cloudera.com>
Date:   2016-11-29T23:19:38Z

    ZOOKEEPER-1634: teach server to enforce client authentication.

----


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Reply via email to