[infinispan-dev] Hot Rod secured by default

Emmanuel Bernard emmanuel at hibernate.org
Wed Sep 6 01:54:37 EDT 2017 

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 <karesti at redhat.com> 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 <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/CacheDecodeContext.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.jboss.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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170906/f70806c2/attachment-0001.html

More information about the infinispan-dev mailing list