[
https://issues.apache.org/jira/browse/ZOOKEEPER-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15471487#comment-15471487
]
Jason Heiss commented on ZOOKEEPER-1045:
----------------------------------------
Typically with Kerberos principals the bit in front of the slash identifies the
type of service rather than a specific user. E.g. HTTP/host.example.com is a
typical principal that would be used for a web server. So the fact that I can
get credentials for HTTP/host1.example.com does not typically imply that I have
any control over who gets credentials for HTTP/host2.example.com. Where I work
we have many thousands of hosts controlled by many different teams, and
self-service tooling for getting Kerberos credentials. If I own
host1.example.com I can control who can get HTTP/host1.example.com or
zookeeper/host1.example.com or whatnot. But if somebody else owns
host2.example.com they can get principals for those same service types on their
host. At least in our environment, even if I make up a unique service type like
"zk1" there is no way for me to limit the ability of others to get
zk1/<hostname> credentials on their hosts.
I think it is reasonable to require that people use hostnames rather than IP
addresses in zoo.cfg when using Kerberos and to use that as an authorization
list. Kerberos clients typically compute the credential name they expect the
server to use based on the hostname that the client is connecting to, so folks
in a Kerberos environment will typically have a functioning name service like
DNS.
> 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)
