[
https://issues.apache.org/jira/browse/ZOOKEEPER-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15471913#comment-15471913
]
Michael Han commented on ZOOKEEPER-1045:
----------------------------------------
bq. We have the list of servers already in the zoo.cfg for example, however the
server address can be anything - e.g. ip address. Would it make sense to
require that the server addresses in zoo.cfg match the host used in the
principal?
I like the idea of using zoo.cfg as the source of authorization information.
Kerberos is there for solving authentication problem, to do authorization we
need a system that stores the set of information such as authorized user info,
and I think that system is separate with Kerberos. In our case, using zoo.cfg
seems the best solution given it's already there and contain everything we
need. Other approach I can think of is using a dedicated znode that stores such
information (user+host combinations) which is bootstrapped configured at
cluster setup time, but that is way more complicated.
One approach we could do is to compute the FQDN for the _host part in
user/_host@REALM, regardless of what's put in zoo.cfg (it could be a DNS name,
or IP address). The implicit requirement here is the cluster deployment
environment has to have a naming service, which is required anyway to run
Kerberos. So we don't need to explicitly configure the _host part in any of the
zookeeper configuration files, we infer them. I believe Hadoop did something
similar by specifying principal names using _HOST string as a placeholder for
the hostname in the configuration file which is replaced at runtime
appropriately wherever needed. This approach does not require any additional
set up or configurations on users side, which I think might be good from
usability point of view.
To sum up, I think:
* ZK quorum authenticates a ZK process asking for joining quorum through
Kerberos.
* ZK quorum authorizes the process by comparing the full principal name that
composed of user/host@realm. The full string must match.
bq. Your comment earlier about
"InetAddress.getLocalHost().getCanonicalHostName()" being used.
That's how Hadoop RPC authenticates - though the motivation seems a little
different than what we are doing. What Hadoop RPC did is to make sure a client
that making RPC is what it advertised who it is by comparing the configured
principal names with the principal names computed at runtime from the client
making PRC - so IIUC this is still an authentication problem, not authorization
problem. That said I think we can still reuse this same code to compute the
host name.
> 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)
