@Emmanuel, sure it't not a big deal, but starting fast and smooth without any trouble helps adoption. Concerning the ticket, there is already one that was acted. I can work on that, even if is assigned to Galder now.
@Gustavo Yes, as I read - better - now on the security part, it is said for the console that we need those. My head skipped that paragraph or I read that badly, and I was wondering if it was more something related to "roles" rather than a user. My bad, because I read too fast sometimes and skip things ! Maybe the paragraph of the security in the console should be moved down to the console part, which is small to read now ? When I read there "see the security part bellow" I was like : ok, the security is done !! :) Thank you for your replies ! Katia On Wed, Sep 6, 2017 at 10:52 AM, Gustavo Fernandes <gust...@infinispan.org> wrote: > 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 >
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev