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 <wf...@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 <slask...@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 <gal...@redhat.com> wrote: > > -- > Galder Zamarreño > Infinispan, Red Hat > > > On 13 Apr 2017, at 09:50, Gustavo Fernandes <gust...@infinispan.org> wrote: > > > > On Thu, Apr 13, 2017 at 6:38 AM, Galder Zamarreño <gal...@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 <ttarr...@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@lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > -- > SEBASTIAN ŁASKAWIEC > INFINISPAN DEVELOPER > Red Hat EMEA > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
