[
https://issues.apache.org/jira/browse/ZOOKEEPER-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15383577#comment-15383577
]
Rakesh R commented on ZOOKEEPER-1045:
-------------------------------------
bq. I believe we should do similar, if not for security then for consistency.
Agreed. Previously in this jira, [~dbenediktson] has brought up a case where
all the ZK hosts run with the same Kerberos principal. So now we have two
cases, need to support both {{_HOST}} based principal name and {{shared}}
principal name. I'm assuming there won't be any need of supporting mixture of
both of these like, few quorum servers with "zkquorum/_HOST@" pattern in their
principal name and few others are having constant name "zkquorum@".
Following is an idea to support both the cases. Welcome comments.
*Case-1)* {{_HOST}} based principal -> For example, zkquorum/[email protected]
zoo.cfg has the following configuration which has the 'host' information. This
host address {{addr.getCanonicalHostName()}} will be used to replace the
{{_HOST}} pattern. We will make use of the existing data structure
{{QuorumCnxManager#view}} map to get the respective server's host name. While
connecting to the respective server, first the quorum learner will check
{{quorum.auth.kerberos.servicePrincipal}} configuration has {{_HOST}} name
pattern then convert the Kerberos principal name to a valid name by replacing
the {{_HOST}} part. Myid will be used as the key to get the respective quorum
server address from the {{#view}}.
{code}
server.0=host1:11222:11223:participant
server.1=host2:11225:11226:participant
server.2=host3:11228:11229:participant
{code}
*Case-2)* Shared principal -> For example, [email protected]
While connecting to peer servers, first the quorum learner will check
{{quorum.auth.kerberos.servicePrincipal}} configuration has {{_HOST}} name
pattern, if not then will directly use the value as Kerberos principal name and
continue with the authentication process.
*Case-3* Mixture of {{_HOST}} based and constant principal
ZooKeeper doesn't supports this case. ZooKeeper supports only two valid
principal names, either all servers should have "_HOST" based principal name or
all servers shares same principal name.
bq. I this this is a great idea, however is it possible to move to another
jira?
OK, I will push this separately
bq. It looks like we don't have any tests to verify the authz aspect of the
change?
Yes, will include test case for this.
> 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, 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)
