[infinispan-dev] Hot Rod secured by default

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Hot Rod secured by default

Wolf Fink
I would think a "switch" can have other impacts as you need to check it in the code - and might have security leaks here

So what is wrong with some configurations which are the default and secured.
and a "*-dev or *-unsecure" configuration to start easy.
Also this can be used in production if there is no need for security

On Thu, Apr 13, 2017 at 4:13 PM, Sebastian Laskawiec <[hidden email]> wrote:
I still think it would be better to create an extra switch to run infinispan in "development mode". This means no authentication, no encryption, possibly with JGroups stack tuned for fast discovery (especially in Kubernetes) and a big warning saying "You are in development mode, do not use this in production".

Just something very easy to get you going.

On Thu, Apr 13, 2017 at 12:16 PM Galder Zamarreño <[hidden email]> wrote:

--
Galder Zamarreño
Infinispan, Red Hat

> On 13 Apr 2017, at 09:50, Gustavo Fernandes <[hidden email]> wrote:
>
> On Thu, Apr 13, 2017 at 6:38 AM, Galder Zamarreño <[hidden email]> wrote:
> Hi all,
>
> As per some discussions we had yesterday on IRC w/ Tristan, Gustavo and Sebastian, I've created a docker image snapshot that reverts the change stop protected caches from requiring security enabled [1].
>
> In other words, I've removed [2]. The reason for temporarily doing that is because with the change as is, the changes required for a default server distro require that the entire cache manager's security is enabled. This is in turn creates a lot of problems with health and running checks used by Kubernetes/OpenShift amongst other things.
>
> Judging from our discussions on IRC, the idea is for such change to be present in 9.0.1, but I'd like to get final confirmation from Tristan et al.
>
>
> +1
>
> Regarding the "security by default" discussion, I think we should ship configurations cloud.xml, clustered.xml and standalone.xml with security enabled and disabled variants, and let users
> decide which one to pick based on the use case.

I think that's a better idea.

We could by default have a secured one, but switching to an insecure configuration should be doable with minimal effort, e.g. just switching config file.

As highlighted above, any secured configuration should work out-of-the-box with our docker images, e.g. WRT healthy/running checks.

Cheers,

>
> Gustavo.
>
>
> Cheers,
>
> [1] https://hub.docker.com/r/galderz/infinispan-server/tags/ (9.0.1-SNAPSHOT tag for anyone interested)
> [2] https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/main/java/org/infinispan/server/hotrod/CacheDecodeContext.java#L114-L118
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
> > On 30 Mar 2017, at 14:25, Tristan Tarrant <[hidden email]> wrote:
> >
> > Dear all,
> >
> > after a mini chat on IRC, I wanted to bring this to everybody's attention.
> >
> > We should make the Hot Rod endpoint require authentication in the
> > out-of-the-box configuration.
> > The proposal is to enable the PLAIN (or, preferably, DIGEST) SASL
> > mechanism against the ApplicationRealm and require users to run the
> > add-user script.
> > This would achieve two goals:
> > - secure out-of-the-box configuration, which is always a good idea
> > - access to the "protected" schema and script caches which is prevented
> > when not on loopback on non-authenticated endpoints.
> >
> > Tristan
> > --
> > Tristan Tarrant
> > Infinispan Lead
> > JBoss, a division of Red Hat
> > _______________________________________________
> > infinispan-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--

SEBASTIAN ŁASKAWIEC

INFINISPAN DEVELOPER


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Hot Rod secured by default

Galder Zamarreno
Agree with Wolf. Let's keep it simple by just providing extra configuration files for dev/unsecure envs.

Cheers,
--
Galder Zamarreño
Infinispan, Red Hat

> On 15 Apr 2017, at 12:57, Wolf Fink <[hidden email]> wrote:
>
> I would think a "switch" can have other impacts as you need to check it in the code - and might have security leaks here
>
> So what is wrong with some configurations which are the default and secured.
> and a "*-dev or *-unsecure" configuration to start easy.
> Also this can be used in production if there is no need for security
>
> On Thu, Apr 13, 2017 at 4:13 PM, Sebastian Laskawiec <[hidden email]> wrote:
> I still think it would be better to create an extra switch to run infinispan in "development mode". This means no authentication, no encryption, possibly with JGroups stack tuned for fast discovery (especially in Kubernetes) and a big warning saying "You are in development mode, do not use this in production".
>
> Just something very easy to get you going.
>
> On Thu, Apr 13, 2017 at 12:16 PM Galder Zamarreño <[hidden email]> wrote:
>
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
> > On 13 Apr 2017, at 09:50, Gustavo Fernandes <[hidden email]> wrote:
> >
> > On Thu, Apr 13, 2017 at 6:38 AM, Galder Zamarreño <[hidden email]> wrote:
> > Hi all,
> >
> > As per some discussions we had yesterday on IRC w/ Tristan, Gustavo and Sebastian, I've created a docker image snapshot that reverts the change stop protected caches from requiring security enabled [1].
> >
> > In other words, I've removed [2]. The reason for temporarily doing that is because with the change as is, the changes required for a default server distro require that the entire cache manager's security is enabled. This is in turn creates a lot of problems with health and running checks used by Kubernetes/OpenShift amongst other things.
> >
> > Judging from our discussions on IRC, the idea is for such change to be present in 9.0.1, but I'd like to get final confirmation from Tristan et al.
> >
> >
> > +1
> >
> > Regarding the "security by default" discussion, I think we should ship configurations cloud.xml, clustered.xml and standalone.xml with security enabled and disabled variants, and let users
> > decide which one to pick based on the use case.
>
> I think that's a better idea.
>
> We could by default have a secured one, but switching to an insecure configuration should be doable with minimal effort, e.g. just switching config file.
>
> As highlighted above, any secured configuration should work out-of-the-box with our docker images, e.g. WRT healthy/running checks.
>
> Cheers,
>
> >
> > Gustavo.
> >
> >
> > Cheers,
> >
> > [1] https://hub.docker.com/r/galderz/infinispan-server/tags/ (9.0.1-SNAPSHOT tag for anyone interested)
> > [2] https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/main/java/org/infinispan/server/hotrod/CacheDecodeContext.java#L114-L118
> > --
> > Galder Zamarreño
> > Infinispan, Red Hat
> >
> > > On 30 Mar 2017, at 14:25, Tristan Tarrant <[hidden email]> wrote:
> > >
> > > Dear all,
> > >
> > > after a mini chat on IRC, I wanted to bring this to everybody's attention.
> > >
> > > We should make the Hot Rod endpoint require authentication in the
> > > out-of-the-box configuration.
> > > The proposal is to enable the PLAIN (or, preferably, DIGEST) SASL
> > > mechanism against the ApplicationRealm and require users to run the
> > > add-user script.
> > > This would achieve two goals:
> > > - secure out-of-the-box configuration, which is always a good idea
> > > - access to the "protected" schema and script caches which is prevented
> > > when not on loopback on non-authenticated endpoints.
> > >
> > > Tristan
> > > --
> > > Tristan Tarrant
> > > Infinispan Lead
> > > JBoss, a division of Red Hat
> > > _______________________________________________
> > > infinispan-dev mailing list
> > > [hidden email]
> > > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> --
> SEBASTIAN ŁASKAWIEC
> INFINISPAN DEVELOPER
> Red Hat EMEA
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Hot Rod secured by default

Tristan Tarrant-2
Currently the "protected cache access" security is implemented as follows:

- if authorization is enabled || client is on loopback
   allow

The first check also implies that authentication needs to be in place,
as the authorization checks need a valid Subject.

Unfortunately authorization is very heavy-weight and actually overkill
even for "normal" secure usage.

My proposal is as follows:
- the "default" configuration files are "secure" by default
- provide clearly marked "unsecured" configuration files, which the user
can use
- drop the "protected cache" check completely

And definitely NO to a dev switch.

Tristan

On 19/04/2017 10:05, Galder Zamarreño wrote:

> Agree with Wolf. Let's keep it simple by just providing extra configuration files for dev/unsecure envs.
>
> Cheers,
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>> On 15 Apr 2017, at 12:57, Wolf Fink <[hidden email]> wrote:
>>
>> I would think a "switch" can have other impacts as you need to check it in the code - and might have security leaks here
>>
>> So what is wrong with some configurations which are the default and secured.
>> and a "*-dev or *-unsecure" configuration to start easy.
>> Also this can be used in production if there is no need for security
>>
>> On Thu, Apr 13, 2017 at 4:13 PM, Sebastian Laskawiec <[hidden email]> wrote:
>> I still think it would be better to create an extra switch to run infinispan in "development mode". This means no authentication, no encryption, possibly with JGroups stack tuned for fast discovery (especially in Kubernetes) and a big warning saying "You are in development mode, do not use this in production".
>>
>> Just something very easy to get you going.
>>
>> On Thu, Apr 13, 2017 at 12:16 PM Galder Zamarreño <[hidden email]> wrote:
>>
>> --
>> Galder Zamarreño
>> Infinispan, Red Hat
>>
>>> On 13 Apr 2017, at 09:50, Gustavo Fernandes <[hidden email]> wrote:
>>>
>>> On Thu, Apr 13, 2017 at 6:38 AM, Galder Zamarreño <[hidden email]> wrote:
>>> Hi all,
>>>
>>> As per some discussions we had yesterday on IRC w/ Tristan, Gustavo and Sebastian, I've created a docker image snapshot that reverts the change stop protected caches from requiring security enabled [1].
>>>
>>> In other words, I've removed [2]. The reason for temporarily doing that is because with the change as is, the changes required for a default server distro require that the entire cache manager's security is enabled. This is in turn creates a lot of problems with health and running checks used by Kubernetes/OpenShift amongst other things.
>>>
>>> Judging from our discussions on IRC, the idea is for such change to be present in 9.0.1, but I'd like to get final confirmation from Tristan et al.
>>>
>>>
>>> +1
>>>
>>> Regarding the "security by default" discussion, I think we should ship configurations cloud.xml, clustered.xml and standalone.xml with security enabled and disabled variants, and let users
>>> decide which one to pick based on the use case.
>>
>> I think that's a better idea.
>>
>> We could by default have a secured one, but switching to an insecure configuration should be doable with minimal effort, e.g. just switching config file.
>>
>> As highlighted above, any secured configuration should work out-of-the-box with our docker images, e.g. WRT healthy/running checks.
>>
>> Cheers,
>>
>>>
>>> Gustavo.
>>>
>>>
>>> Cheers,
>>>
>>> [1] https://hub.docker.com/r/galderz/infinispan-server/tags/ (9.0.1-SNAPSHOT tag for anyone interested)
>>> [2] https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/main/java/org/infinispan/server/hotrod/CacheDecodeContext.java#L114-L118
>>> --
>>> Galder Zamarreño
>>> Infinispan, Red Hat
>>>
>>>> On 30 Mar 2017, at 14:25, Tristan Tarrant <[hidden email]> wrote:
>>>>
>>>> Dear all,
>>>>
>>>> after a mini chat on IRC, I wanted to bring this to everybody's attention.
>>>>
>>>> We should make the Hot Rod endpoint require authentication in the
>>>> out-of-the-box configuration.
>>>> The proposal is to enable the PLAIN (or, preferably, DIGEST) SASL
>>>> mechanism against the ApplicationRealm and require users to run the
>>>> add-user script.
>>>> This would achieve two goals:
>>>> - secure out-of-the-box configuration, which is always a good idea
>>>> - access to the "protected" schema and script caches which is prevented
>>>> when not on loopback on non-authenticated endpoints.
>>>>
>>>> Tristan
>>>> --
>>>> Tristan Tarrant
>>>> Infinispan Lead
>>>> JBoss, a division of Red Hat
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> --
>> SEBASTIAN ŁASKAWIEC
>> INFINISPAN DEVELOPER
>> Red Hat EMEA
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Hot Rod secured by default

Sebastian Laskawiec
The proposal look ok to me.

But I would also like to highlight one thing - it seems you can't access secured cache properties using CLI. This seems wrong to me (if you can invoke the cli, in 99,99% of the cases you have access to the machine, so you can do whatever you want). It also breaks healthchecks in Docker image. 

I would like to make sure we will address those concerns.

On Wed, Apr 19, 2017 at 10:59 AM Tristan Tarrant <[hidden email]> wrote:
Currently the "protected cache access" security is implemented as follows:

- if authorization is enabled || client is on loopback
   allow

The first check also implies that authentication needs to be in place,
as the authorization checks need a valid Subject.

Unfortunately authorization is very heavy-weight and actually overkill
even for "normal" secure usage.

My proposal is as follows:
- the "default" configuration files are "secure" by default
- provide clearly marked "unsecured" configuration files, which the user
can use
- drop the "protected cache" check completely

And definitely NO to a dev switch.

Tristan

