CVE-2022-22963

[Vishwas Bm]

Hi All,

Is ignite impacted by this critical vulnerability?

https://securityboulevard.com/2022/03/cyrc-vulnerability-analysis-two-distinct-spring-vulnerabilities-discovered-spring4shell-and-cve-2022-22963/


Regards,
Vishwas

Re: Ignite best practice for restarting k8s pod

[Vishwas Bm]

Hi Alexandr,

Thanks for the response.

It is with native persistence being enabled.  Will there be any difference,
with and without persistence ?
The docker image and the statefulset is created based on the below ignite
documentation:
https://github.com/apache/ignite/blob/master/docker/apache-ignite/Dockerfile
https://apacheignite.readme.io/docs/stateful-deployment#statefulset-deployment

The docker image is based on ignite-2.9.0 release and we had put debug
statements in onDisconnected method call but we do not see any
of those prints in the case of "kubectl delete pod"

Also what is the code in ignite which handles KILL SIG  ?


*Thanks & Regards,*

*Vishwas *


On Fri, Jan 15, 2021 at 8:10 PM Alexandr Shapkin  wrote:

> Hi,
>
>
>
> Thanks for the ticket. I’ll check that.
>
>
>
> What configuration do you use, is it a persistent cluster or in-memory one?
>
> Do you use an official Ignite image or a custom assembly?
>
>
>
> 'kubectl delete pod' should work fine here and forward KILL SIG to a
> running node internally.
>
> Well, at least starting from 2.9 version.
>
>
>
>
>
> *From: *vbm 
> *Sent: *Wednesday, January 13, 2021 11:32 AM
> *To: *user@ignite.apache.org
> *Subject: *Ignite best practice for restarting k8s pod
>
>
>
> Hi,
>
>
>
> I had raised this ticket:
>
> https://issues.apache.org/jira/browse/IGNITE-13974
>
>
>
>
>
> Currently I do not see any cleanup functions getting called when we do a
>
> 'kubectl delete pod'.
>
>
>
> May I know, what is the best practice for restarting k8s ignite pod ?
>
> How do we handle scenario when we need to scale down Ignite pods ? I think
>
> internally when we do kubectl scale down it calls kubectl delete pod.
>
>
>
>
>
> Regards,
>
> Vishwas
>
>
>
>
>
>
>
> --
>
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>
>
>

Re: Query on implementing GridSecurityProcessor

[Vishwas Bm]

Yes. I have posted the question on developer  list.


On Fri, 27 Nov, 2020, 16:28 andrei,  wrote:

> Hello,
>
> I think you should post your question on the Ignite Developer List:
>
> http://apache-ignite-developers.2346864.n4.nabble.com/
>
> IEP41 was developed by Denis Garus and discussed in the following thread:
>
>
> http://apache-ignite-developers.2346864.n4.nabble.com/Security-Subject-of-thin-client-on-remote-nodes-td46029.html
>
> You can try asking him in this thread.
>
> BR,
> Andrew
> 24.11.2020 21:06, Vishwas Bm пишет:
>
> The uuid is set randomly and as we are not allowed to update the node
> attributes, I am not sure how this can be implemented using node
> attributes.
>
> Any idea on how this can be achieved ?
>
>
>
> On Sun, 22 Nov, 2020, 19:22 vbm,  wrote:
>
>> Hi,
>>
>> We have implemented the security plugin by implementing
>> GridSecurityProcessor .
>>
>> We are using sqlline for querying the cache and are hitting the below
>> issue
>> (i.e remote node not able to get the security context)
>>
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-41
>>
>> I am not able to get how to implement the below part from IEP-41
>> "The subject id for the node can be stored in its
>> IgniteNodeAttributes.ATTR_SECURITY_SUBJECT_ID attribute."
>>
>>
>> In the GridSecurityProcessor interface the AuthenticationContext,  is only
>> available in authenticate function.
>> @Override public SecurityContext authenticate(AuthenticationContext ctx)
>>
>> If I make IgniteNodeAttributes.ATTR_SECURITY_SUBJECT_ID as a userAttribute
>> will I be able to update the attribute ?
>> Will this attribute be visible when eventually below function gets called
>> ?
>>
>> public SecurityContext securityContext(UUID subjId){
>>
>> }
>>
>>
>> Regards,
>> Vishwas
>>
>>
>>
>> --
>> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>>
>

Re: Query on implementing GridSecurityProcessor

[Vishwas Bm]

