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(a)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(a)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(a)redhat.com> wrote:
--
Galder Zamarreño
Infinispan, Red Hat
> On 13 Apr 2017, at 09:50, Gustavo Fernandes <gustavo(a)infinispan.org> wrote:
>
> On Thu, Apr 13, 2017 at 6:38 AM, Galder Zamarreño <galder(a)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/ma...
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
> > On 30 Mar 2017, at 14:25, Tristan Tarrant <ttarrant(a)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(a)lists.jboss.org
> >
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
SEBASTIAN ŁASKAWIEC
INFINISPAN DEVELOPER
Red Hat EMEA
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev