[infinispan-dev] Hot Rod secured by default

Katia Aresti karesti at redhat.com
Wed Sep 6 05:03:55 EDT 2017 

@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 <gustavo at infinispan.org>
wrote:

> Comments inlined
>
> On Tue, Sep 5, 2017 at 5:03 PM, Katia Aresti <karesti at redhat.com> 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 <galder at redhat.com>
>> 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 <ttarrant at redhat.com> 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 <ttarrant at redhat.com
>>> >> <mailto:ttarrant at redhat.com>> 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 <wfink at redhat.com
>>> >>    <mailto:wfink at redhat.com>> 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
>>> >>    <slaskawi at redhat.com <mailto:slaskawi at redhat.com>> 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
>>> >>    <galder at redhat.com <mailto:galder at redhat.com>> wrote:
>>> >>>>
>>> >>>> --
>>> >>>> Galder Zamarreño
>>> >>>> Infinispan, Red Hat
>>> >>>>
>>> >>>>> On 13 Apr 2017, at 09:50, Gustavo Fernandes
>>> >>    <gustavo at infinispan.org <mailto:gustavo at infinispan.org>> wrote:
>>> >>>>>
>>> >>>>> On Thu, Apr 13, 2017 at 6:38 AM, Galder Zamarreño
>>> >>    <galder at redhat.com <mailto:galder at redhat.com>> 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/CacheDecod
>>> eContext.java#L114-L118
>>> >>>>> --
>>> >>>>> Galder Zamarreño
>>> >>>>> Infinispan, Red Hat
>>> >>>>>
>>> >>>>>> On 30 Mar 2017, at 14:25, Tristan Tarrant <ttarrant at redhat.com
>>> >>    <mailto:ttarrant at redhat.com>> 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
>>> >>>>>> infinispan-dev at lists.jboss.org
>>> >>    <mailto:infinispan-dev at lists.jboss.org>
>>> >>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> >>>>>
>>> >>>>>
>>> >>>>> _______________________________________________
>>> >>>>> infinispan-dev mailing list
>>> >>>>> infinispan-dev at lists.jboss.org
>>> >>    <mailto:infinispan-dev at lists.jboss.org>
>>> >>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> >>>>>
>>> >>>>> _______________________________________________
>>> >>>>> infinispan-dev mailing list
>>> >>>>> infinispan-dev at lists.jboss.org
>>> >>    <mailto:infinispan-dev at lists.jboss.org>
>>> >>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> >>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> infinispan-dev mailing list
>>> >>>> infinispan-dev at lists.jboss.org
>>> >>    <mailto:infinispan-dev at lists.jboss.org>
>>> >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> >>>> --
>>> >>>> SEBASTIAN ŁASKAWIEC
>>> >>>> INFINISPAN DEVELOPER
>>> >>>> Red Hat EMEA
>>> >>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> infinispan-dev mailing list
>>> >>>> infinispan-dev at lists.jboss.org
>>> >>    <mailto:infinispan-dev at lists.jboss.org>
>>> >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> infinispan-dev mailing list
>>> >>>> infinispan-dev at lists.jboss.org
>>> >>    <mailto:infinispan-dev at lists.jboss.org>
>>> >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> infinispan-dev mailing list
>>> >>> infinispan-dev at lists.jboss.org
>>> >>    <mailto:infinispan-dev at lists.jboss.org>
>>> >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> >>>
>>> >>
>>> >>    --
>>> >>    Tristan Tarrant
>>> >>    Infinispan Lead
>>> >>    JBoss, a division of Red Hat
>>> >>    _______________________________________________
>>> >>    infinispan-dev mailing list
>>> >>    infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.j
>>> boss.org>
>>> >>    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
>>> >> infinispan-dev at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> >>
>>> >
>>> > --
>>> > Tristan Tarrant
>>> > Infinispan Lead
>>> > JBoss, a division of Red Hat
>>> > _______________________________________________
>>> > infinispan-dev mailing list
>>> > infinispan-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170906/91f038ab/attachment-0001.html

More information about the infinispan-dev mailing list