[
https://issues.apache.org/jira/browse/IGNITE-14871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-14871:
-----------------------------------------
Description:
When a node enters the cluster, its configuration needs to be validated in
order to maintain cluster-wide invariants and to prohibit a non-compatible or
malicious node from entering the topology.
h2. Possible approaches
h3. Remote validation
The entering node sends some metadata (e.g. its version) to a random remote
node, which validates the metadata and issues the permit for the node to join.
*Pros:*
* Easier to maintain backwards-compatibility (useful for the rolling upgrade
feature).
*Cons:*
* What if a remote node is also older than other nodes? It might be possible
that a chain of increasingly older nodes might break the cluster invariants.
h3. Local validation
The entering node collects some metadata from a random remote node and decides
whether it is able to join the cluster or not.
*Pros:*
* ???
*Cons:*
* Difficult to maintain backwards-compatibility: an old node should be able to
predict what information might be sent by the newer remote nodes.
* Possible security issues: a malicious node can enter the cluster more easily
than when using the remote validation. However, this may be mitigated by
signing the handshake messages.
was:
When a node enters the cluster, its configuration needs to be validated in
order to maintain cluster-wide invariants and to prohibit a non-compatible or
malicious node from entering the topology.
h3. Possible approaches
> Implement a validation protocol for the nodes entering the topology
> -------------------------------------------------------------------
>
> Key: IGNITE-14871
> URL: https://issues.apache.org/jira/browse/IGNITE-14871
> Project: Ignite
> Issue Type: Task
> Components: networking
> Reporter: Vyacheslav Koptilin
> Priority: Major
> Labels: ignite-3
>
> When a node enters the cluster, its configuration needs to be validated in
> order to maintain cluster-wide invariants and to prohibit a non-compatible or
> malicious node from entering the topology.
> h2. Possible approaches
> h3. Remote validation
> The entering node sends some metadata (e.g. its version) to a random remote
> node, which validates the metadata and issues the permit for the node to join.
> *Pros:*
> * Easier to maintain backwards-compatibility (useful for the rolling upgrade
> feature).
> *Cons:*
> * What if a remote node is also older than other nodes? It might be possible
> that a chain of increasingly older nodes might break the cluster invariants.
> h3. Local validation
> The entering node collects some metadata from a random remote node and
> decides whether it is able to join the cluster or not.
> *Pros:*
> * ???
> *Cons:*
> * Difficult to maintain backwards-compatibility: an old node should be able
> to predict what information might be sent by the newer remote nodes.
> * Possible security issues: a malicious node can enter the cluster more
> easily than when using the remote validation. However, this may be mitigated
> by signing the handshake messages.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
