[
https://issues.apache.org/jira/browse/ZOOKEEPER-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16254811#comment-16254811
]
Patrick Hunt commented on ZOOKEEPER-2793:
-----------------------------------------
I would say that all sounds reasonable. My main remaining concern is that we
could end up locking up the cluster and not being able to recover.
bq. Apart from the following case any other way the corruption can occur
I guess anything where the list no longer reflects that the admin wants.
Perhaps another example is that you have a three node ensemble, two of the
nodes die and you need to get two new ones. Wouldn't that also be a valid
example where we can recover today but not if this feature is enabled?
Perhaps there is a control somewhere else that enables/disables this feature?
In the worst-case scenario the admin could disable, recover the cluster, reset
the "authzhosts" and then re-enable. That seems like a copout though. Is there
a better way?
> [QP MutualAuth]: Implement a mechanism to build "authzHosts" for dynamic
> reconfig servers
> -----------------------------------------------------------------------------------------
>
> Key: ZOOKEEPER-2793
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2793
> Project: ZooKeeper
> Issue Type: Sub-task
> Components: quorum, security
> Reporter: Rakesh R
> Assignee: Rakesh R
> Fix For: 3.5.4, 3.6.0
>
>
> {{QuorumServer}} will do the authorization checks against configured
> authorized hosts. During LE, QuorumLearner will send an authentication packet
> to QuorumServer. Now, QuorumServer will check that the connecting
> QuorumLearner’s hostname exists in the authorized hosts. If not exists then
> connecting peer is not authorized to join this ensemble and the request will
> be rejected immediately.
> In {{branch-3.4}} building {{authzHosts}} list is pretty straight forward,
> can use the ensemble server details in zoo.cfg file. But with dynamic
> reconfig, it has to consider the dynamic add/remove/update servers and need
> to discuss the ways to handle dynamic cases.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
