[
https://issues.apache.org/jira/browse/MESOS-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14044846#comment-14044846
]
Dominic Hamon commented on MESOS-1546:
--------------------------------------
This solution is fine but it seems to be to be papering over the issue instead
of fixing the root cause.
Once we have a whitelist, do we need to use ZK for discovery?
Is there any other way we can capture an unexpected master, perhaps by setting
the expected number of masters explicitly?
> Introduce an optional master whitelist for replicated log based registrar.
> --------------------------------------------------------------------------
>
> Key: MESOS-1546
> URL: https://issues.apache.org/jira/browse/MESOS-1546
> Project: Mesos
> Issue Type: Improvement
> Components: master, replicated log
> Reporter: Jie Yu
>
> When using replicated log as the storage back-end for registrar, we currently
> rely on ZooKeeper to discover replicas (see ZooKeeperNetwork in
> src/log/network.hpp). We simply broadcast Paxos messages to all replicas in
> the ZooKeeperNetwork.
> There is a security concern using this approach. For example, say initially
> there are 3 masters and the quorum size is 2. Now, if a 4th master is
> accidentally added and joined the ZooKeeperNetwork, we will then operate at 4
> replicas with quorum size 2. This could lead to inconsistency in the
> replicated log (and thus registrar).
> The idea here is to introduce a whitelist for masters. We still use
> ZooKeeperNetwork to discover replicas. However, when broadcasting Paxos
> messages in the replicated log, we check the whitelist and make sure we don't
> send Paxos messages to a master that is not in this whitelist.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
