You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Patrick Hunt (JIRA)" <ji...@apache.org> on 2016/09/07 05:02:21 UTC

[jira] [Commented] (ZOOKEEPER-1045) Support Quorum Peer mutual authentication via SASL

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

Patrick Hunt commented on ZOOKEEPER-1045:
-----------------------------------------

I did additional research on this. In particular I met with Esteban who's very familiar with the Hadoop and HBase code. We spent a considerable amount of time discussing and looking through the hbase/hadoop code. We couldn't find any direct parallels between what they are doing and what we are considering however. That said we came up with the following proposal. The idea being to simplify the implementation, allow expansion/extension in future, and in particular ensure that what we have initially is secure. Here's my proposal:

1) first, authenticate the remote entity (learner) and ensure they have valid kerberos credentials - we already have that in the patch.

2) if the learner has a principal of the form user/host@realm we compare just the user and realm, and not the host. If a credential with user@realm is provided we compare the user and realm similarly.

In neither case will we compare the host. This means that a particular user in realm can operate from any host as a quorum peer (if the user and realm match). It simplifies things greatly as we don't have to configure each/every ZK server in the ensemble with the principal of every other ZK server participating in the ensemble. If there are multiple ZK services (ensembles) in a realm then the user will need to ensure that differing user names are provided in the principal, otherwise servers from "other" ZK clusters could join services they are not meant to join. We should ensure that the documentation calls this out.

IIUC our current patch correctly this just means that we need to parse/compare the user and realm when authorizing. In future if there is the need to enhance this functionality in some way we can add additional configuration options for that.

Thoughts?


> Support Quorum Peer mutual authentication via SASL
> --------------------------------------------------
>
>                 Key: ZOOKEEPER-1045
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1045
>             Project: ZooKeeper
>          Issue Type: New Feature
>          Components: server
>            Reporter: Eugene Koontz
>            Assignee: Rakesh R
>            Priority: Critical
>             Fix For: 3.4.10, 3.5.3
>
>         Attachments: 0001-ZOOKEEPER-1045-br-3-4.patch, 1045_failing_phunt.tar.gz, HOST_RESOLVER-ZK-1045.patch, TEST-org.apache.zookeeper.server.quorum.auth.QuorumAuthUpgradeTest.txt, ZK-1045-test-case-failure-logs.zip, ZOOKEEPER-1045-00.patch, ZOOKEEPER-1045-Rolling Upgrade Design Proposal.pdf, ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045TestValidationDesign.pdf
>
>
> ZOOKEEPER-938 addresses mutual authentication between clients and servers. This bug, on the other hand, is for authentication among quorum peers. Hopefully much of the work done on SASL integration with Zookeeper for ZOOKEEPER-938 can be used as a foundation for this enhancement.



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