[
https://issues.apache.org/jira/browse/ZOOKEEPER-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15096571#comment-15096571
]
Rakesh R commented on ZOOKEEPER-1045:
-------------------------------------
bq. Is there much user demand for Kerberos support for inter-zk channels?.
SASL approach is a good choice considering that SASL(Kerberos) is already
supported between zkclient-zksever communications quite some time. I think
users/admins will be much more comfortable with SASL deployment. Also, it will
be easy for them to upgrade the existing clusters which is secured with
SASL(kerberos) way.
bq. Will ZK have to always get token from KDC first before authenticating a
peer?. I am not quite familiar with SASL Java API can you shed some light into
the system level process.
Yes, Initial authentication takes place between the Kerberos client and the KDC
server. In ZooKeeper,every QuorumPeer will have a Kerberos client and at the
beginning gets token from the KDC server. For the initial TGT can either choose
{{kinit USERNAME}} or use the local keytab file. I've tried capturing few
configurations needed for implementing this feature in
[README.md|https://github.com/apache/zookeeper/pull/49/files#diff-ecca263dd60ba00b624638323e799bdfR53]
For example,
{code}
QuorumServer {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=false
useTicketCache=true
principal="zkquorum/localh...@example.com";
};
{code}
{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}
I hope the following links will help to understand Kerberos, SASL java API:
http://www.roguelynn.com/words/explain-like-im-5-kerberos/
https://docs.oracle.com/javase/7/docs/technotes/guides/security/sasl/sasl-refguide.html
https://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide/default.htm?turl=WordDocuments%2Fintroductiontokerberosauthentication.htm
bq. Does this provide encryption of the data traffic using the shared secret
key?.
As per my understanding, Kerberos provides facilities to make sure that
messages are not changed as they travel across the network. The messages can
optionally be encrypted so only the parties that know the session key can
examine their contents. Java SASL provides QOP settings. "auth-conf" – This
stands for authentication, integrity and confidentiality. This setting
guarantees that data exchanged between client and server is encrypted and is
not readable by a "man in the middle". Truly I haven't explored much to
implement this part. I hope experienced folks can shed some light on this.
> Quorum Peer mutual authentication
> ---------------------------------
>
> 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
> Attachments: ZOOKEEPER-1045-00.patch, ZOOKEEPER-1045-Rolling Upgrade
> Design Proposal.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)