On 19/04/2017 10:05, Galder Zamarreño wrote:
> Agree with Wolf. Let's keep it simple by just providing extra configuration files for dev/unsecure envs.
>
> Cheers,
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>> On 15 Apr 2017, at 12:57, Wolf Fink <[hidden email]> wrote:
>>
>> I would think a "switch" can have other impacts as you need to check it in the code - and might have security leaks here
>>
>> So what is wrong with some configurations which are the default and secured.
>> and a "*-dev or *-unsecure" configuration to start easy.
>> Also this can be used in production if there is no need for security
>>
>> On Thu, Apr 13, 2017 at 4:13 PM, Sebastian Laskawiec <[hidden email]> wrote:
>> I still think it would be better to create an extra switch to run infinispan in "development mode". This means no authentication, no encryption, possibly with JGroups stack tuned for fast discovery (especially in Kubernetes) and a big warning saying "You are in development mode, do not use this in production".
>>
>> Just something very easy to get you going.
>>
>> On Thu, Apr 13, 2017 at 12:16 PM Galder Zamarreño <[hidden email]> wrote:
>>
>> --
>> Galder Zamarreño
>> Infinispan, Red Hat
>>
>>> On 13 Apr 2017, at 09:50, Gustavo Fernandes <[hidden email]> wrote:
>>>
>>> On Thu, Apr 13, 2017 at 6:38 AM, Galder Zamarreño <[hidden email]> wrote:
>>> Hi all,
>>>
>>> As per some discussions we had yesterday on IRC w/ Tristan, Gustavo and Sebastian, I've created a docker image snapshot that reverts the change stop protected caches from requiring security enabled [1].
>>>
>>> In other words, I've removed [2]. The reason for temporarily doing that is because with the change as is, the changes required for a default server distro require that the entire cache manager's security is enabled. This is in turn creates a lot of problems with health and running checks used by Kubernetes/OpenShift amongst other things.
>>>
>>> Judging from our discussions on IRC, the idea is for such change to be present in 9.0.1, but I'd like to get final confirmation from Tristan et al.
>>>
>>>
>>> +1
>>>
>>> Regarding the "security by default" discussion, I think we should ship configurations cloud.xml, clustered.xml and standalone.xml with security enabled and disabled variants, and let users
>>> decide which one to pick based on the use case.
>>
>> I think that's a better idea.
>>
>> We could by default have a secured one, but switching to an insecure configuration should be doable with minimal effort, e.g. just switching config file.
>>
>> As highlighted above, any secured configuration should work out-of-the-box with our docker images, e.g. WRT healthy/running checks.
>>
>> Cheers,
>>
>>>
>>> Gustavo.
>>>
>>>
>>> Cheers,
>>>
>>> [1] https://hub.docker.com/r/galderz/infinispan-server/tags/ (9.0.1-SNAPSHOT tag for anyone interested)
>>> [2] https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/main/java/org/infinispan/server/hotrod/CacheDecodeContext.java#L114-L118
>>> --
>>> Galder Zamarreño
>>> Infinispan, Red Hat
>>>
>>>> On 30 Mar 2017, at 14:25, Tristan Tarrant <[hidden email]> wrote:
>>>>
>>>> Dear all,
>>>>
>>>> after a mini chat on IRC, I wanted to bring this to everybody's attention.
>>>>
>>>> We should make the Hot Rod endpoint require authentication in the
>>>> out-of-the-box configuration.
>>>> The proposal is to enable the PLAIN (or, preferably, DIGEST) SASL
>>>> mechanism against the ApplicationRealm and require users to run the
>>>> add-user script.
>>>> This would achieve two goals:
>>>> - secure out-of-the-box configuration, which is always a good idea
>>>> - access to the "protected" schema and script caches which is prevented
>>>> when not on loopback on non-authenticated endpoints.
>>>>
>>>> Tristan
>>>> --
>>>> Tristan Tarrant
>>>> Infinispan Lead
>>>> JBoss, a division of Red Hat
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> --
>> SEBASTIAN ŁASKAWIEC
>> INFINISPAN DEVELOPER
>> Red Hat EMEA
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--

SEBASTIAN ŁASKAWIEC

INFINISPAN DEVELOPER


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Hot Rod secured by default

Galder Zamarreno
In reply to this post by Tristan Tarrant-2
+100

--
Galder Zamarreño
Infinispan, Red Hat

> On 19 Apr 2017, at 10:57, Tristan Tarrant <[hidden email]> wrote:
>
> Currently the "protected cache access" security is implemented as follows:
>
> - if authorization is enabled || client is on loopback
>   allow
>
> The first check also implies that authentication needs to be in place,
> as the authorization checks need a valid Subject.
>
> Unfortunately authorization is very heavy-weight and actually overkill
> even for "normal" secure usage.
>
> My proposal is as follows:
> - the "default" configuration files are "secure" by default
> - provide clearly marked "unsecured" configuration files, which the user
> can use
> - drop the "protected cache" check completely
>
> And definitely NO to a dev switch.
>
> Tristan
>
> On 19/04/2017 10:05, Galder Zamarreño wrote:
>> Agree with Wolf. Let's keep it simple by just providing extra configuration files for dev/unsecure envs.
>>
>> Cheers,
>> --
>> Galder Zamarreño
>> Infinispan, Red Hat
>>
>>> On 15 Apr 2017, at 12:57, Wolf Fink <[hidden email]> wrote:
>>>
>>> I would think a "switch" can have other impacts as you need to check it in the code - and might have security leaks here
>>>
>>> So what is wrong with some configurations which are the default and secured.
>>> and a "*-dev or *-unsecure" configuration to start easy.
>>> Also this can be used in production if there is no need for security
>>>
>>> On Thu, Apr 13, 2017 at 4:13 PM, Sebastian Laskawiec <[hidden email]> wrote:
>>> I still think it would be better to create an extra switch to run infinispan in "development mode". This means no authentication, no encryption, possibly with JGroups stack tuned for fast discovery (especially in Kubernetes) and a big warning saying "You are in development mode, do not use this in production".
>>>
>>> Just something very easy to get you going.
>>>
>>> On Thu, Apr 13, 2017 at 12:16 PM Galder Zamarreño <[hidden email]> wrote:
>>>
>>> --
>>> Galder Zamarreño
>>> Infinispan, Red Hat
>>>
>>>> On 13 Apr 2017, at 09:50, Gustavo Fernandes <[hidden email]> wrote:
>>>>
>>>> On Thu, Apr 13, 2017 at 6:38 AM, Galder Zamarreño <[hidden email]> wrote:
>>>> Hi all,
>>>>
>>>> As per some discussions we had yesterday on IRC w/ Tristan, Gustavo and Sebastian, I've created a docker image snapshot that reverts the change stop protected caches from requiring security enabled [1].
>>>>
>>>> In other words, I've removed [2]. The reason for temporarily doing that is because with the change as is, the changes required for a default server distro require that the entire cache manager's security is enabled. This is in turn creates a lot of problems with health and running checks used by Kubernetes/OpenShift amongst other things.
>>>>
>>>> Judging from our discussions on IRC, the idea is for such change to be present in 9.0.1, but I'd like to get final confirmation from Tristan et al.
>>>>
>>>>
>>>> +1
>>>>
>>>> Regarding the "security by default" discussion, I think we should ship configurations cloud.xml, clustered.xml and standalone.xml with security enabled and disabled variants, and let users
>>>> decide which one to pick based on the use case.
>>>
>>> I think that's a better idea.
>>>
>>> We could by default have a secured one, but switching to an insecure configuration should be doable with minimal effort, e.g. just switching config file.
>>>
>>> As highlighted above, any secured configuration should work out-of-the-box with our docker images, e.g. WRT healthy/running checks.
>>>
>>> Cheers,
>>>
>>>>
>>>> Gustavo.
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> [1] https://hub.docker.com/r/galderz/infinispan-server/tags/ (9.0.1-SNAPSHOT tag for anyone interested)
>>>> [2] https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/main/java/org/infinispan/server/hotrod/CacheDecodeContext.java#L114-L118
>>>> --
>>>> Galder Zamarreño
>>>> Infinispan, Red Hat
>>>>
>>>>> On 30 Mar 2017, at 14:25, Tristan Tarrant <[hidden email]> wrote:
>>>>>
>>>>> Dear all,
>>>>>
>>>>> after a mini chat on IRC, I wanted to bring this to everybody's attention.
>>>>>
>>>>> We should make the Hot Rod endpoint require authentication in the
>>>>> out-of-the-box configuration.
>>>>> The proposal is to enable the PLAIN (or, preferably, DIGEST) SASL
>>>>> mechanism against the ApplicationRealm and require users to run the
>>>>> add-user script.
>>>>> This would achieve two goals:
>>>>> - secure out-of-the-box configuration, which is always a good idea
>>>>> - access to the "protected" schema and script caches which is prevented
>>>>> when not on loopback on non-authenticated endpoints.
>>>>>
>>>>> Tristan
>>>>> --
>>>>> Tristan Tarrant
>>>>> Infinispan Lead
>>>>> JBoss, a division of Red Hat
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> --
>>> SEBASTIAN ŁASKAWIEC
>>> INFINISPAN DEVELOPER
>>> Red Hat EMEA
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Hot Rod secured by default

Tristan Tarrant-2
In reply to this post by Sebastian Laskawiec
That is caused by not wrapping the calls in PrivilegedActions in all the
correct places and is a bug.

Tristan

On 19/04/2017 11:34, Sebastian Laskawiec wrote:

> The proposal look ok to me.
>
> But I would also like to highlight one thing - it seems you can't access
> secured cache properties using CLI. This seems wrong to me (if you can
> invoke the cli, in 99,99% of the cases you have access to the machine,
> so you can do whatever you want). It also breaks healthchecks in Docker
> image.
>
> I would like to make sure we will address those concerns.
>
> On Wed, Apr 19, 2017 at 10:59 AM Tristan Tarrant <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Currently the "protected cache access" security is implemented as
>     follows:
>
>     - if authorization is enabled || client is on loopback
>         allow
>
>     The first check also implies that authentication needs to be in place,
>     as the authorization checks need a valid Subject.
>
>     Unfortunately authorization is very heavy-weight and actually overkill
>     even for "normal" secure usage.
>
>     My proposal is as follows:
>     - the "default" configuration files are "secure" by default
>     - provide clearly marked "unsecured" configuration files, which the user
>     can use
>     - drop the "protected cache" check completely
>
>     And definitely NO to a dev switch.
>
>     Tristan
>
>     On 19/04/2017 10:05, Galder Zamarreño wrote:
>      > Agree with Wolf. Let's keep it simple by just providing extra
>     configuration files for dev/unsecure envs.
>      >
>      > Cheers,
>      > --
>      > Galder Zamarreño
>      > Infinispan, Red Hat
>      >
>      >> On 15 Apr 2017, at 12:57, Wolf Fink <[hidden email]
>     <mailto:[hidden email]>> wrote:
>      >>
>      >> I would think a "switch" can have other impacts as you need to
>     check it in the code - and might have security leaks here
>      >>
>      >> So what is wrong with some configurations which are the default
>     and secured.
>      >> and a "*-dev or *-unsecure" configuration to start easy.
>      >> Also this can be used in production if there is no need for security
>      >>
>      >> On Thu, Apr 13, 2017 at 4:13 PM, Sebastian Laskawiec
>     <[hidden email] <mailto:[hidden email]>> wrote:
>      >> I still think it would be better to create an extra switch to
>     run infinispan in "development mode". This means no authentication,
>     no encryption, possibly with JGroups stack tuned for fast discovery
>     (especially in Kubernetes) and a big warning saying "You are in
>     development mode, do not use this in production".
>      >>
>      >> Just something very easy to get you going.
>      >>
>      >> On Thu, Apr 13, 2017 at 12:16 PM Galder Zamarreño
>     <[hidden email] <mailto:[hidden email]>> wrote:
>      >>
>      >> --
>      >> Galder Zamarreño
>      >> Infinispan, Red Hat
>      >>
>      >>> On 13 Apr 2017, at 09:50, Gustavo Fernandes
>     <[hidden email] <mailto:[hidden email]>> wrote:
>      >>>
>      >>> On Thu, Apr 13, 2017 at 6:38 AM, Galder Zamarreño
>     <[hidden email] <mailto:[hidden email]>> wrote:
>      >>> Hi all,
>      >>>
>      >>> As per some discussions we had yesterday on IRC w/ Tristan,
>     Gustavo and Sebastian, I've created a docker image snapshot that
>     reverts the change stop protected caches from requiring security
>     enabled [1].
>      >>>
>      >>> In other words, I've removed [2]. The reason for temporarily
>     doing that is because with the change as is, the changes required
>     for a default server distro require that the entire cache manager's
>     security is enabled. This is in turn creates a lot of problems with
>     health and running checks used by Kubernetes/OpenShift amongst other
>     things.
>      >>>
>      >>> Judging from our discussions on IRC, the idea is for such
>     change to be present in 9.0.1, but I'd like to get final
>     confirmation from Tristan et al.
>      >>>
>      >>>
>      >>> +1
>      >>>
>      >>> Regarding the "security by default" discussion, I think we
>     should ship configurations cloud.xml, clustered.xml and
>     standalone.xml with security enabled and disabled variants, and let
>     users
>      >>> decide which one to pick based on the use case.
>      >>
>      >> I think that's a better idea.
>      >>
>      >> We could by default have a secured one, but switching to an
>     insecure configuration should be doable with minimal effort, e.g.
>     just switching config file.
>      >>
>      >> As highlighted above, any secured configuration should work
>     out-of-the-box with our docker images, e.g. WRT healthy/running checks.
>      >>
>      >> Cheers,
>      >>
>      >>>
>      >>> Gustavo.
>      >>>
>      >>>
>      >>> Cheers,
>      >>>
>      >>> [1] https://hub.docker.com/r/galderz/infinispan-server/tags/
>     (9.0.1-SNAPSHOT tag for anyone interested)
>      >>> [2]
>     https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/main/java/org/infinispan/server/hotrod/CacheDecodeContext.java#L114-L118
>      >>> --
>      >>> Galder Zamarreño
>      >>> Infinispan, Red Hat
>      >>>
>      >>>> On 30 Mar 2017, at 14:25, Tristan Tarrant <[hidden email]
>     <mailto:[hidden email]>> wrote:
>      >>>>
>      >>>> Dear all,
>      >>>>
>      >>>> after a mini chat on IRC, I wanted to bring this to
>     everybody's attention.
>      >>>>
>      >>>> We should make the Hot Rod endpoint require authentication in the
>      >>>> out-of-the-box configuration.
>      >>>> The proposal is to enable the PLAIN (or, preferably, DIGEST) SASL
>      >>>> mechanism against the ApplicationRealm and require users to
>     run the
>      >>>> add-user script.
>      >>>> This would achieve two goals:
>      >>>> - secure out-of-the-box configuration, which is always a good idea
>      >>>> - access to the "protected" schema and script caches which is
>     prevented
>      >>>> when not on loopback on non-authenticated endpoints.
>      >>>>
>      >>>> Tristan
>      >>>> --
>      >>>> Tristan Tarrant
>      >>>> Infinispan Lead
>      >>>> JBoss, a division of Red Hat
>      >>>> _______________________________________________
>      >>>> infinispan-dev mailing list
>      >>>> [hidden email]
>     <mailto:[hidden email]>
>      >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >>>
>      >>>
>      >>> _______________________________________________
>      >>> infinispan-dev mailing list
>      >>> [hidden email]
>     <mailto:[hidden email]>
>      >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >>>
>      >>> _______________________________________________
>      >>> infinispan-dev mailing list
>      >>> [hidden email]
>     <mailto:[hidden email]>
>      >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >>
>      >>
>      >> _______________________________________________
>      >> infinispan-dev mailing list
>      >> [hidden email]
>     <mailto:[hidden email]>
>      >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >> --
>      >> SEBASTIAN ŁASKAWIEC
>      >> INFINISPAN DEVELOPER
>      >> Red Hat EMEA
>      >>
>      >>
>      >> _______________________________________________
>      >> infinispan-dev mailing list
>      >> [hidden email]
>     <mailto:[hidden email]>
>      >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >>
>      >> _______________________________________________
>      >> infinispan-dev mailing list
>      >> [hidden email]
>     <mailto:[hidden email]>
>      >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >
>      >
>      > _______________________________________________
>      > infinispan-dev mailing list
>      > [hidden email]
>     <mailto:[hidden email]>
>      > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >
>
>     --
>     Tristan Tarrant
>     Infinispan Lead
>     JBoss, a division of Red Hat
>     _______________________________________________
>     infinispan-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
>
> SEBASTIANŁASKAWIEC
>
> INFINISPAN DEVELOPER
>
> Red HatEMEA <https://www.redhat.com/>
>
> <https://red.ht/sig>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Hot Rod secured by default

