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