ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Pavlukhin <vololo...@gmail.com>
Subject Re: Joining node validation failure event.
Date Tue, 03 Dec 2019 05:48:19 GMT
Mikhail,

Do you need some ordering guarantees among node lifecycle events and
listener notifications. For example, I can imagine that it is good to
notify security component about every node failed validation. How can
we achieve it with events (I assume dynamic listener registration)?

пн, 2 дек. 2019 г. в 18:09, Mikhail Petrov <pmgheap.sbt@gmail.com>:
>
> 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.
>
> Regards,
> Mikhail.
>
> 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 the
> >>>>>> 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
> >>>>>>>>
> >>>



-- 
Best regards,
Ivan Pavlukhin

Mime
View raw message