Galder Zamarreno
Hi all,

Tristan and I had chat yesterday and I've distilled the contents of the discussion and the feedback here into a JIRA [1]. The JIRA contains several subtasks to handle these aspects:

1. Remove auth check in server's CacheDecodeContext.
2. Default server configuration should require authentication in all entry points.
3. Provide an unauthenticated configuration that users can easily switch to.
4. Remove default username+passwords in docker image and instead show an info/warn message when these are not provided.
5. Add capability to pass in app user role groups to docker image easily, so that its easy to add authorization on top of the server.

Cheers,

[1] https://issues.jboss.org/browse/ISPN-7811
--
Galder Zamarreño
Infinispan, Red Hat

> On 19 Apr 2017, at 12:04, Tristan Tarrant <[hidden email]> wrote:
>
> That is caused by not wrapping the calls in PrivilegedActions in all the
> correct places and is a bug.
>
> Tristan
>
> On 19/04/2017 11:34, Sebastian Laskawiec wrote:
>> The proposal look ok to me.
>>
>> But I would also like to highlight one thing - it seems you can't access
>> secured cache properties using CLI. This seems wrong to me (if you can
>> invoke the cli, in 99,99% of the cases you have access to the machine,
>> so you can do whatever you want). It also breaks healthchecks in Docker
>> image.
>>
>> I would like to make sure we will address those concerns.
>>
>> On Wed, Apr 19, 2017 at 10:59 AM Tristan Tarrant <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>    Currently the "protected cache access" security is implemented as
>>    follows:
>>
>>    - if authorization is enabled || client is on loopback
>>        allow
>>
>>    The first check also implies that authentication needs to be in place,
>>    as the authorization checks need a valid Subject.
>>
>>    Unfortunately authorization is very heavy-weight and actually overkill
>>    even for "normal" secure usage.
>>
>>    My proposal is as follows:
>>    - the "default" configuration files are "secure" by default
>>    - provide clearly marked "unsecured" configuration files, which the user
>>    can use
>>    - drop the "protected cache" check completely
>>
>>    And definitely NO to a dev switch.
>>
>>    Tristan
>>
>>    On 19/04/2017 10:05, Galder Zamarreño wrote:
>>> Agree with Wolf. Let's keep it simple by just providing extra
>>    configuration files for dev/unsecure envs.
>>>
>>> Cheers,
>>> --
>>> Galder Zamarreño
>>> Infinispan, Red Hat
>>>
>>>> On 15 Apr 2017, at 12:57, Wolf Fink <[hidden email]
>>    <mailto:[hidden email]>> wrote:
>>>>
>>>> I would think a "switch" can have other impacts as you need to
>>    check it in the code - and might have security leaks here
>>>>
>>>> So what is wrong with some configurations which are the default
>>    and secured.
>>>> and a "*-dev or *-unsecure" configuration to start easy.
>>>> Also this can be used in production if there is no need for security
>>>>
>>>> On Thu, Apr 13, 2017 at 4:13 PM, Sebastian Laskawiec
>>    <[hidden email] <mailto:[hidden email]>> wrote:
>>>> I still think it would be better to create an extra switch to
>>    run infinispan in "development mode". This means no authentication,
>>    no encryption, possibly with JGroups stack tuned for fast discovery
>>    (especially in Kubernetes) and a big warning saying "You are in
>>    development mode, do not use this in production".
>>>>
>>>> Just something very easy to get you going.
>>>>
>>>> On Thu, Apr 13, 2017 at 12:16 PM Galder Zamarreño
>>    <[hidden email] <mailto:[hidden email]>> wrote:
>>>>
>>>> --
>>>> Galder Zamarreño
>>>> Infinispan, Red Hat
>>>>
>>>>> On 13 Apr 2017, at 09:50, Gustavo Fernandes
>>    <[hidden email] <mailto:[hidden email]>> wrote:
>>>>>
>>>>> On Thu, Apr 13, 2017 at 6:38 AM, Galder Zamarreño
>>    <[hidden email] <mailto:[hidden email]>> wrote:
>>>>> Hi all,
>>>>>
>>>>> As per some discussions we had yesterday on IRC w/ Tristan,
>>    Gustavo and Sebastian, I've created a docker image snapshot that
>>    reverts the change stop protected caches from requiring security
>>    enabled [1].
>>>>>
>>>>> In other words, I've removed [2]. The reason for temporarily
>>    doing that is because with the change as is, the changes required
>>    for a default server distro require that the entire cache manager's
>>    security is enabled. This is in turn creates a lot of problems with
>>    health and running checks used by Kubernetes/OpenShift amongst other
>>    things.
>>>>>
>>>>> Judging from our discussions on IRC, the idea is for such
>>    change to be present in 9.0.1, but I'd like to get final
>>    confirmation from Tristan et al.
>>>>>
>>>>>
>>>>> +1
>>>>>
>>>>> Regarding the "security by default" discussion, I think we
>>    should ship configurations cloud.xml, clustered.xml and
>>    standalone.xml with security enabled and disabled variants, and let
>>    users
>>>>> decide which one to pick based on the use case.
>>>>
>>>> I think that's a better idea.
>>>>
>>>> We could by default have a secured one, but switching to an
>>    insecure configuration should be doable with minimal effort, e.g.
>>    just switching config file.
>>>>
>>>> As highlighted above, any secured configuration should work
>>    out-of-the-box with our docker images, e.g. WRT healthy/running checks.
>>>>
>>>> Cheers,
>>>>
>>>>>
>>>>> Gustavo.
>>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>> [1] https://hub.docker.com/r/galderz/infinispan-server/tags/
>>    (9.0.1-SNAPSHOT tag for anyone interested)
>>>>> [2]
>>    https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/main/java/org/infinispan/server/hotrod/CacheDecodeContext.java#L114-L118
>>>>> --
>>>>> Galder Zamarreño
>>>>> Infinispan, Red Hat
>>>>>
>>>>>> On 30 Mar 2017, at 14:25, Tristan Tarrant <[hidden email]
>>    <mailto:[hidden email]>> wrote:
>>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>> after a mini chat on IRC, I wanted to bring this to
>>    everybody's attention.
>>>>>>
>>>>>> We should make the Hot Rod endpoint require authentication in the
>>>>>> out-of-the-box configuration.
>>>>>> The proposal is to enable the PLAIN (or, preferably, DIGEST) SASL
>>>>>> mechanism against the ApplicationRealm and require users to
>>    run the
>>>>>> add-user script.
>>>>>> This would achieve two goals:
>>>>>> - secure out-of-the-box configuration, which is always a good idea
>>>>>> - access to the "protected" schema and script caches which is
>>    prevented
>>>>>> when not on loopback on non-authenticated endpoints.
>>>>>>
>>>>>> Tristan
>>>>>> --
>>>>>> Tristan Tarrant
>>>>>> Infinispan Lead
>>>>>> JBoss, a division of Red Hat
>>>>>> _______________________________________________
>>>>>> infinispan-dev mailing list
>>>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>> --
>>>> SEBASTIAN ŁASKAWIEC
>>>> INFINISPAN DEVELOPER
>>>> Red Hat EMEA
>>>>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>    <mailto:[hidden email]>
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>>    --
>>    Tristan Tarrant
>>    Infinispan Lead
>>    JBoss, a division of Red Hat
>>    _______________________________________________
>>    infinispan-dev mailing list
>>    [hidden email] <mailto:[hidden email]>
>>    https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>>
>> SEBASTIANŁASKAWIEC
>>
>> INFINISPAN DEVELOPER
>>
>> Red HatEMEA <https://www.redhat.com/>
>>
>> <https://red.ht/sig>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

[infinispan-dev] Netty SSL Context, was [Hot Rod secured by default]

Sebastian Laskawiec
In reply to this post by Tristan Tarrant-2
I think I've just found the reason why we can not migrate in OpenSSL by default :(

In server scenario we obtain SSLContext (the one from JDK; Netty has similar SslContext) from WildFly. It is already configured along with sercurity realms, domains etc. We then get into this branch of code [1].

In order to do fancy things like SNI we need to remap JDK's SSLContext into Netty's SslContext and the only implementation that can consume SSLContext we have at hand is JdkSslContext.

I honestly have no idea how we could refactor this... And that's a shame because OpenSSL is way faster...


On Fri, Mar 31, 2017 at 6:02 PM Tristan Tarrant <[hidden email]> wrote:
You want to use OpenSSL with Netty:

http://netty.io/wiki/requirements-for-4.x.html#wiki-h4-4

Tristan

