Quantcast

[infinispan-dev] Hot Rod secured by default

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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

Galder Zamarreño
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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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

Galder Zamarreño
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
|  
Report Content as Inappropriate

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
12
Loading...