[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 <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>
> wrote:
>
>>
>> --
>> Galder Zamarreño
>> Infinispan, Red Hat
>>
>> > On 13 Apr 2017, at 09:50, Gustavo Fernandes <gustavo at infinispan.org>
>> wrote:
>> >
>> > On Thu, Apr 13, 2017 at 6:38 AM, Galder Zamarreño <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>
>> 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
>> > > 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
>
> --
>
> SEBASTIAN ŁASKAWIEC
>
> INFINISPAN DEVELOPER
>
> Red Hat EMEA <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170415/24aed177/attachment-0001.html