[
https://issues.apache.org/jira/browse/ZOOKEEPER-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15358379#comment-15358379
]
Rakesh R edited comment on ZOOKEEPER-1045 at 7/1/16 6:03 AM:
-------------------------------------------------------------
Thanks [~dbenediktson] for the interest in this work and sharing the use case.
bq. please make sure you support the case where all the ZK hosts run as the
same Kerberos principal
Yes, you can configure the same Krb credentials for client-server and
server-server communications. As part of this jira, there is no changes to the
existing client-server communication path, this will work as it is. I will try
to add few details about the server-server auth configs.
For the server-server auth, Kerb principal should be same for all the servers
to allow communicating each other. Since each server will talk to all the other
servers to form quorum it is required to know each others Krb principal. This
jira introduces {{QuorumServer}} section where admin can configure the Krb
principal of self (also it represents the principal of other quorum peer
server), learner will use this and can contact them.
In the below example config, should use same
{{principal="zkquorum/localh...@example.com";}} in all the servers.
{code}
QuorumServer {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
keyTab="/path/to/keytab"
storeKey=true
useTicketCache=false
debug=false
principal="zkquorum/localh...@example.com";
};
{code}
Few days back there was a discussion about configuring [different Kerb
credentials|https://issues.apache.org/jira/browse/ZOOKEEPER-1045?focusedCommentId=15339198&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15339198]
for client-server(Server) and server-server(QuorumServer/QuorumLearner)
communications. Please refer this to understand more.
We will be supporting Krb credentials in the following ways. I'd appreciate if
you can test the same in your env and see its working.
1) all ZK hosts sharing same Kerb principal for both client-server and
server-server
2) client-server(Server) uses {{principal_1}} and
server-server(QuorumServer/QuorumLearner) uses {{principal_2}}.
bq.I've validated that server to server Kerberos SASL auth working, when
servers share same credentials (same service principal name + same full
qualified domain+ same keytabs) deployed on all nodes.
Thanks [~hanm] for the confirmation.
bq. For the cases where each server has a distinct Kerberos credential, it's
not working yet.
[~hanm], please let me the QuorumServer principal values. Could you share the
{{jaas.config}} of all the servers and the failure logs for better debugging.
was (Author: rakeshr):
Thanks [~dbenediktson] for the interest in this work and sharing the use case.
bq. please make sure you support the case where all the ZK hosts run as the
same Kerberos principal
Yes, you can configure the same Krb credentials for client-server and
server-server communications. As part of this jira, there is no changes to the
existing client-server communication path, this will work as it is. I will try
to add few details about the server-server auth configs.
For the server-server auth, Kerb principal should be same for all the servers
to allow communicating each other. Since each server will talk to all the other
servers to form quorum it is required to know each others Krb principal. This
jira introduces {{QuorumServer}} section where admin can configure the
principal of self(also the principal of other quorum peer server), learner will
use this and can contact them.
In the below example config, should use same
{{principal="zkquorum/localh...@example.com";}} in all the servers.
{code}
QuorumServer {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
keyTab="/path/to/keytab"
storeKey=true
useTicketCache=false
debug=false
principal="zkquorum/localh...@example.com";
};
{code}
Few days back there was a discussion about configuring [different Kerb
credentials|https://issues.apache.org/jira/browse/ZOOKEEPER-1045?focusedCommentId=15339198&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15339198]
for client-server(Server) and server-server(QuorumServer/QuorumLearner)
communications. Please refer this to understand more.
We will be supporting Krb credentials in the following ways. I'd appreciate if
you can test the same in your env and see its working.
1) all ZK hosts sharing same Kerb principal for both client-server and
server-server
2) client-server(Server) uses {{principal_1}} and
server-server(QuorumServer/QuorumLearner) uses {{principal_2}}.
bq.I've validated that server to server Kerberos SASL auth working, when
servers share same credentials (same service principal name + same full
qualified domain+ same keytabs) deployed on all nodes.
Thanks [~hanm] for the confirmation.
bq. For the cases where each server has a distinct Kerberos credential, it's
not working yet.
[~hanm], please let me the QuorumServer principal values. Could you share the
{{jaas.config}} of all the servers and the failure logs for better debugging.
> 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-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)
