[
https://issues.apache.org/jira/browse/ZOOKEEPER-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15401001#comment-15401001
]
Rakesh R commented on ZOOKEEPER-1045:
-------------------------------------
Thanks a lot [~phunt], [~yoderme], [~hanm] for your time and comments. Sorry
for the delay in reply, I took some time to read the hadoop logic. I've
referred Hadoop SecurityUtil and tried a logic to resolve the hostname, please
refer attached {{HOST_RESOLVER-ZK-1045.patch}}. This can be verified using the
{{TestHost.java}} class. Can we do similar host resolver in ZooKeeper ?
bq. I don't think we can rely on the "host" from the zoo.cfg file, it might be
the host name, it might be an IP address, it might be FQDN, might not match
whatever is in the kerberos credential.
[~phunt], I thought of avoiding extra configurations to configure the peer
details for our authentication mechanism. Since we have the host details of all
the peers in zoo.cfg, while connecting, a current server can make use of this
zk quorum view and can get the respective ipaddress/hostname/fqdn using
{{sid}}. How about adopting {{HostResolver}} logic from Hadoop for resolving
this address, please refer the attached patch {{HOST_RESOLVER-ZK-1045.patch}},
which can be used to prepare ServerPrincipal
{{SecurityUtil.getServerPrincipal()}}?
bq. I chatted with the HDFS and HBase folks briefly, and what they mentioned to
me was that they look at the user and domain portion of the user/host@domain
principal, and don't compare the host portion. This is why it's a bit more
complicated than a simple string comparison as we originally had it in this
patch. This would provide the authz at the user and domain level, while not
constraining the host. Given we aren't using shared credentials I believe this
is sufficient - the ZK servers would authenticate each of the zk servers with
kerberos, then check that the user and domain is correct
Agreed. I think, we should also implement the same logic. I'm waiting to see
the responses of host resolver part first and then implement the authorization
logic. OK?
bq. How about we add an optional "require host in kerberos principal" flag,
default it to false. Then when comparing principals, we split out user / host @
domain, compare the user and domain, and then depending on the value of the
flag compare the host. This gives us comptibility and then optional security.
And we can move towards flipping that flag to true later.
Yes, this is a good idea. [~phunt], shall we introduce a flag?
> 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.9, 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)