The uuid is set randomly and as we are not allowed to update the node
attributes, I am not sure how this can be implemented using node
attributes.

Any idea on how this can be achieved ?



On Sun, 22 Nov, 2020, 19:22 vbm,  wrote:

> Hi,
>
> We have implemented the security plugin by implementing
> GridSecurityProcessor .
>
> We are using sqlline for querying the cache and are hitting the below issue
> (i.e remote node not able to get the security context)
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-41
>
> I am not able to get how to implement the below part from IEP-41
> "The subject id for the node can be stored in its
> IgniteNodeAttributes.ATTR_SECURITY_SUBJECT_ID attribute."
>
>
> In the GridSecurityProcessor interface the AuthenticationContext,  is only
> available in authenticate function.
> @Override public SecurityContext authenticate(AuthenticationContext ctx)
>
> If I make IgniteNodeAttributes.ATTR_SECURITY_SUBJECT_ID as a userAttribute
> will I be able to update the attribute ?
> Will this attribute be visible when eventually below function gets called ?
>
> public SecurityContext securityContext(UUID subjId){
>
> }
>
>
> Regards,
> Vishwas
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

IgniteSecurity vs GridSecurityProcessor

[Vishwas Bm]

Hi,

We were using 2.7.6 and had implemented a custom security plugin for
authorization and authentication by implementing GridSecurityProcessor.

Now in 2.9 we see that a new interface is provided IgniteSecurity.
May I know what is the difference between the interfaces, as both look
similar and what is appropriate place to implement them.

Also in 2.7.6 there was a class called SecurityContextHolder to  hold the
context.
Now in 2.9 we do not see that class and we see a class
OperartionClassContext.
How do we use this new class when using a custom security plugin?



Regards,
Vishwas

Query on Ignite K8s Operator

[Vishwas Bm]

Hi,

I found the below link on Ignite K8s operator docker image:
https://hub.docker.com/r/gridgain/apache-ignite-operator

Is this licensed ? Can this be used ?

*Thanks & Regards,*

*Vishwas*

Ignite IPv6 support

[Vishwas Bm]

Hi,

We are using ignite on K8s environment. Now we wanted to move to a K8s
environment with ipv6 support.

But I read in below document that ignite has some issues on IPv6 cluster:
https://apacheignite.readme.io/docs/network-config

May I know what are the challenges or issues that are seen with Ignite on
an IPv6 enabled cluster ?


*Thanks & Regards,*

*Vishwas *

Re: 3rd-party-store not working (Record is not getting updated in Hive)

[Vishwas Bm]

Thanks for the reply. We are able to achieve the write through behavior
after enabling the flag.


On Thu, Sep 27, 2018, 11:26 AM Evgenii Zhuravlev 
wrote:

> You can read JavaDoc to this parameter, it have information about 3rd
> party persistent store:
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteDataStreamer.html#allowOverwrite--
>
> чт, 27 сент. 2018 г. в 8:35, vbm :
>
>> Hi,
>>
>> We will try by setting it to True. But the name of the parameter is
>> misleading for the 3rd party store usage.
>>
>> We will get back, if we find issues again.
>>
>> Regards,
>> Vishwas
>>
>>
>>
>> --
>> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>>
>

How to connect to kubernetes pods from ignite client

[Vishwas Bm]

Hi,

I have  setup 3 kuberentes pods each running a ignite server as per the
link.

My question is how to connect to these from an ignite client which is
outside the kubernetes environment. I have the client running in a
contianer.
How does the client discover the ignite pods. Should we use the same
TcpDiscoveryKubernetesIpFinder when starting the client.


*Thanks & Regards,*

*Vishwas *

Question on ports exposed in kubernetes setup

[Vishwas Bm]

Hi,

I have setup ignite on kubernetes using this link
.
The setup is ready, I wanted to try few curl commands as mentioned in this
link .

As per the ignite kubernetes setup guide, the rest port is
But when I try it, it gives empty reply.
As per my understanding 8080 is the port for curl commands by default. So I
exposed 8080 port and then tried the curl command and it worked.

As per the setup guide, following ports are exposed:

- containerPort: 11211 # REST port number.-
containerPort: 47100 # communication SPI port number.-
containerPort: 47500 # discovery SPI port number.-
containerPort: 49112 # JMX port number.- containerPort: 10800
# SQL port number.


So I wanted to know, what is the port  11211 used for and what is the
actual rest port.


*Thanks & Regards,*

*Vishwas *