[
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:*
* Possibly better security: a malicious node would have to imitate valid
requirements.
*Cons:*
* Harder to maintain backwards compatibility: old nodes need to predict what
information a new node might send.
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:*
* Easier to maintain backwards-compatibility: a new node knows if older nodes
are compatible with it.
* Modular validation architecture: each plugin can independently register its
cluster state requirements.
*Cons:*
* Possible security issues: a malicious node can enter the cluster more
easily. 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.
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:*
* ???
*Cons:*
* Harder to maintain backwards compatibility: old nodes need to predict what
information a new node might send.
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:*
* Easier to maintain backwards-compatibility: a new node knows if older nodes
are compatible with it.
* Modular validation architecture: each plugin can independently register its
requirements.
*Cons:*
* Possible security issues: a malicious node can enter the cluster more
easily. However, this may be mitigated by signing the handshake messages.
> 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:*
> * Possibly better security: a malicious node would have to imitate valid
> requirements.
> *Cons:*
> * Harder to maintain backwards compatibility: old nodes need to predict what
> information a new node might send.
> 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:*
> * Easier to maintain backwards-compatibility: a new node knows if older
> nodes are compatible with it.
> * Modular validation architecture: each plugin can independently register
> its cluster state requirements.
> *Cons:*
> * Possible security issues: a malicious node can enter the cluster more
> easily. However, this may be mitigated by signing the handshake messages.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
