Comments inlined On Tue, Sep 5, 2017 at 5:03 PM, Katia Aresti <kare...@redhat.com> wrote: > > 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 ? >
The console credentials are specified with MGMT_USER/MGMT_PASS env variables, did you try those? It will not work for APP_USER/APP_PASS. > I wonder if you want to reconsider the "secured by default" point after my > experience. > The outcome of the discussion is that the clustered.xml will be secured by default, but you should be able to launch a container without any security by simply passing an alternate xml in the startup, and we'll ship this XML with the server. Gustavo > > My 2 cents, > > Katia > > On Tue, May 9, 2017 at 2:24 PM, Galder Zamarreño <gal...@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 <ttarr...@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 <ttarr...@redhat.com >> >> <mailto:ttarr...@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 <wf...@redhat.com >> >> <mailto: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 <mailto: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 <mailto:gal...@redhat.com>> wrote: >> >>>> >> >>>> -- >> >>>> Galder Zamarreño >> >>>> Infinispan, Red Hat >> >>>> >> >>>>> On 13 Apr 2017, at 09:50, Gustavo Fernandes >> >> <gust...@infinispan.org <mailto:gust...@infinispan.org>> wrote: >> >>>>> >> >>>>> On Thu, Apr 13, 2017 at 6:38 AM, Galder Zamarreño >> >> <gal...@redhat.com <mailto: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/CacheDecod >> eContext.java#L114-L118 >> >>>>> -- >> >>>>> Galder Zamarreño >> >>>>> Infinispan, Red Hat >> >>>>> >> >>>>>> On 30 Mar 2017, at 14:25, Tristan Tarrant <ttarr...@redhat.com >> >> <mailto: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 >> >> <mailto:infinispan-dev@lists.jboss.org> >> >>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >>>>> >> >>>>> >> >>>>> _______________________________________________ >> >>>>> infinispan-dev mailing list >> >>>>> infinispan-dev@lists.jboss.org >> >> <mailto:infinispan-dev@lists.jboss.org> >> >>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >>>>> >> >>>>> _______________________________________________ >> >>>>> infinispan-dev mailing list >> >>>>> infinispan-dev@lists.jboss.org >> >> <mailto:infinispan-dev@lists.jboss.org> >> >>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> infinispan-dev mailing list >> >>>> infinispan-dev@lists.jboss.org >> >> <mailto: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 >> >> <mailto:infinispan-dev@lists.jboss.org> >> >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >>>> >> >>>> _______________________________________________ >> >>>> infinispan-dev mailing list >> >>>> infinispan-dev@lists.jboss.org >> >> <mailto:infinispan-dev@lists.jboss.org> >> >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >>> >> >>> >> >>> _______________________________________________ >> >>> infinispan-dev mailing list >> >>> infinispan-dev@lists.jboss.org >> >> <mailto:infinispan-dev@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@lists.jboss.org <mailto:infinispan-dev@lists.j >> boss.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@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@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
