> Changing the default behavior to a less secure one

My point is that both options represent security issues.

If we want to migrate to a thin client, we need to allow management
tasks to be executed anyway. Among them are those that can read and
delete user data (cache scan/clear/destroy commands), deactivate a
cluster, etc.
Which without an explicitly configured security plugin will be a
security issue. Isn't that so?

> Mixing management tasks and user-defined tasks

There is authorization logic in GridTaskProcessor to distinguish them.

> Are we aware of any extensions that provide their own management commands? 
> How does it work with GridClient? Invoke by class name?

See CommandsProvider. Yes, they are invoked by the class name.

On Mon, Nov 11, 2024 at 8:15 AM Pavel Tupitsyn <ptupit...@apache.org> wrote:
>
> Nikita,
>
> I see two issues:
> - Changing the default behavior to a less secure one
> - Mixing management tasks and user-defined tasks
>
> What about a separate client operation code for management tasks?
> This will provide a way to control this functionality separately, and keep
> the default compute behavior as is.
>
> > This is necessary for pluggable commands
> Are we aware of any extensions that provide their own management commands?
> How does it work with GridClient? Invoke by class name?
>
>
> On Sun, Nov 10, 2024 at 8:40 PM Nikita Amelchev <namelc...@apache.org>
> wrote:
>
> > Hi, Pavel.
> >
> > > Which tasks are required for control.sh?
> >
> > All management tasks inherit from the `VisorMultiNodeTask` class.
> >
> > > Should we add a special case for them instead of enabling all tasks by
> > default?
> >
> > We can do it this way, but then it is possible to execute any task in
> > the Ignite classpath that inherits from the management task class.
> > This is necessary for pluggable commands - in Ignite extensions and
> > plugins.
> >
> > In any case, to avoid security issues it seems the user should
> > configure an explicit security plugin - which has the functionality
> > needed for this.
> >
> > On Fri, Nov 8, 2024 at 4:15 PM Pavel Tupitsyn <ptupit...@apache.org>
> > wrote:
> > >
> > > I agree with the proposal in general, but this part is concerning:
> > >
> > > > Change the default parameter -
> > > ThinClientConfiguration#setMaxActiveComputeTasksPerConnection (enable
> > tasks
> > > execution by default)
> > >
> > > This might become a security issue.
> > > As a user, I might want to disable thin client compute tasks but still
> > use
> > > the control utility.
> > >
> > > Which tasks are required for control.sh? Should we add a special case for
> > > them instead of enabling all tasks by default?
> > >
> > > On Fri, Nov 8, 2024 at 3:00 PM Nikolay Izhikov <nizhi...@apache.org>
> > wrote:
> > >
> > > > +1
> > > >
> > > > > On 8 Nov 2024, at 08:26, Nikita Amelchev <namelc...@apache.org>
> > wrote:
> > > > >
> > > > > Hello, Igniters.
> > > > >
> > > > > I propose to migrate the control.sh utility to a thin client. This
> > > > > will allow us to:
> > > > >
> > > > > - Remove the legacy GridClient, which is used only for control.sh;
> > > > > - Developers will support one thin client, instead of two;
> > > > > - Simplify cluster configuration.
> > > > >
> > > > > Implementation details and migration notes are described in the IEP
> > > > > [1]. PRs are ready to review [2,3,4]. Please, take a look.
> > > > >
> > > > > [1]
> > > >
> > https://cwiki.apache.org/confluence/display/IGNITE/%5BPhase+3%5D+Use+IgniteClient+instead+of+GridClient+in+the+control.sh+utility
> > > > > [2] https://github.com/apache/ignite/pull/11647
> > > > > [3] https://github.com/apache/ignite/pull/11646
> > > > > [4] https://github.com/apache/ignite/pull/11648
> > > > >
> > > > >
> > > > > --
> > > > > Best wishes,
> > > > > Amelchev Nikita
> > > >
> > > >
> >
> >
> >
> > --
> > Best wishes,
> > Amelchev Nikita
> >



-- 
Best wishes,
Amelchev Nikita

Reply via email to