zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ZOOKEEPER-1634) A new feature proposal to ZooKeeper: authentication enforcement
Date Wed, 30 Nov 2016 00:12:58 GMT

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

ASF GitHub Bot commented on ZOOKEEPER-1634:

GitHub user hanm opened a pull request:


    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
    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):

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:


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 <hanm@cloudera.com>
Date:   2016-11-29T23:19:38Z

    ZOOKEEPER-1634: teach server to enforce client authentication.


> A new feature proposal to ZooKeeper: authentication enforcement
> ---------------------------------------------------------------
>                 Key: ZOOKEEPER-1634
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1634
>             Project: ZooKeeper
>          Issue Type: New Feature
>          Components: security, server
>    Affects Versions: 3.4.5
>            Reporter: Jaewoong Choi
>            Assignee: Michael Han
>             Fix For: 3.6.0
>         Attachments: zookeeper_3.4.5_patch_for_authentication_enforcement.patch
>   Original Estimate: 72h
>  Remaining Estimate: 72h
> Up to the version of 3.4.5, ZooKeeperServer doesn't force the authentication if the client
doesn't give any auth-info through ZooKeeper#addAuthInfo method invocation.  Hence, every
znode should have at least one ACL assigned otherwise any unauthenticated client can do anything
on it.
> The current authentication/authorization mechanism of ZooKeeper described above has several
points at issue:
> 1. At security standpoint, a maleficent client can access a znode which doesn't have
any proper authorization access control set.
> 2. At runtime performance standpoint, authorization for every znode to every operation
is unnecessarily but always evaluated against the client who bypassed the authentication phase.
> In other words, the current mechanism doesn't address a certain requirement at below:
> "We want to protect a ZK server by enforcing a simple authentication to every client
no matter which znode it is trying to access.  Every connection (or operation) from the client
won't be established but rejected if it doesn't come with a valid authentication information.
 As we don't have any other distinction between znodes in term of authorization, we don't
want any ACLs on any znode."
> To address the issues mentioned above, we propose a feature called "authentication enforcement"
to the ZK source.  The idea is roughly but clearly described in a form of patch in the attached
file (zookeeper_3.4.5_patch_for_authentication_enforcement.patch): which makes ZooKeeperServer
enforce the authentication with the given 2 configurations: authenticationEnforced (boolean)
and enforcedAuthenticationScheme (string) against every operation coming through ZooKeeperServer#processPacket
method except for OpCode.auth operation.  The repository base of the patch is "http://svn.apache.org/repos/asf/zookeeper/tags/release-3.4.5/"

This message was sent by Atlassian JIRA

View raw message