On 31/03/2017 15:55, Sebastian Laskawiec wrote:
> Unfortunately TLS still slows down stuff (a lot). When I was doing tests
> for the multi-tenancy router (which is based on TLS/SNI), my average
> results were like this:
>
> Use-caseTypeAvgError
> initConnectionAndPerform10KPutsSingleServerNoSsl1034.81714.424
> initConnectionAndPerform10KPutsSingleServerWithSsl1567.55324.872
> initConnectionAndPerform10KPutsTwoServersWithSslSni1563.22934.05
> initConnectionOnlySingleServerNoSsl*3.389*0.198
> initConnectionOnlySingleServerWithSsl*14.086*0.794
> initConnectionOnlyTwoServersWithSslSni*14.722*0.684
> perform10KPutsSingleServerNoSsl*4.602*0.585
> perform10KPutsSingleServerWithSsl*16.583*0.198
> perform10KPutsTwoServersWithSslSni*17.02*0.794
>
> This is nothing new, but initializing Hot Rod connection took was ~4
> times slower and putting 10K random strings (UUIDs) was also ~4 times
> slower. But what's worth to mention, there is no significant difference
> between TLS and TLS+SNI.
>
> As far as I know, it is possible to install specialized hardware to deal
> with encryption in data centers. It is called SSL Acceleration [1].
> However I'm not aware of any special processor instructions that can
> help you with that. But the implementations are getting better and
> better, so who knows...
>
> But getting back to the original question, I think the problem we are
> trying to solve (correct me if I'm wrong) is to prevent unauthorized
> folks to put their hands on a victims data (either pushing something
> malicious/corrupted to the cache or obtaining something from the cache).
> Another problem is transmission security - encryption. If we want our
> new devs to be secured out of the box, I think we should do both - use
> TLS (without trusting all certificated) and authentication. This makes
> Infinispan harder to use of course. So the other extremum is to turn
> both things off.
>
> I voted for the latter, making Infinispan super easy to use. But you
> guys convinced me that we should care about the security in this case
> too, so I would use PLAIN authentication + TLS. I would also love to see
> one magic switch, for example `./bin/standalone.sh --dev-mode`, which
> would turn all security off.
>
> Thanks,
> Sebastian
>
> [1] https://en.wikipedia.org/wiki/SSL_acceleration
>
>
> On Thu, Mar 30, 2017 at 9:22 PM Dan Berindei <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     I agree with Radim, PLAIN authentication without encryption makes it
>     too easy to sniff the password from another machine.
>
>     I have no idea how expensive SSL encryption is in WildFly, but I think
>     all recent processors have specialized instructions for helping with
>     encryption, so it may not be that bad.
>
>     Even with encryption, if the client trusts all certs, it may be
>     possible for an attacker to insert itself in the middle and decode
>     everything -- depending on network topology and what kind of access
>     the attacker already has. I think it only makes sense to trust all
>     certs if we also implement something like HPKP [1], to make it more
>     like ssh.
>
>     [1]: https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
>
>     Cheers
>     Dan
>
>
>
>     On Thu, Mar 30, 2017 at 7:07 PM, Wolf Fink <[hidden email]
>     <mailto:[hidden email]>> wrote:
>      > +1 to make the default secure.
>      >
>      > -1 SSL by default as it makes it slower and I think not most will
>     use it
>      >
>      > -1 easy trust all certs, That sounds to me we close one door and
>     make it
>      > possible to open another one
>      >
>      >
>      > What if we add an example configuration unsecured which can be
>     simple copied
>      > for examples and to start.
>      >
>      >
>      > On Thu, Mar 30, 2017 at 5:31 PM, Dennis Reed <[hidden email]
>     <mailto:[hidden email]>> wrote:
>      >>
>      >> +1 to authentication and encryption by default.
>      >>   This is 2017, that's how *everything* should be configured.
>      >>
>      >> -1 to making it easy to trust all certs.  That negates the point of
>      >> using encryption in the first place and should really never be done.
>      >>
>      >> If it's too hard to configure the correct way that we think it would
>      >> turn users away, that's a usability problem that needs to be fixed.
>      >>
>      >> -Dennis
>      >>
>      >>
>      >> On 03/30/2017 09:29 AM, Tristan Tarrant wrote:
>      >> > While the "unsecure" over loopback is quite tempting, I would
>     prefer to
>      >> > have homogeneous behaviour with the possibility to disable
>     security
>      >> > altogether for quick demos.
>      >> > Otherwise a developer would need to code differently for the
>     local use
>      >> > case than for the remote one, causing more confusion.
>      >> >
>      >> > Tristan
>      >> >
>      >> > On 30/03/2017 14:54, Sebastian Laskawiec wrote:
>      >> >> I agree the security out of the box is good. But at the same
>     time we
>      >> >> don't want to make Infinispan harder to use for new
>     developers. Out of
>      >> >> the box configuration should be "good enough" to start hacking.
>      >> >>
>      >> >> I would propose to make all the endpoints unprotected (with
>      >> >> authentication disabled) on localhost/loopback and protected when
>      >> >> calling from the outside world.
>      >> >>
>      >> >> On Thu, Mar 30, 2017 at 2:39 PM Tristan Tarrant
>     <[hidden email] <mailto:[hidden email]>
>      >> >> <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>      >> >>
>      >> >>     Dear all,
>      >> >>
>      >> >>     after a mini chat on IRC, I wanted to bring this to
>     everybody's
>      >> >>     attention.
>      >> >>
>      >> >>     We should make the Hot Rod endpoint require
>     authentication in the
>      >> >>     out-of-the-box configuration.
>      >> >>     The proposal is to enable the PLAIN (or, preferably,
>     DIGEST) SASL
>      >> >>     mechanism against the ApplicationRealm and require users
>     to run the
>      >> >>     add-user script.
>      >> >>     This would achieve two goals:
>      >> >>     - secure out-of-the-box configuration, which is always a
>     good idea
>      >> >>     - access to the "protected" schema and script caches which is
>      >> >> prevented
>      >> >>     when not on loopback on non-authenticated endpoints.
>      >> >>
>      >> >>     Tristan
>      >> >>     --
>      >> >>     Tristan Tarrant
>      >> >>     Infinispan Lead
>      >> >>     JBoss, a division of Red Hat
>      >> >>     _______________________________________________
>      >> >>     infinispan-dev mailing list
>      >> >> [hidden email]
>     <mailto:[hidden email]>
>      >> >> <mailto:[hidden email]
>     <mailto:[hidden email]>>
>      >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >> >>
>      >> >>
>      >> >>
>      >> >> _______________________________________________
>      >> >> infinispan-dev mailing list
>      >> >> [hidden email]
>     <mailto:[hidden email]>
>      >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >> >>
>      >> >
>      >> _______________________________________________
>      >> infinispan-dev mailing list
>      >> [hidden email]
>     <mailto:[hidden email]>
>      >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >
>      >
>      >
>      > _______________________________________________
>      > infinispan-dev mailing list
>      > [hidden email]
>     <mailto:[hidden email]>
>      > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     _______________________________________________
>     infinispan-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--

SEBASTIAN ŁASKAWIEC

INFINISPAN DEVELOPER


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Netty SSL Context, was [Hot Rod secured by default]

Gustavo Fernandes-2
On Thu, Jun 1, 2017 at 10:51 AM, Sebastian Laskawiec <[hidden email]> wrote:
I think I've just found the reason why we can not migrate in OpenSSL by default :(

In server scenario we obtain SSLContext (the one from JDK; Netty has similar SslContext) from WildFly. It is already configured along with sercurity realms, domains etc. We then get into this branch of code [1].

In order to do fancy things like SNI we need to remap JDK's SSLContext into Netty's SslContext and the only implementation that can consume SSLContext we have at hand is JdkSslContext.

I honestly have no idea how we could refactor this... And that's a shame because OpenSSL is way faster...


I tried migrating the SSL engine to Netty's in [1] and hit the same wall. What I was told is that the SSLContext in Wildfly is now (version 11?) a capability under 'org.wildfly.security.ssl-context'  and
can be replaced, but I did not try doing that.

Gustavo

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Netty SSL Context, was [Hot Rod secured by default]

Tristan Tarrant-2
We should use this:

https://github.com/wildfly/wildfly-openssl

Tristan

On 6/1/17 1:17 PM, Gustavo Fernandes wrote:

> On Thu, Jun 1, 2017 at 10:51 AM, Sebastian Laskawiec
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     I think I've just found the reason why we can not migrate in OpenSSL
>     by default :(
>
>     In server scenario we obtain S*SL*Context (the one from JDK; Netty
>     has similar S*sl*Context) from WildFly. It is already configured
>     along with sercurity realms, domains etc. We then get into this
>     branch of code [1].
>
>     In order to do fancy things like SNI we need to remap JDK's
>     SSLContext into Netty's SslContext and the only implementation that
>     can consume SSLContext we have at hand is JdkSslContext.
>
>     I honestly have no idea how we could refactor this... And that's a
>     shame because OpenSSL is way faster...
>
>
>
> I tried migrating the SSL engine to Netty's in [1] and hit the same
> wall. What I was told is that the SSLContext in Wildfly is now (version
> 11?) a capability under 'org.wildfly.security.ssl-context'  and
> can be replaced, but I did not try doing that.
>
>
> [1] https://issues.jboss.org/browse/ISPN-6990 
> <https://issues.jboss.org/browse/ISPN-6990>
>
> Gustavo
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Netty SSL Context, was [Hot Rod secured by default]

Sebastian Laskawiec
We actually have more alternatives - e.g. we could use OpenSSL via Boring SSL library [1]. The root problem remains the same - we can use only what we obtain from the WF server. And currently we obtain only JSSE SSLContext...

[1] http://netty.io/wiki/forked-tomcat-native.html

On Mon, Jun 5, 2017 at 10:34 AM Tristan Tarrant <[hidden email]> wrote:
We should use this:

https://github.com/wildfly/wildfly-openssl

Tristan

On 6/1/17 1:17 PM, Gustavo Fernandes wrote:
> On Thu, Jun 1, 2017 at 10:51 AM, Sebastian Laskawiec
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     I think I've just found the reason why we can not migrate in OpenSSL
>     by default :(
>
>     In server scenario we obtain S*SL*Context (the one from JDK; Netty
>     has similar S*sl*Context) from WildFly. It is already configured
>     along with sercurity realms, domains etc. We then get into this
>     branch of code [1].
>
>     In order to do fancy things like SNI we need to remap JDK's
>     SSLContext into Netty's SslContext and the only implementation that
>     can consume SSLContext we have at hand is JdkSslContext.
>
>     I honestly have no idea how we could refactor this... And that's a
>     shame because OpenSSL is way faster...
>
>
>
> I tried migrating the SSL engine to Netty's in [1] and hit the same
> wall. What I was told is that the SSLContext in Wildfly is now (version
> 11?) a capability under 'org.wildfly.security.ssl-context'  and
> can be replaced, but I did not try doing that.
>
>
> [1] https://issues.jboss.org/browse/ISPN-6990
> <https://issues.jboss.org/browse/ISPN-6990>
>
> Gustavo
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--

SEBASTIAN ŁASKAWIEC

INFINISPAN DEVELOPER


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Netty SSL Context, was [Hot Rod secured by default]

Tristan Tarrant-2
Actually, WildFly 11 will allow this.
Additionally, in our restructured server, we can do whatever we want.

Tristan

On 6/5/17 12:29 PM, Sebastian Laskawiec wrote:

> We actually have more alternatives - e.g. we could use OpenSSL via
> Boring SSL library [1]. The root problem remains the same - we can use
> only what we obtain from the WF server. And currently we obtain
> only JSSE SSLContext...
>
> [1] http://netty.io/wiki/forked-tomcat-native.html
>
> On Mon, Jun 5, 2017 at 10:34 AM Tristan Tarrant <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     We should use this:
>
>     https://github.com/wildfly/wildfly-openssl
>
>     Tristan
>
>     On 6/1/17 1:17 PM, Gustavo Fernandes wrote:
>      > On Thu, Jun 1, 2017 at 10:51 AM, Sebastian Laskawiec
>      > <[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>      >
>      >     I think I've just found the reason why we can not migrate in
>     OpenSSL
>      >     by default :(
>      >
>      >     In server scenario we obtain S*SL*Context (the one from JDK;
>     Netty
>      >     has similar S*sl*Context) from WildFly. It is already configured
>      >     along with sercurity realms, domains etc. We then get into this
>      >     branch of code [1].
>      >
>      >     In order to do fancy things like SNI we need to remap JDK's
>      >     SSLContext into Netty's SslContext and the only
>     implementation that
>      >     can consume SSLContext we have at hand is JdkSslContext.
>      >
>      >     I honestly have no idea how we could refactor this... And
>     that's a
>      >     shame because OpenSSL is way faster...
>      >
>      >
>      >
>      > I tried migrating the SSL engine to Netty's in [1] and hit the same
>      > wall. What I was told is that the SSLContext in Wildfly is now
>     (version
>      > 11?) a capability under 'org.wildfly.security.ssl-context'  and
>      > can be replaced, but I did not try doing that.
>      >
>      >
>      > [1] https://issues.jboss.org/browse/ISPN-6990
>      > <https://issues.jboss.org/browse/ISPN-6990>
>      >
>      > Gustavo
>      >
>      >
>      > _______________________________________________
>      > infinispan-dev mailing list
>      > [hidden email]
>     <mailto:[hidden email]>
>      > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>      >
>
>     --
>     Tristan Tarrant
>     Infinispan Lead
>     JBoss, a division of Red Hat
>     _______________________________________________
>     infinispan-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
>
> SEBASTIANŁASKAWIEC
>
> INFINISPAN DEVELOPER
>
> Red HatEMEA <https://www.redhat.com/>
>
> <https://red.ht/sig>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Hot Rod secured by default

Katia Aresti
In reply to this post by Galder Zamarreno
Hi all,

I came up to this thread now, at the time I did not understand what we discussed here.

Let me tell you my experience of today.

I want to create a vert.x application, super simple, that connects to infinispan-server. Everything in open-shift.
I take an vert-x example as base, super simple one, that deploys directly a super simple web app with a simple command line. Works fine, I see the "hello world" webapp in my laptop on the openshift and my navigator.

I want this time to access to infinispan-server. I go into the interface, and I say "hey, grab the jboss/infinispan-server" image from docker registry. I try to go to the REST console, and oh, I need to authenticate. I go back, and then I read that I need to put 2 env variables. So there it is, now it works.
And then I want to go to the console, requires me to put again the user/password. And it does not work. And I don't see how to disable security. And I don't know what to do. And I'm like : why do I need security at all here ?
I'm a lambda dev, in a lambda project, considering using infinispan-server for the first time, and at this point, security of the cache I don't care and I don't know why I have to deal with it.

I know you acted a ticket and decided to have security on by default. IMHO lambda dev creating the hello world with the docker image provided by jboss... does not care about it. At all. He or she just wants to see everything working as soon as possible. Once they decide to use infinispan, if the cache needs to be secured, which seems to be recommended, they will go into that point (devs and ops) and change the code and the configuration to add the security level they need for their project.

I wonder if you want to reconsider the "secured by default" point after my experience. 

My 2 cents,

Katia

On Tue, May 9, 2017 at 2:24 PM, Galder Zamarreño <[hidden email]> wrote:
Hi all,

Tristan and I had chat yesterday and I've distilled the contents of the discussion and the feedback here into a JIRA [1]. The JIRA contains several subtasks to handle these aspects:

1. Remove auth check in server's CacheDecodeContext.
2. Default server configuration should require authentication in all entry points.
3. Provide an unauthenticated configuration that users can easily switch to.
4. Remove default username+passwords in docker image and instead show an info/warn message when these are not provided.
5. Add capability to pass in app user role groups to docker image easily, so that its easy to add authorization on top of the server.

Cheers,

[1] https://issues.jboss.org/browse/ISPN-7811
--
Galder Zamarreño
Infinispan, Red Hat

> On 19 Apr 2017, at 12:04, Tristan Tarrant <[hidden email]> wrote:
>
> That is caused by not wrapping the calls in PrivilegedActions in all the
> correct places and is a bug.
>
> Tristan
>
> On 19/04/2017 11:34, Sebastian Laskawiec wrote:
>> The proposal look ok to me.
>>
>> But I would also like to highlight one thing - it seems you can't access
>> secured cache properties using CLI. This seems wrong to me (if you can
>> invoke the cli, in 99,99% of the cases you have access to the machine,
>> so you can do whatever you want). It also breaks healthchecks in Docker
>> image.
>>
>> I would like to make sure we will address those concerns.
>>
>> On Wed, Apr 19, 2017 at 10:59 AM Tristan Tarrant <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>    Currently the "protected cache access" security is implemented as
>>    follows:
>>
>>    - if authorization is enabled || client is on loopback
>>        allow
>>
>>    The first check also implies that authentication needs to be in place,
>>    as the authorization checks need a valid Subject.
>>
>>    Unfortunately authorization is very heavy-weight and actually overkill
>>    even for "normal" secure usage.
>>
>>    My proposal is as follows:
>>    - the "default" configuration files are "secure" by default
>>    - provide clearly marked "unsecured" configuration files, which the user
>>    can use
>>    - drop the "protected cache" check completely
>>
>>    And definitely NO to a dev switch.
>>
>>    Tristan
>>
>>    On 19/04/2017 10:05, Galder Zamarreño wrote:
>>> Agree with Wolf. Let's keep it simple by just providing extra
>>    configuration files for dev/unsecure envs.
>>>
>>> Cheers,
>>> --
>>> Galder Zamarreño
>>> Infinispan, Red Hat
>>>
>>>> On 15 Apr 2017, at 12:57, Wolf Fink <[hidden email]
>>    <mailto:[hidden email]>> wrote:
>>>>
>>>> I would think a "switch" can have other impacts as you need to
>>    check it in the code - and might have security leaks here
>>>>
>>>> So what is wrong with some configurations which are the default
>>    and secured.
>>>> and a "*-dev or *-unsecure" configuration to start easy.
>>>> Also this can be used in production if there is no need for security
>>>>
>>>> On Thu, Apr 13, 2017 at 4:13 PM, Sebastian Laskawiec
>>    <[hidden email] <mailto:[hidden email]>> wrote:
>>>> I still think it would be better to create an extra switch to
>>    run infinispan in "development mode". This means no authentication,
>>    no encryption, possibly with JGroups stack tuned for fast discovery
>>    (especially in Kubernetes) and a big warning saying "You are in
>>    development mode, do not use this in production".
>>>>
>>>> Just something very easy to get you going.
>>>>
>>>> On Thu, Apr 13, 2017 at 12:16 PM Galder Zamarreño
>>    <[hidden email] <mailto:[hidden email]>> wrote:
>>>>
>>>> --
>>>> Galder Zamarreño
>>>> Infinispan, Red Hat
>>>>
>>>>> On 13 Apr 2017, at 09:50, Gustavo Fernandes
>>    <[hidden email] <mailto:[hidden email]>> wrote:
>>>>>
>>>>> On Thu, Apr 13, 2017 at 6:38 AM, Galder Zamarreño
>>    <[hidden email] <mailto:[hidden email]>> wrote:
>>>>> Hi all,
>>>>>
>>>>> As per some discussions we had yesterday on IRC w/ Tristan,
>>    Gustavo and Sebastian, I've created a docker image snapshot that
>>    reverts the change stop protected caches from requiring security
>>    enabled [1].
>>>>>
>>>>> In other words, I've removed [2]. The reason for temporarily
>>    doing that is because with the change as is, the changes required
>>    for a default server distro require that the entire cache manager's
>>    security is enabled. This is in turn creates a lot of problems with
>>    health and running checks used by Kubernetes/OpenShift amongst other
>>    things.
>>>>>
>>>>> Judging from our discussions on IRC, the idea is for such
>>    change to be present in 9.0.1, but I'd like to get final
>>    confirmation from Tristan et al.
>>>>>
>>>>>
>>>>> +1
>>>>>
>>>>> Regarding the "security by default" discussion, I think we
>>    should ship configurations cloud.xml, clustered.xml and
>>    standalone.xml with security enabled and disabled variants, and let
>>    users
>>>>> decide which one to pick based on the use case.
>>>>
>>>> I think that's a better idea.
>>>>
>>>> We could by default have a secured one, but switching to an
>>    insecure configuration should be doable with minimal effort, e.g.
>>    just switching config file.
>>>>
>>>> As highlighted above, any secured configuration should work
>>    out-of-the-box with our docker images, e.g. WRT healthy/running checks.
>>>>
>>>> Cheers,
>>>>
>>>>>
>>>>> Gustavo.
>>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>> [1] https://hub.docker.com/r/galderz/infinispan-server/tags/
>>    (9.0.1-SNAPSHOT tag for anyone interested)
>>>>> [2]
>>    https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/main/java/org/infinispan/server/hotrod/CacheDecodeContext.java#L114-L118
>>>>> --
>>>>> Galder Zamarreño
>>>>> Infinispan, Red Hat
>>>>>
>>>>>> On 30 Mar 2017, at 14:25, Tristan Tarrant <[hidden email]
>>    <mailto:[hidden email]>> wrote:
>>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>> after a mini chat on IRC, I wanted to bring this to
>>    everybody's attention.
>>>>>>
>>>>>> We should make the Hot Rod endpoint require authentication in the
>>>>>> out-of-the-box configuration.
>>>>>> The proposal is to enable the PLAIN (or, preferably, DIGEST) SASL
>>>>>> mechanism against the ApplicationRealm and require users to
>>    run the
>>>>>> add-user script.
>>>>>> This would achieve two goals:
>>>>>> - secure out-of-the-box configuration, which is always a good idea
>>>>>> - access to the "protected" schema and script caches which is
>>    prevented
>>>>>> when not on loopback on non-authenticated endpoints.
>>>>>>
>>>>>> Tristan
>>>>>> --
>>>>>> Tristan Tarrant
>>>>>> Infinispan Lead
>>>>>> JBoss, a division of Red Hat
>>>>>> _______________________________________________
>>>>>> infinispan-dev mailing list
>>>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>> --
>>>> SEBASTIAN ŁASKAWIEC
>>>> INFINISPAN DEVELOPER
>>>> Red Hat EMEA
>>>>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>    <mailto:[hidden email]>
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>>    --
>>    Tristan Tarrant
>>    Infinispan Lead
>>    JBoss, a division of Red Hat
>>    _______________________________________________
>>    infinispan-dev mailing list
>>    [hidden email] <mailto:[hidden email]>
>>    https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>>
>> SEBASTIANŁASKAWIEC
>>
>> INFINISPAN DEVELOPER
>>
>> Red HatEMEA <https://www.redhat.com/>
>>
>> <https://red.ht/sig>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Hot Rod secured by default

Emmanuel Bernard
When you deploy a RDBMS on OpenShift, it is secured by default I think and it's not a big deal. It is possible to read back secrets in OpenShift in case you forgot them. 
Maybe there is a way to either document that better, maybe having the same password between console and cache by default is easier ?
We live in a world where we need to take security from day one. Remember OpenShift means you can start stuff super easily, some in the cloud, you don't want it open by default. 
But your input is super valuable, open a j'irai with that experience and let's try and make it easier. 

On 5 Sep 2017, at 18:03, Katia Aresti <[hidden email]> wrote:

Hi all,

I came up to this thread now, at the time I did not understand what we discussed here.

Let me tell you my experience of today.

I want to create a vert.x application, super simple, that connects to infinispan-server. Everything in open-shift.
I take an vert-x example as base, super simple one, that deploys directly a super simple web app with a simple command line. Works fine, I see the "hello world" webapp in my laptop on the openshift and my navigator.

I want this time to access to infinispan-server. I go into the interface, and I say "hey, grab the jboss/infinispan-server" image from docker registry. I try to go to the REST console, and oh, I need to authenticate. I go back, and then I read that I need to put 2 env variables. So there it is, now it works.
And then I want to go to the console, requires me to put again the user/password. And it does not work. And I don't see how to disable security. And I don't know what to do. And I'm like : why do I need security at all here ?
I'm a lambda dev, in a lambda project, considering using infinispan-server for the first time, and at this point, security of the cache I don't care and I don't know why I have to deal with it.

I know you acted a ticket and decided to have security on by default. IMHO lambda dev creating the hello world with the docker image provided by jboss... does not care about it. At all. He or she just wants to see everything working as soon as possible. Once they decide to use infinispan, if the cache needs to be secured, which seems to be recommended, they will go into that point (devs and ops) and change the code and the configuration to add the security level they need for their project.

I wonder if you want to reconsider the "secured by default" point after my experience. 

My 2 cents,

Katia

On Tue, May 9, 2017 at 2:24 PM, Galder Zamarreño <[hidden email]> wrote:
Hi all,

Tristan and I had chat yesterday and I've distilled the contents of the discussion and the feedback here into a JIRA [1]. The JIRA contains several subtasks to handle these aspects:

1. Remove auth check in server's CacheDecodeContext.
2. Default server configuration should require authentication in all entry points.
3. Provide an unauthenticated configuration that users can easily switch to.
4. Remove default username+passwords in docker image and instead show an info/warn message when these are not provided.
5. Add capability to pass in app user role groups to docker image easily, so that its easy to add authorization on top of the server.

Cheers,

[1] https://issues.jboss.org/browse/ISPN-7811
--
Galder Zamarreño
Infinispan, Red Hat

> On 19 Apr 2017, at 12:04, Tristan Tarrant <[hidden email]> wrote:
>
> That is caused by not wrapping the calls in PrivilegedActions in all the
> correct places and is a bug.
>
> Tristan
>
> On 19/04/2017 11:34, Sebastian Laskawiec wrote:
>> The proposal look ok to me.
>>
>> But I would also like to highlight one thing - it seems you can't access
>> secured cache properties using CLI. This seems wrong to me (if you can
>> invoke the cli, in 99,99% of the cases you have access to the machine,
>> so you can do whatever you want). It also breaks healthchecks in Docker
>> image.
>>
>> I would like to make sure we will address those concerns.
>>
>> On Wed, Apr 19, 2017 at 10:59 AM Tristan Tarrant <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>    Currently the "protected cache access" security is implemented as
>>    follows:
>>
>>    - if authorization is enabled || client is on loopback
>>        allow
>>
>>    The first check also implies that authentication needs to be in place,
>>    as the authorization checks need a valid Subject.
>>
>>    Unfortunately authorization is very heavy-weight and actually overkill
>>    even for "normal" secure usage.
>>
>>    My proposal is as follows:
>>    - the "default" configuration files are "secure" by default
>>    - provide clearly marked "unsecured" configuration files, which the user
>>    can use
>>    - drop the "protected cache" check completely
>>
>>    And definitely NO to a dev switch.
>>
>>    Tristan
>>
>>    On 19/04/2017 10:05, Galder Zamarreño wrote:
>>> Agree with Wolf. Let's keep it simple by just providing extra
>>    configuration files for dev/unsecure envs.
>>>
>>> Cheers,
>>> --
>>> Galder Zamarreño
>>> Infinispan, Red Hat
>>>
>>>> On 15 Apr 2017, at 12:57, Wolf Fink <[hidden email]
>>    <mailto:[hidden email]>> wrote:
>>>>
>>>> I would think a "switch" can have other impacts as you need to
>>    check it in the code - and might have security leaks here
>>>>
>>>> So what is wrong with some configurations which are the default
>>    and secured.
>>>> and a "*-dev or *-unsecure" configuration to start easy.
>>>> Also this can be used in production if there is no need for security
>>>>
>>>> On Thu, Apr 13, 2017 at 4:13 PM, Sebastian Laskawiec
>>    <[hidden email] <mailto:[hidden email]>> wrote:
>>>> I still think it would be better to create an extra switch to
>>    run infinispan in "development mode". This means no authentication,
>>    no encryption, possibly with JGroups stack tuned for fast discovery
>>    (especially in Kubernetes) and a big warning saying "You are in
>>    development mode, do not use this in production".
>>>>
>>>> Just something very easy to get you going.
>>>>
>>>> On Thu, Apr 13, 2017 at 12:16 PM Galder Zamarreño
>>    <[hidden email] <mailto:[hidden email]>> wrote:
>>>>
>>>> --
>>>> Galder Zamarreño
>>>> Infinispan, Red Hat
>>>>
>>>>> On 13 Apr 2017, at 09:50, Gustavo Fernandes
>>    <[hidden email] <mailto:[hidden email]>> wrote:
>>>>>
>>>>> On Thu, Apr 13, 2017 at 6:38 AM, Galder Zamarreño
>>    <[hidden email] <mailto:[hidden email]>> wrote:
>>>>> Hi all,
>>>>>
>>>>> As per some discussions we had yesterday on IRC w/ Tristan,
>>    Gustavo and Sebastian, I've created a docker image snapshot that
>>    reverts the change stop protected caches from requiring security
>>    enabled [1].
>>>>>
>>>>> In other words, I've removed [2]. The reason for temporarily
>>    doing that is because with the change as is, the changes required
>>    for a default server distro require that the entire cache manager's
>>    security is enabled. This is in turn creates a lot of problems with
>>    health and running checks used by Kubernetes/OpenShift amongst other
>>    things.
>>>>>
>>>>> Judging from our discussions on IRC, the idea is for such
>>    change to be present in 9.0.1, but I'd like to get final
>>    confirmation from Tristan et al.
>>>>>
>>>>>
>>>>> +1
>>>>>
>>>>> Regarding the "security by default" discussion, I think we
>>    should ship configurations cloud.xml, clustered.xml and
>>    standalone.xml with security enabled and disabled variants, and let
>>    users
>>>>> decide which one to pick based on the use case.
>>>>
>>>> I think that's a better idea.
>>>>
>>>> We could by default have a secured one, but switching to an
>>    insecure configuration should be doable with minimal effort, e.g.
>>    just switching config file.
>>>>
>>>> As highlighted above, any secured configuration should work
>>    out-of-the-box with our docker images, e.g. WRT healthy/running checks.
>>>>
>>>> Cheers,
>>>>
>>>>>
>>>>> Gustavo.
>>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>> [1] https://hub.docker.com/r/galderz/infinispan-server/tags/
>>    (9.0.1-SNAPSHOT tag for anyone interested)
>>>>> [2]
>>    https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/main/java/org/infinispan/server/hotrod/CacheDecodeContext.java#L114-L118
>>>>> --
>>>>> Galder Zamarreño
>>>>> Infinispan, Red Hat
>>>>>
>>>>>> On 30 Mar 2017, at 14:25, Tristan Tarrant <[hidden email]
>>    <mailto:[hidden email]>> wrote:
>>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>> after a mini chat on IRC, I wanted to bring this to
>>    everybody's attention.
>>>>>>
>>>>>> We should make the Hot Rod endpoint require authentication in the
>>>>>> out-of-the-box configuration.
>>>>>> The proposal is to enable the PLAIN (or, preferably, DIGEST) SASL
>>>>>> mechanism against the ApplicationRealm and require users to
>>    run the
>>>>>> add-user script.
>>>>>> This would achieve two goals:
>>>>>> - secure out-of-the-box configuration, which is always a good idea
>>>>>> - access to the "protected" schema and script caches which is
>>    prevented
>>>>>> when not on loopback on non-authenticated endpoints.
>>>>>>
>>>>>> Tristan
>>>>>> --
>>>>>> Tristan Tarrant
>>>>>> Infinispan Lead
>>>>>> JBoss, a division of Red Hat
>>>>>> _______________________________________________
>>>>>> infinispan-dev mailing list
>>>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>> --
>>>> SEBASTIAN ŁASKAWIEC
>>>> INFINISPAN DEVELOPER
>>>> Red Hat EMEA
>>>>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>    <mailto:[hidden email]>
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>>    --
>>    Tristan Tarrant
>>    Infinispan Lead
>>    JBoss, a division of Red Hat
>>    _______________________________________________
>>    infinispan-dev mailing list
>>    [hidden email] <mailto:[hidden email]>
>>    https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>>
>> SEBASTIANŁASKAWIEC
>>
>> INFINISPAN DEVELOPER
>>
>> Red HatEMEA <https://www.redhat.com/>
>>
>> <https://red.ht/sig>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Hot Rod secured by default

Wolf Fink
We have that discussion several times and I remember it years ago.
What I've seen in onld EAP4 times is that user start a JBoss instance (which run with unsecure console by default) and secured everything they use, but forgot the console which they don't use.
Finally that ends in an open door to manipulate the server or shut it down, you were able to search for the JBoss console start page and you find a lot of server in production mode.
Because of this we should keep connections secured by default and find a balance to keep it easy to remove it.
An extra example marked as unsecured and a documentation what the default is and how to make it unsecure or more secure would be good.

Also default passwords are not good enough as everybody knows it and this is no security in my opinion (i.e. admin/admin ;) )

So a simple section in the "getting started" doc should make it clear and the user know that the security has been removed and the connections are public visible.

my 2ct

Wolf

On Wed, Sep 6, 2017 at 7:54 AM, Emmanuel Bernard <[hidden email]> wrote:
When you deploy a RDBMS on OpenShift, it is secured by default I think and it's not a big deal. It is possible to read back secrets in OpenShift in case you forgot them. 
Maybe there is a way to either document that better, maybe having the same password between console and cache by default is easier ?
We live in a world where we need to take security from day one. Remember OpenShift means you can start stuff super easily, some in the cloud, you don't want it open by default. 
But your input is super valuable, open a j'irai with that experience and let's try and make it easier. 

On 5 Sep 2017, at 18:03, Katia Aresti <[hidden email]> wrote:

Hi all,

I came up to this thread now, at the time I did not understand what we discussed here.

Let me tell you my experience of today.

I want to create a vert.x application, super simple, that connects to infinispan-server. Everything in open-shift.
I take an vert-x example as base, super simple one, that deploys directly a super simple web app with a simple command line. Works fine, I see the "hello world" webapp in my laptop on the openshift and my navigator.

I want this time to access to infinispan-server. I go into the interface, and I say "hey, grab the jboss/infinispan-server" image from docker registry. I try to go to the REST console, and oh, I need to authenticate. I go back, and then I read that I need to put 2 env variables. So there it is, now it works.
And then I want to go to the console, requires me to put again the user/password. And it does not work. And I don't see how to disable security. And I don't know what to do. And I'm like : why do I need security at all here ?
I'm a lambda dev, in a lambda project, considering using infinispan-server for the first time, and at this point, security of the cache I don't care and I don't know why I have to deal with it.

I know you acted a ticket and decided to have security on by default. IMHO lambda dev creating the hello world with the docker image provided by jboss... does not care about it. At all. He or she just wants to see everything working as soon as possible. Once they decide to use infinispan, if the cache needs to be secured, which seems to be recommended, they will go into that point (devs and ops) and change the code and the configuration to add the security level they need for their project.

I wonder if you want to reconsider the "secured by default" point after my experience. 

My 2 cents,

Katia

On Tue, May 9, 2017 at 2:24 PM, Galder Zamarreño <[hidden email]> wrote:
Hi all,

Tristan and I had chat yesterday and I've distilled the contents of the discussion and the feedback here into a JIRA [1]. The JIRA contains several subtasks to handle these aspects:

1. Remove auth check in server's CacheDecodeContext.
2. Default server configuration should require authentication in all entry points.
3. Provide an unauthenticated configuration that users can easily switch to.
4. Remove default username+passwords in docker image and instead show an info/warn message when these are not provided.
5. Add capability to pass in app user role groups to docker image easily, so that its easy to add authorization on top of the server.

Cheers,

[1] https://issues.jboss.org/browse/ISPN-7811
--
Galder Zamarreño
Infinispan, Red Hat

> On 19 Apr 2017, at 12:04, Tristan Tarrant <[hidden email]> wrote:
>
> That is caused by not wrapping the calls in PrivilegedActions in all the
> correct places and is a bug.
>
> Tristan
>
> On 19/04/2017 11:34, Sebastian Laskawiec wrote:
>> The proposal look ok to me.
>>
>> But I would also like to highlight one thing - it seems you can't access
>> secured cache properties using CLI. This seems wrong to me (if you can
>> invoke the cli, in 99,99% of the cases you have access to the machine,
>> so you can do whatever you want). It also breaks healthchecks in Docker
>> image.
>>
>> I would like to make sure we will address those concerns.
>>
>> On Wed, Apr 19, 2017 at 10:59 AM Tristan Tarrant <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>    Currently the "protected cache access" security is implemented as
>>    follows:
>>
>>    - if authorization is enabled || client is on loopback
>>        allow
>>
>>    The first check also implies that authentication needs to be in place,
>>    as the authorization checks need a valid Subject.
>>
>>    Unfortunately authorization is very heavy-weight and actually overkill
>>    even for "normal" secure usage.
>>
>>    My proposal is as follows:
>>    - the "default" configuration files are "secure" by default
>>    - provide clearly marked "unsecured" configuration files, which the user
>>    can use
>>    - drop the "protected cache" check completely
>>
>>    And definitely NO to a dev switch.
>>
>>    Tristan
>>
>>    On 19/04/2017 10:05, Galder Zamarreño wrote:
>>> Agree with Wolf. Let's keep it simple by just providing extra
>>    configuration files for dev/unsecure envs.
>>>
>>> Cheers,
>>> --
>>> Galder Zamarreño
>>> Infinispan, Red Hat
>>>
>>>> On 15 Apr 2017, at 12:57, Wolf Fink <[hidden email]
>>    <mailto:[hidden email]>> wrote:
>>>>
>>>> I would think a "switch" can have other impacts as you need to
>>    check it in the code - and might have security leaks here
>>>>
>>>> So what is wrong with some configurations which are the default
>>    and secured.
>>>> and a "*-dev or *-unsecure" configuration to start easy.
>>>> Also this can be used in production if there is no need for security
>>>>
>>>> On Thu, Apr 13, 2017 at 4:13 PM, Sebastian Laskawiec
>>    <[hidden email] <mailto:[hidden email]>> wrote:
>>>> I still think it would be better to create an extra switch to
>>    run infinispan in "development mode". This means no authentication,
>>    no encryption, possibly with JGroups stack tuned for fast discovery
>>    (especially in Kubernetes) and a big warning saying "You are in
>>    development mode, do not use this in production".
>>>>
>>>> Just something very easy to get you going.
>>>>
>>>> On Thu, Apr 13, 2017 at 12:16 PM Galder Zamarreño
>>    <[hidden email] <mailto:[hidden email]>> wrote:
>>>>
>>>> --
>>>> Galder Zamarreño
>>>> Infinispan, Red Hat
>>>>
>>>>> On 13 Apr 2017, at 09:50, Gustavo Fernandes
>>    <[hidden email] <mailto:[hidden email]>> wrote:
>>>>>
>>>>> On Thu, Apr 13, 2017 at 6:38 AM, Galder Zamarreño
>>    <[hidden email] <mailto:[hidden email]>> wrote:
>>>>> Hi all,
>>>>>
>>>>> As per some discussions we had yesterday on IRC w/ Tristan,
>>    Gustavo and Sebastian, I've created a docker image snapshot that
>>    reverts the change stop protected caches from requiring security
>>    enabled [1].
>>>>>
>>>>> In other words, I've removed [2]. The reason for temporarily
>>    doing that is because with the change as is, the changes required
>>    for a default server distro require that the entire cache manager's
>>    security is enabled. This is in turn creates a lot of problems with
>>    health and running checks used by Kubernetes/OpenShift amongst other
>>    things.
>>>>>
>>>>> Judging from our discussions on IRC, the idea is for such
>>    change to be present in 9.0.1, but I'd like to get final
>>    confirmation from Tristan et al.
>>>>>
>>>>>
>>>>> +1
>>>>>
>>>>> Regarding the "security by default" discussion, I think we
>>    should ship configurations cloud.xml, clustered.xml and
>>    standalone.xml with security enabled and disabled variants, and let
>>    users
>>>>> decide which one to pick based on the use case.
>>>>
>>>> I think that's a better idea.
>>>>
>>>> We could by default have a secured one, but switching to an
>>    insecure configuration should be doable with minimal effort, e.g.
>>    just switching config file.
>>>>
>>>> As highlighted above, any secured configuration should work
>>    out-of-the-box with our docker images, e.g. WRT healthy/running checks.
>>>>
>>>> Cheers,
>>>>
>>>>>
>>>>> Gustavo.
>>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>> [1] https://hub.docker.com/r/galderz/infinispan-server/tags/
>>    (9.0.1-SNAPSHOT tag for anyone interested)
>>>>> [2]
>>    https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/main/java/org/infinispan/server/hotrod/CacheDecodeContext.java#L114-L118
>>>>> --
>>>>> Galder Zamarreño
>>>>> Infinispan, Red Hat
>>>>>
>>>>>> On 30 Mar 2017, at 14:25, Tristan Tarrant <[hidden email]
>>    <mailto:[hidden email]>> wrote:
>>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>> after a mini chat on IRC, I wanted to bring this to
>>    everybody's attention.
>>>>>>
>>>>>> We should make the Hot Rod endpoint require authentication in the
>>>>>> out-of-the-box configuration.
>>>>>> The proposal is to enable the PLAIN (or, preferably, DIGEST) SASL
>>>>>> mechanism against the ApplicationRealm and require users to
>>    run the
>>>>>> add-user script.
>>>>>> This would achieve two goals:
>>>>>> - secure out-of-the-box configuration, which is always a good idea
>>>>>> - access to the "protected" schema and script caches which is
>>    prevented
>>>>>> when not on loopback on non-authenticated endpoints.
>>>>>>
>>>>>> Tristan
>>>>>> --
>>>>>> Tristan Tarrant
>>>>>> Infinispan Lead
>>>>>> JBoss, a division of Red Hat
>>>>>> _______________________________________________
>>>>>> infinispan-dev mailing list
>>>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>> --
>>>> SEBASTIAN ŁASKAWIEC
>>>> INFINISPAN DEVELOPER
>>>> Red Hat EMEA
>>>>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>    <mailto:[hidden email]>
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>>    --
>>    Tristan Tarrant
>>    Infinispan Lead
>>    JBoss, a division of Red Hat
>>    _______________________________________________
>>    infinispan-dev mailing list
>>    [hidden email] <mailto:[hidden email]>
>>    https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>>
>> SEBASTIANŁASKAWIEC
>>
>> INFINISPAN DEVELOPER
>>
>> Red HatEMEA <https://www.redhat.com/>
>>
>> <https://red.ht/sig>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Hot Rod secured by default

Gustavo Fernandes-2
In reply to this post by Katia Aresti
Comments inlined

On Tue, Sep 5, 2017 at 5:03 PM, Katia Aresti <[hidden email]> wrote:
And then I want to go to the console, requires me to put again the user/password. And it does not work. And I don't see how to disable security. And I don't know what to do. And I'm like : why do I need security at all here ?


The console credentials are specified with MGMT_USER/MGMT_PASS env variables, did you try those? It will not work for APP_USER/APP_PASS.

 
I wonder if you want to reconsider the "secured by default" point after my experience. 


The outcome of the discussion is that the clustered.xml will be secured by default, but you should be able to launch a container without any security by simply passing an alternate xml in the startup, and we'll ship this XML with the server. 


Gustavo
 

My 2 cents,

Katia

On Tue, May 9, 2017 at 2:24 PM, Galder Zamarreño <[hidden email]> wrote:
Hi all,

Tristan and I had chat yesterday and I've distilled the contents of the discussion and the feedback here into a JIRA [1]. The JIRA contains several subtasks to handle these aspects:

1. Remove auth check in server's CacheDecodeContext.
2. Default server configuration should require authentication in all entry points.
3. Provide an unauthenticated configuration that users can easily switch to.
4. Remove default username+passwords in docker image and instead show an info/warn message when these are not provided.
5. Add capability to pass in app user role groups to docker image easily, so that its easy to add authorization on top of the server.

Cheers,

[1] https://issues.jboss.org/browse/ISPN-7811
--
Galder Zamarreño
Infinispan, Red Hat

> On 19 Apr 2017, at 12:04, Tristan Tarrant <[hidden email]> wrote:
>
> That is caused by not wrapping the calls in PrivilegedActions in all the
> correct places and is a bug.
>
> Tristan
>
> On 19/04/2017 11:34, Sebastian Laskawiec wrote:
>> The proposal look ok to me.
>>
>> But I would also like to highlight one thing - it seems you can't access
>> secured cache properties using CLI. This seems wrong to me (if you can
>> invoke the cli, in 99,99% of the cases you have access to the machine,
>> so you can do whatever you want). It also breaks healthchecks in Docker
>> image.
>>
>> I would like to make sure we will address those concerns.
>>
>> On Wed, Apr 19, 2017 at 10:59 AM Tristan Tarrant <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>    Currently the "protected cache access" security is implemented as
>>    follows:
>>
>>    - if authorization is enabled || client is on loopback
>>        allow
>>
>>    The first check also implies that authentication needs to be in place,
>>    as the authorization checks need a valid Subject.
>>
>>    Unfortunately authorization is very heavy-weight and actually overkill
>>    even for "normal" secure usage.
>>
>>    My proposal is as follows:
>>    - the "default" configuration files are "secure" by default
>>    - provide clearly marked "unsecured" configuration files, which the user
>>    can use
>>    - drop the "protected cache" check completely
>>
>>    And definitely NO to a dev switch.
>>
>>    Tristan
>>
>>    On 19/04/2017 10:05, Galder Zamarreño wrote:
>>> Agree with Wolf. Let's keep it simple by just providing extra
>>    configuration files for dev/unsecure envs.
>>>
>>> Cheers,
>>> --
>>> Galder Zamarreño
>>> Infinispan, Red Hat
>>>
>>>> On 15 Apr 2017, at 12:57, Wolf Fink <[hidden email]
>>    <mailto:[hidden email]>> wrote:
>>>>
>>>> I would think a "switch" can have other impacts as you need to
>>    check it in the code - and might have security leaks here
>>>>
>>>> So what is wrong with some configurations which are the default
>>    and secured.
>>>> and a "*-dev or *-unsecure" configuration to start easy.
>>>> Also this can be used in production if there is no need for security
>>>>
>>>> On Thu, Apr 13, 2017 at 4:13 PM, Sebastian Laskawiec
>>    <[hidden email] <mailto:[hidden email]>> wrote:
>>>> I still think it would be better to create an extra switch to
>>    run infinispan in "development mode". This means no authentication,
>>    no encryption, possibly with JGroups stack tuned for fast discovery
>>    (especially in Kubernetes) and a big warning saying "You are in
>>    development mode, do not use this in production".
>>>>
>>>> Just something very easy to get you going.
>>>>
>>>> On Thu, Apr 13, 2017 at 12:16 PM Galder Zamarreño
>>    <[hidden email] <mailto:[hidden email]>> wrote:
>>>>
>>>> --
>>>> Galder Zamarreño
>>>> Infinispan, Red Hat
>>>>
>>>>> On 13 Apr 2017, at 09:50, Gustavo Fernandes
>>    <[hidden email] <mailto:[hidden email]>> wrote:
>>>>>
>>>>> On Thu, Apr 13, 2017 at 6:38 AM, Galder Zamarreño
>>    <[hidden email] <mailto:[hidden email]>> wrote:
>>>>> Hi all,
>>>>>
>>>>> As per some discussions we had yesterday on IRC w/ Tristan,
>>    Gustavo and Sebastian, I've created a docker image snapshot that
>>    reverts the change stop protected caches from requiring security
>>    enabled [1].
>>>>>
>>>>> In other words, I've removed [2]. The reason for temporarily
>>    doing that is because with the change as is, the changes required
>>    for a default server distro require that the entire cache manager's
>>    security is enabled. This is in turn creates a lot of problems with
>>    health and running checks used by Kubernetes/OpenShift amongst other
>>    things.
>>>>>
>>>>> Judging from our discussions on IRC, the idea is for such
>>    change to be present in 9.0.1, but I'd like to get final
>>    confirmation from Tristan et al.
>>>>>
>>>>>
>>>>> +1
>>>>>
>>>>> Regarding the "security by default" discussion, I think we
>>    should ship configurations cloud.xml, clustered.xml and
>>    standalone.xml with security enabled and disabled variants, and let
>>    users
>>>>> decide which one to pick based on the use case.
>>>>
>>>> I think that's a better idea.
>>>>
>>>> We could by default have a secured one, but switching to an
>>    insecure configuration should be doable with minimal effort, e.g.
>>    just switching config file.
>>>>
>>>> As highlighted above, any secured configuration should work
>>    out-of-the-box with our docker images, e.g. WRT healthy/running checks.
>>>>
>>>> Cheers,
>>>>
>>>>>
>>>>> Gustavo.
>>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>> [1] https://hub.docker.com/r/galderz/infinispan-server/tags/
>>    (9.0.1-SNAPSHOT tag for anyone interested)
>>>>> [2]
>>    https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/main/java/org/infinispan/server/hotrod/CacheDecodeContext.java#L114-L118
>>>>> --
>>>>> Galder Zamarreño
>>>>> Infinispan, Red Hat
>>>>>
>>>>>> On 30 Mar 2017, at 14:25, Tristan Tarrant <[hidden email]
>>    <mailto:[hidden email]>> wrote:
>>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>> after a mini chat on IRC, I wanted to bring this to
>>    everybody's attention.
>>>>>>
>>>>>> We should make the Hot Rod endpoint require authentication in the
>>>>>> out-of-the-box configuration.
>>>>>> The proposal is to enable the PLAIN (or, preferably, DIGEST) SASL
>>>>>> mechanism against the ApplicationRealm and require users to
>>    run the
>>>>>> add-user script.
>>>>>> This would achieve two goals:
>>>>>> - secure out-of-the-box configuration, which is always a good idea
>>>>>> - access to the "protected" schema and script caches which is
>>    prevented
>>>>>> when not on loopback on non-authenticated endpoints.
>>>>>>
>>>>>> Tristan
>>>>>> --
>>>>>> Tristan Tarrant
>>>>>> Infinispan Lead
>>>>>> JBoss, a division of Red Hat
>>>>>> _______________________________________________
>>>>>> infinispan-dev mailing list
>>>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>> --
>>>> SEBASTIAN ŁASKAWIEC
>>>> INFINISPAN DEVELOPER
>>>> Red Hat EMEA
>>>>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>    <mailto:[hidden email]>
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>>    --
>>    Tristan Tarrant
>>    Infinispan Lead
>>    JBoss, a division of Red Hat
>>    _______________________________________________
>>    infinispan-dev mailing list
>>    [hidden email] <mailto:[hidden email]>
>>    https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>>
>> SEBASTIANŁASKAWIEC
>>
>> INFINISPAN DEVELOPER
>>
>> Red HatEMEA <https://www.redhat.com/>
>>
>> <https://red.ht/sig>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Hot Rod secured by default

Katia Aresti
@Emmanuel, sure it't not a big deal, but starting fast and smooth without any trouble helps adoption. Concerning the ticket, there is already one that was acted. I can work on that, even if is assigned to Galder now. 

@Gustavo
Yes, as I read - better - now on the security part, it is said for the console that we need those. My head skipped that paragraph or I read that badly, and I was wondering if it was more something related to "roles" rather than a user. My bad, because I read too fast sometimes and skip things ! Maybe the paragraph of the security in the console should be moved down to the console part, which is small to read now ?  When I read there "see the security part bellow" I was like : ok, the security is done !! :) 

Thank you for your replies !

Katia


On Wed, Sep 6, 2017 at 10:52 AM, Gustavo Fernandes <[hidden email]> wrote:
Comments inlined

On Tue, Sep 5, 2017 at 5:03 PM, Katia Aresti <[hidden email]> wrote:
And then I want to go to the console, requires me to put again the user/password. And it does not work. And I don't see how to disable security. And I don't know what to do. And I'm like : why do I need security at all here ?


The console credentials are specified with MGMT_USER/MGMT_PASS env variables, did you try those? It will not work for APP_USER/APP_PASS.

 
I wonder if you want to reconsider the "secured by default" point after my experience. 


The outcome of the discussion is that the clustered.xml will be secured by default, but you should be able to launch a container without any security by simply passing an alternate xml in the startup, and we'll ship this XML with the server. 


Gustavo
 

My 2 cents,

Katia

On Tue, May 9, 2017 at 2:24 PM, Galder Zamarreño <[hidden email]> wrote:
Hi all,

Tristan and I had chat yesterday and I've distilled the contents of the discussion and the feedback here into a JIRA [1]. The JIRA contains several subtasks to handle these aspects:

1. Remove auth check in server's CacheDecodeContext.
2. Default server configuration should require authentication in all entry points.
3. Provide an unauthenticated configuration that users can easily switch to.
4. Remove default username+passwords in docker image and instead show an info/warn message when these are not provided.
5. Add capability to pass in app user role groups to docker image easily, so that its easy to add authorization on top of the server.

Cheers,

[1] https://issues.jboss.org/browse/ISPN-7811
--
Galder Zamarreño
Infinispan, Red Hat

> On 19 Apr 2017, at 12:04, Tristan Tarrant <[hidden email]> wrote:
>
> That is caused by not wrapping the calls in PrivilegedActions in all the
> correct places and is a bug.
>
> Tristan
>
> On 19/04/2017 11:34, Sebastian Laskawiec wrote:
>> The proposal look ok to me.
>>
>> But I would also like to highlight one thing - it seems you can't access
>> secured cache properties using CLI. This seems wrong to me (if you can
>> invoke the cli, in 99,99% of the cases you have access to the machine,
>> so you can do whatever you want). It also breaks healthchecks in Docker
>> image.
>>
>> I would like to make sure we will address those concerns.
>>
>> On Wed, Apr 19, 2017 at 10:59 AM Tristan Tarrant <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>    Currently the "protected cache access" security is implemented as
>>    follows:
>>
>>    - if authorization is enabled || client is on loopback
>>        allow
>>
>>    The first check also implies that authentication needs to be in place,
>>    as the authorization checks need a valid Subject.
>>
>>    Unfortunately authorization is very heavy-weight and actually overkill
>>    even for "normal" secure usage.
>>
>>    My proposal is as follows:
>>    - the "default" configuration files are "secure" by default
>>    - provide clearly marked "unsecured" configuration files, which the user
>>    can use
>>    - drop the "protected cache" check completely
>>
>>    And definitely NO to a dev switch.
>>
>>    Tristan
>>
>>    On 19/04/2017 10:05, Galder Zamarreño wrote:
>>> Agree with Wolf. Let's keep it simple by just providing extra
>>    configuration files for dev/unsecure envs.
>>>
>>> Cheers,
>>> --
>>> Galder Zamarreño
>>> Infinispan, Red Hat
>>>
>>>> On 15 Apr 2017, at 12:57, Wolf Fink <[hidden email]
>>    <mailto:[hidden email]>> wrote:
>>>>
>>>> I would think a "switch" can have other impacts as you need to
>>    check it in the code - and might have security leaks here
>>>>
>>>> So what is wrong with some configurations which are the default
>>    and secured.
>>>> and a "*-dev or *-unsecure" configuration to start easy.
>>>> Also this can be used in production if there is no need for security
>>>>
>>>> On Thu, Apr 13, 2017 at 4:13 PM, Sebastian Laskawiec
>>    <[hidden email] <mailto:[hidden email]>> wrote:
>>>> I still think it would be better to create an extra switch to
>>    run infinispan in "development mode". This means no authentication,
>>    no encryption, possibly with JGroups stack tuned for fast discovery
>>    (especially in Kubernetes) and a big warning saying "You are in
>>    development mode, do not use this in production".
>>>>
>>>> Just something very easy to get you going.
>>>>
>>>> On Thu, Apr 13, 2017 at 12:16 PM Galder Zamarreño
>>    <[hidden email] <mailto:[hidden email]>> wrote:
>>>>
>>>> --
>>>> Galder Zamarreño
>>>> Infinispan, Red Hat
>>>>
>>>>> On 13 Apr 2017, at 09:50, Gustavo Fernandes
>>    <[hidden email] <mailto:[hidden email]>> wrote:
>>>>>
>>>>> On Thu, Apr 13, 2017 at 6:38 AM, Galder Zamarreño
>>    <[hidden email] <mailto:[hidden email]>> wrote:
>>>>> Hi all,
>>>>>
>>>>> As per some discussions we had yesterday on IRC w/ Tristan,
>>    Gustavo and Sebastian, I've created a docker image snapshot that
>>    reverts the change stop protected caches from requiring security
>>    enabled [1].
>>>>>
>>>>> In other words, I've removed [2]. The reason for temporarily
>>    doing that is because with the change as is, the changes required
>>    for a default server distro require that the entire cache manager's
>>    security is enabled. This is in turn creates a lot of problems with
>>    health and running checks used by Kubernetes/OpenShift amongst other
>>    things.
>>>>>
>>>>> Judging from our discussions on IRC, the idea is for such
>>    change to be present in 9.0.1, but I'd like to get final
>>    confirmation from Tristan et al.
>>>>>
>>>>>
>>>>> +1
>>>>>
>>>>> Regarding the "security by default" discussion, I think we
>>    should ship configurations cloud.xml, clustered.xml and
>>    standalone.xml with security enabled and disabled variants, and let
>>    users
>>>>> decide which one to pick based on the use case.
>>>>
>>>> I think that's a better idea.
>>>>
>>>> We could by default have a secured one, but switching to an
>>    insecure configuration should be doable with minimal effort, e.g.
>>    just switching config file.
>>>>
>>>> As highlighted above, any secured configuration should work
>>    out-of-the-box with our docker images, e.g. WRT healthy/running checks.
>>>>
>>>> Cheers,
>>>>
>>>>>
>>>>> Gustavo.
>>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>> [1] https://hub.docker.com/r/galderz/infinispan-server/tags/
>>    (9.0.1-SNAPSHOT tag for anyone interested)
>>>>> [2]
>>    https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/main/java/org/infinispan/server/hotrod/CacheDecodeContext.java#L114-L118
>>>>> --
>>>>> Galder Zamarreño
>>>>> Infinispan, Red Hat
>>>>>
>>>>>> On 30 Mar 2017, at 14:25, Tristan Tarrant <[hidden email]
>>    <mailto:[hidden email]>> wrote:
>>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>> after a mini chat on IRC, I wanted to bring this to
>>    everybody's attention.
>>>>>>
>>>>>> We should make the Hot Rod endpoint require authentication in the
>>>>>> out-of-the-box configuration.
>>>>>> The proposal is to enable the PLAIN (or, preferably, DIGEST) SASL
>>>>>> mechanism against the ApplicationRealm and require users to
>>    run the
>>>>>> add-user script.
>>>>>> This would achieve two goals:
>>>>>> - secure out-of-the-box configuration, which is always a good idea
>>>>>> - access to the "protected" schema and script caches which is
>>    prevented
>>>>>> when not on loopback on non-authenticated endpoints.
>>>>>>
>>>>>> Tristan
>>>>>> --
>>>>>> Tristan Tarrant
>>>>>> Infinispan Lead
>>>>>> JBoss, a division of Red Hat
>>>>>> _______________________________________________
>>>>>> infinispan-dev mailing list
>>>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>> --
>>>> SEBASTIAN ŁASKAWIEC
>>>> INFINISPAN DEVELOPER
>>>> Red Hat EMEA
>>>>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>    <mailto:[hidden email]>
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>    <mailto:[hidden email]>
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>>    --
>>    Tristan Tarrant
>>    Infinispan Lead
>>    JBoss, a division of Red Hat
>>    _______________________________________________
>>    infinispan-dev mailing list
>>    [hidden email] <mailto:[hidden email]>
>>    https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>>
>> SEBASTIANŁASKAWIEC
>>
>> INFINISPAN DEVELOPER
>>
>> Red HatEMEA <https://www.redhat.com/>
>>
>> <https://red.ht/sig>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Hot Rod secured by default

Galder Zamarreno
Gustavo's reply was the agreement reached. Secured by default and an easy way to use it unsecured is the best middle ground IMO.

So, we've done the securing part partially, which needs to be completed by [2] (currently assigned to Tristan).

More importantly, we also need to complete [3] so that we have ship the unsecured configuration, and then show people how to use that (docus, examples...etc).

If you want to help, taking ownership of [3] would be best.

Cheers,

[2] https://issues.jboss.org/browse/ISPN-7815
[3] https://issues.jboss.org/browse/ISPN-7818

> On 6 Sep 2017, at 11:03, Katia Aresti <[hidden email]> wrote:
>
> @Emmanuel, sure it't not a big deal, but starting fast and smooth without any trouble helps adoption. Concerning the ticket, there is already one that was acted. I can work on that, even if is assigned to Galder now.
>
> @Gustavo
> Yes, as I read - better - now on the security part, it is said for the console that we need those. My head skipped that paragraph or I read that badly, and I was wondering if it was more something related to "roles" rather than a user. My bad, because I read too fast sometimes and skip things ! Maybe the paragraph of the security in the console should be moved down to the console part, which is small to read now ?  When I read there "see the security part bellow" I was like : ok, the security is done !! :)
>
> Thank you for your replies !
>
> Katia
>
>
> On Wed, Sep 6, 2017 at 10:52 AM, Gustavo Fernandes <[hidden email]> wrote:
> Comments inlined
>
> On Tue, Sep 5, 2017 at 5:03 PM, Katia Aresti <[hidden email]> wrote:
> And then I want to go to the console, requires me to put again the user/password. And it does not work. And I don't see how to disable security. And I don't know what to do. And I'm like : why do I need security at all here ?
>
>
> The console credentials are specified with MGMT_USER/MGMT_PASS env variables, did you try those? It will not work for APP_USER/APP_PASS.
>
>  
> I wonder if you want to reconsider the "secured by default" point after my experience.
>
>
> The outcome of the discussion is that the clustered.xml will be secured by default, but you should be able to launch a container without any security by simply passing an alternate xml in the startup, and we'll ship this XML with the server.
>
>
> Gustavo
>  
>
> My 2 cents,
>
> Katia
>
> On Tue, May 9, 2017 at 2:24 PM, Galder Zamarreño <[hidden email]> wrote:
> Hi all,
>
> Tristan and I had chat yesterday and I've distilled the contents of the discussion and the feedback here into a JIRA [1]. The JIRA contains several subtasks to handle these aspects:
>
> 1. Remove auth check in server's CacheDecodeContext.
> 2. Default server configuration should require authentication in all entry points.
> 3. Provide an unauthenticated configuration that users can easily switch to.
> 4. Remove default username+passwords in docker image and instead show an info/warn message when these are not provided.
> 5. Add capability to pass in app user role groups to docker image easily, so that its easy to add authorization on top of the server.
>
> Cheers,
>
> [1] https://issues.jboss.org/browse/ISPN-7811
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
> > On 19 Apr 2017, at 12:04, Tristan Tarrant <[hidden email]> wrote:
> >
> > That is caused by not wrapping the calls in PrivilegedActions in all the
> > correct places and is a bug.
> >
> > Tristan
> >
> > On 19/04/2017 11:34, Sebastian Laskawiec wrote:
> >> The proposal look ok to me.
> >>
> >> But I would also like to highlight one thing - it seems you can't access
> >> secured cache properties using CLI. This seems wrong to me (if you can
> >> invoke the cli, in 99,99% of the cases you have access to the machine,
> >> so you can do whatever you want). It also breaks healthchecks in Docker
> >> image.
> >>
> >> I would like to make sure we will address those concerns.
> >>
> >> On Wed, Apr 19, 2017 at 10:59 AM Tristan Tarrant <[hidden email]
> >> <mailto:[hidden email]>> wrote:
> >>
> >>    Currently the "protected cache access" security is implemented as
> >>    follows:
> >>
> >>    - if authorization is enabled || client is on loopback
> >>        allow
> >>
> >>    The first check also implies that authentication needs to be in place,
> >>    as the authorization checks need a valid Subject.
> >>
> >>    Unfortunately authorization is very heavy-weight and actually overkill
> >>    even for "normal" secure usage.
> >>
> >>    My proposal is as follows:
> >>    - the "default" configuration files are "secure" by default
> >>    - provide clearly marked "unsecured" configuration files, which the user
> >>    can use
> >>    - drop the "protected cache" check completely
> >>
> >>    And definitely NO to a dev switch.
> >>
> >>    Tristan
> >>
> >>    On 19/04/2017 10:05, Galder Zamarreño wrote:
> >>> Agree with Wolf. Let's keep it simple by just providing extra
> >>    configuration files for dev/unsecure envs.
> >>>
> >>> Cheers,
> >>> --
> >>> Galder Zamarreño
> >>> Infinispan, Red Hat
> >>>
> >>>> On 15 Apr 2017, at 12:57, Wolf Fink <[hidden email]
> >>    <mailto:[hidden email]>> wrote:
> >>>>
> >>>> I would think a "switch" can have other impacts as you need to
> >>    check it in the code - and might have security leaks here
> >>>>
> >>>> So what is wrong with some configurations which are the default
> >>    and secured.
> >>>> and a "*-dev or *-unsecure" configuration to start easy.
> >>>> Also this can be used in production if there is no need for security
> >>>>
> >>>> On Thu, Apr 13, 2017 at 4:13 PM, Sebastian Laskawiec
> >>    <[hidden email] <mailto:[hidden email]>> wrote:
> >>>> I still think it would be better to create an extra switch to
> >>    run infinispan in "development mode". This means no authentication,
> >>    no encryption, possibly with JGroups stack tuned for fast discovery
> >>    (especially in Kubernetes) and a big warning saying "You are in
> >>    development mode, do not use this in production".
> >>>>
> >>>> Just something very easy to get you going.
> >>>>
> >>>> On Thu, Apr 13, 2017 at 12:16 PM Galder Zamarreño
> >>    <[hidden email] <mailto:[hidden email]>> wrote:
> >>>>
> >>>> --
> >>>> Galder Zamarreño
> >>>> Infinispan, Red Hat
> >>>>
> >>>>> On 13 Apr 2017, at 09:50, Gustavo Fernandes
> >>    <[hidden email] <mailto:[hidden email]>> wrote:
> >>>>>
> >>>>> On Thu, Apr 13, 2017 at 6:38 AM, Galder Zamarreño
> >>    <[hidden email] <mailto:[hidden email]>> wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> As per some discussions we had yesterday on IRC w/ Tristan,
> >>    Gustavo and Sebastian, I've created a docker image snapshot that
> >>    reverts the change stop protected caches from requiring security
> >>    enabled [1].
> >>>>>
> >>>>> In other words, I've removed [2]. The reason for temporarily
> >>    doing that is because with the change as is, the changes required
> >>    for a default server distro require that the entire cache manager's
> >>    security is enabled. This is in turn creates a lot of problems with
> >>    health and running checks used by Kubernetes/OpenShift amongst other
> >>    things.
> >>>>>
> >>>>> Judging from our discussions on IRC, the idea is for such
> >>    change to be present in 9.0.1, but I'd like to get final
> >>    confirmation from Tristan et al.
> >>>>>
> >>>>>
> >>>>> +1
> >>>>>
> >>>>> Regarding the "security by default" discussion, I think we
> >>    should ship configurations cloud.xml, clustered.xml and
> >>    standalone.xml with security enabled and disabled variants, and let
> >>    users
> >>>>> decide which one to pick based on the use case.
> >>>>
> >>>> I think that's a better idea.
> >>>>
> >>>> We could by default have a secured one, but switching to an
> >>    insecure configuration should be doable with minimal effort, e.g.
> >>    just switching config file.
> >>>>
> >>>> As highlighted above, any secured configuration should work
> >>    out-of-the-box with our docker images, e.g. WRT healthy/running checks.
> >>>>
> >>>> Cheers,
> >>>>
> >>>>>
> >>>>> Gustavo.
> >>>>>
> >>>>>
> >>>>> Cheers,
> >>>>>
> >>>>> [1] https://hub.docker.com/r/galderz/infinispan-server/tags/
> >>    (9.0.1-SNAPSHOT tag for anyone interested)
> >>>>> [2]
> >>    https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/main/java/org/infinispan/server/hotrod/CacheDecodeContext.java#L114-L118
> >>>>> --
> >>>>> Galder Zamarreño
> >>>>> Infinispan, Red Hat
> >>>>>
> >>>>>> On 30 Mar 2017, at 14:25, Tristan Tarrant <[hidden email]
> >>    <mailto:[hidden email]>> wrote:
> >>>>>>
> >>>>>> Dear all,
> >>>>>>
> >>>>>> after a mini chat on IRC, I wanted to bring this to
> >>    everybody's attention.
> >>>>>>
> >>>>>> We should make the Hot Rod endpoint require authentication in the
> >>>>>> out-of-the-box configuration.
> >>>>>> The proposal is to enable the PLAIN (or, preferably, DIGEST) SASL
> >>>>>> mechanism against the ApplicationRealm and require users to
> >>    run the
> >>>>>> add-user script.
> >>>>>> This would achieve two goals:
> >>>>>> - secure out-of-the-box configuration, which is always a good idea
> >>>>>> - access to the "protected" schema and script caches which is
> >>    prevented
> >>>>>> when not on loopback on non-authenticated endpoints.
> >>>>>>
> >>>>>> Tristan
> >>>>>> --
> >>>>>> Tristan Tarrant
> >>>>>> Infinispan Lead
> >>>>>> JBoss, a division of Red Hat
> >>>>>> _______________________________________________
> >>>>>> infinispan-dev mailing list
> >>>>>> [hidden email]
> >>    <mailto:[hidden email]>
> >>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> infinispan-dev mailing list
> >>>>> [hidden email]
> >>    <mailto:[hidden email]>
> >>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>>>>
> >>>>> _______________________________________________
> >>>>> infinispan-dev mailing list
> >>>>> [hidden email]
> >>    <mailto:[hidden email]>
> >>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> infinispan-dev mailing list
> >>>> [hidden email]
> >>    <mailto:[hidden email]>
> >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>>> --
> >>>> SEBASTIAN ŁASKAWIEC
> >>>> INFINISPAN DEVELOPER
> >>>> Red Hat EMEA
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> infinispan-dev mailing list
> >>>> [hidden email]
> >>    <mailto:[hidden email]>
> >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>>>
> >>>> _______________________________________________
> >>>> infinispan-dev mailing list
> >>>> [hidden email]
> >>    <mailto:[hidden email]>
> >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>>
> >>>
> >>> _______________________________________________
> >>> infinispan-dev mailing list
> >>> [hidden email]
> >>    <mailto:[hidden email]>
> >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>>
> >>
> >>    --
> >>    Tristan Tarrant
> >>    Infinispan Lead
> >>    JBoss, a division of Red Hat
> >>    _______________________________________________
> >>    infinispan-dev mailing list
> >>    [hidden email] <mailto:[hidden email]>
> >>    https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>
> >> --
> >>
> >> SEBASTIANŁASKAWIEC
> >>
> >> INFINISPAN DEVELOPER
> >>
> >> Red HatEMEA <https://www.redhat.com/>
> >>
> >> <https://red.ht/sig>
> >>
> >>
> >>
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> [hidden email]
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>
> >
> > --
> > Tristan Tarrant
> > Infinispan Lead
> > JBoss, a division of Red Hat
> > _______________________________________________
> > infinispan-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Infinispan, Red Hat


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
12