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 <https://www.redhat.com/> > <https://red.ht/sig> > > _______________________________________________ > 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
