[
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/[email protected]'
server.2=FQDN2:2080:2181 and its Kerb principal name should be
'zkquorum/[email protected]'
server.3=FQDN3:2080:2181 and its Kerb principal name should be
'zkquorum/[email protected]'
{code}
Impact of interchanging the principal. For example, assume admin has configured
a valid {{zkquorum/[email protected]}} 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/[email protected]}} 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/[email protected]}} 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)
