@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 <gustavo(a)infinispan.org>
wrote:
Comments inlined
On Tue, Sep 5, 2017 at 5:03 PM, Katia Aresti <karesti(a)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 <galder(a)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 <ttarrant(a)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
<ttarrant(a)redhat.com
>> >> <mailto:ttarrant@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 <wfink(a)redhat.com
>> >> <mailto:wfink@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 <mailto:slaskawi@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 <mailto:galder@redhat.com>> wrote:
>> >>>>
>> >>>> --
>> >>>> Galder Zamarreño
>> >>>> Infinispan, Red Hat
>> >>>>
>> >>>>> On 13 Apr 2017, at 09:50, Gustavo Fernandes
>> >> <gustavo(a)infinispan.org <mailto:gustavo@infinispan.org>>
wrote:
>> >>>>>
>> >>>>> On Thu, Apr 13, 2017 at 6:38 AM, Galder Zamarreño
>> >> <galder(a)redhat.com <mailto:galder@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
<ttarrant(a)redhat.com
>> >> <mailto:ttarrant@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
>> >> <mailto:infinispan-dev@lists.jboss.org>
>> >>>>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> >>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> infinispan-dev mailing list
>> >>>>> infinispan-dev(a)lists.jboss.org
>> >> <mailto:infinispan-dev@lists.jboss.org>
>> >>>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> infinispan-dev mailing list
>> >>>>> infinispan-dev(a)lists.jboss.org
>> >> <mailto:infinispan-dev@lists.jboss.org>
>> >>>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> infinispan-dev mailing list
>> >>>> infinispan-dev(a)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(a)lists.jboss.org
>> >> <mailto:infinispan-dev@lists.jboss.org>
>> >>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> >>>>
>> >>>> _______________________________________________
>> >>>> infinispan-dev mailing list
>> >>>> infinispan-dev(a)lists.jboss.org
>> >> <mailto:infinispan-dev@lists.jboss.org>
>> >>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> infinispan-dev mailing list
>> >>> infinispan-dev(a)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(a)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(a)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(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