ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikhail Petrov <pmgheap....@gmail.com>
Subject Re: Joining node validation failure event.
Date Mon, 02 Dec 2019 15:09:08 GMT
Hi, Andrey.

It doesn't influence on authentication or authorization process. There 
is a security requirement that demands to notify some outer security 
subsystems in a specific way when joining node validation failed in any 
Ignite component (e.g. GridCacheProcessor) not only in 
IgniteSecurityProcessor. So PluginProvider#validateNewNode is not 
acceptable for me.


On 02.12.2019 16:35, Andrey Gura wrote:
> Mikhail,
> I don't understand how node validation on join affects security. But
> it seems that you can use
> PluginProvider#validateNewNode(org.apache.ignite.cluster.ClusterNode,
> java.io.Serializable) method. Does it fit for your needs?
> On Mon, Dec 2, 2019 at 12:54 PM Mikhail Petrov <pmgheap.sbt@gmail.com> wrote:
>> Hi, Ivan.
>> Unfortunately, we came to no decision yet. As I mentioned above this
>> event is disabled by default and no node will receive this event without
>> an explicit subscription. In my case, that event is assumed to be used
>> on node locally to share joining node info between security and
>> discovery components. I have no idea how to solve this problem without
>> publishing a new event too. But I'm concerned about the acceptance of
>> that solution. Maybe it can be solved some other way? I will appreciate
>> any suggestion or review PR [1] with event implementation.
>> [1] https://github.com/apache/ignite/pull/7057
>> Regards,
>> Mikhail.
>> On 02.12.2019 10:38, Ivan Pavlukhin wrote:
>>> Mikhail, Andrey,
>>> Have you come to a common decision here? As for me, it sounds useful
>>> to expose node join failure details somehow. The thing to decide on is
>>> a mechanism to expose it. Unfortunately, immediately have no idea
>>> better than using events.
>>>> What is purpose of the special cluster wide event? Node is not joined
>>>> to the topology. Why topology nodes should know something about this
>>>> node?
>>> Was this question answered? I suppose that at least coordinator will
>>> receive the event, will not it?
>>> чт, 28 нояб. 2019 г. в 10:10, Mikhail Petrov <pmgheap.sbt@gmail.com>:
>>>> Hi, Ivan.
>>>> I'm sorry that the discussion was moved in private channel. The problem
>>>> I'm trying to solve is described below in the thread. The security
>>>> plugin in my case stores and analyzesinfo about a node that failed to join.
>>>> Regards,
>>>> Mikhail.
>>>> -------- Forwarded Message --------
>>>> Subject:        Re: Joining node validation failure event.
>>>> Date:   Thu, 21 Nov 2019 21:43:33 +0300
>>>> From:   Mikhail Petrov <pmgheap.sbt@gmail.com>
>>>> To:     Andrey Gura <agura@apache.org>
>>>> Hi, Andrey.
>>>> In my task security plugin running on the coordinator must locally
>>>> handle the situation when some node is trying to join the topology with
>>>> the invalid configuration. I can't handle the response on a node that
>>>> failed to connect because it's untrusted.
>>>> Actually I'm only concerned about one validation -- when all Ignite
>>>> components validate new node.
>>>> In my case plugin must be able to obtain general and security subject
>>>> information from joining TcpDiscoveryNode attributes. But I have no idea
>>>> how to share information between the security and discovery components
>>>> without recording event and listening it locally.
>>>> This event is assumed to be disable by default and in my case used only
>>>> on local node so it's not look like "cluster wide event".
>>>> Also I propose to record this event in dedicated utilityPool so it can't
>>>> stuck discovery thread.
>>>> I will appreciate any thoughts on this problem.
>>>> Regards,
>>>> Mikhail.
>>>> On 21.11.2019 19:40, Andrey Gura wrote:
>>>>> Mikhail,
>>>>> It is still not enough details to me. What is expected behavior if the
>>>>> plugin?
>>>>> There are a different validations during node join. Many of them
>>>>> placed in RingMessageWorker#processJoinRequestMessage method. If
>>>>> validation will fail then corresponding message will be sent to the
>>>>> joining node (including TcpDiscoveryAuthFailedMessage) and node will
>>>>> not joined to topology.
>>>>> What is purpose of the special cluster wide event? Node is not joined
>>>>> to the topology. Why topology nodes should know something about this
>>>>> node?
>>>>> On Thu, Nov 21, 2019 at 9:54 AM Mikhail Petrov <pmgheap.sbt@gmail.com>
>>>>> wrote:
>>>>>> Hi, Andrey.
>>>>>> I take part in the development of a custom security plugin for Apache
>>>>>> Ignite. There is an information security requirement for which node
>>>>>> joining failures due to invalid configuration must be handled by
>>>>>> plugin.
>>>>>> This is where my case comes from. Are there any objections to the
>>>>>> proposed approach?
>>>>>> Regards,
>>>>>> Mikhail.
>>>>>> On 20.11.2019 19:38, Andrey Gura wrote:
>>>>>>> Hi, Mikhail!
>>>>>>> Could you please describe the case for this new event?
>>>>>>> On Wed, Nov 20, 2019 at 12:45 PM Mikhail Petrov
>>>>>>> <pmgheap.sbt@gmail.com> wrote:
>>>>>>>> Hello, Igniters.
>>>>>>>> There is a case which requires to handle joining node validation
>>>>>>>> failure
>>>>>>>> in Ignite components and obtain information of the node that
tried to
>>>>>>>> join and the reason for the failure. Now, as I see, there
is no way to
>>>>>>>> do it. I propose to implement a new event -- NodeValidationFailedEvent
>>>>>>>> -- and record it in case the validation fails. I have created
Tiket [1]
>>>>>>>> and PR [2], which shows an example of implementation. Could
anyone take
>>>>>>>> a look at it, please?
>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-12380
>>>>>>>> [2] https://github.com/apache/ignite/pull/7057

View raw message