[ https://issues.apache.org/jira/browse/ZOOKEEPER-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15635578#comment-15635578 ]
Rakesh R commented on ZOOKEEPER-1045: ------------------------------------- bq. There is a corner case about impersonating server (a server with a valid Kerberos credential from another server in ensemble.). My feeling is this is a corner case that we could either postpone or document - security wise it seems fine, because we support shared kerberos credential there is no way we can prevent impersonating (shared Kerberos credential is an extreme, as shared Kerberos credential effectively would disable authorization). Good catch [~hanm]. I think it is not required to specifically authorizing the Learner's host details against the authz lists. I agreed to capture this recommendations in my feature document. Any of the servers(the server hosts configured in zoo.cfg) in the ensemble can join quorum with a valid Kerb principal. Lets assume we have three servers 1,2 & 3. It is highly recommended to configure the host based Kerb principal to the respective servers like, {code} server.1=FQDN1:2080:2181 and its Kerb principal name should be 'zkquorum/fq...@example.com' server.2=FQDN2:2080:2181 and its Kerb principal name should be 'zkquorum/fq...@example.com' server.3=FQDN3:2080:2181 and its Kerb principal name should be 'zkquorum/fq...@example.com' {code} Impact of interchanging the principal. For example, assume admin has configured a valid {{zkquorum/fq...@example.com}} principal(ensured proper keytab in place) in server.3's {{jaas.config}} instead of {{FQDN3}}. Server.3 will create an instance of {{SaslServer}} using this principal, which is a valid one. But all the Learners will think that Server.3 has service principal {{zkquorum/fq...@example.com}} and tries to authenticate using this and will endup in auth failures. So Server.3 will never get chance to become LEADER due to not successfully authenticating any of the connecting Learners. Since 1 & 2 has proper {{jaas.config}} principal entries, these both will successfully participate in quorum formation and one of them will become LEADER. For convenience, assume 1 became LEADER. Now, what happens to 3. Since he has valid kerberos principal he can findout the Leader server and prepares Leader's Kerb principal {{zkquorum/fq...@example.com}} and joins quorum as FOLLOWER {{connectToLeader()}}. bq. my thoughts are authentication and authorization has to be done together and authorization has a hard dependency on authentication Yes, you are correct. bq. In shared Kerberos credential case, there is no way to authenticate that the names sent from a server is genuine as opposed to the none shared Kerberos case where we have names encoded in keytabs, which will be authenticated as part of Kerberos. Passing host details via {{QuorumAuthPacket}} is one proposal. *I'd like to know anybody has a strong use case which needs authorization of host for both Digest and shared Kerb principal*. Thanks! bq. If user wants authorization they can use none-shared kerberos credential. This will make the implementation simple. I'd like to hear comments from other folks as well. Welcome thoughts. Thanks! > 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: quorum, security > 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, QuorumPeer Mutual > Authentication Via Sasl Feature Doc - 2016-Sep-25.pdf, > TEST-org.apache.zookeeper.server.quorum.auth.QuorumAuthUpgradeTest.txt, > ZK-1045-test-case-failure-logs.zip, ZOOKEEPER-1045 Test Plan.pdf, > 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-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, > org.apache.zookeeper.server.quorum.auth.QuorumAuthUpgradeTest.testRollingUpgrade.log > > > 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. > Review board: https://reviews.apache.org/r/47354/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)