[infinispan-dev] Hot Rod secured by default
Tristan Tarrant
ttarrant at redhat.com
Wed Apr 19 06:04:34 EDT 2017
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 at redhat.com
> <mailto:ttarrant at 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 at redhat.com
> <mailto:wfink at 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 at redhat.com <mailto:slaskawi at 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 at redhat.com <mailto:galder at redhat.com>> wrote:
> >>
> >> --
> >> Galder Zamarreño
> >> Infinispan, Red Hat
> >>
> >>> On 13 Apr 2017, at 09:50, Gustavo Fernandes
> <gustavo at infinispan.org <mailto:gustavo at infinispan.org>> wrote:
> >>>
> >>> On Thu, Apr 13, 2017 at 6:38 AM, Galder Zamarreño
> <galder at redhat.com <mailto:galder at 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 <ttarrant at redhat.com
> <mailto:ttarrant at 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 at lists.jboss.org
> <mailto:infinispan-dev at lists.jboss.org>
> >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>>
> >>>
> >>> _______________________________________________
> >>> infinispan-dev mailing list
> >>> infinispan-dev at lists.jboss.org
> <mailto:infinispan-dev at lists.jboss.org>
> >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>>
> >>> _______________________________________________
> >>> infinispan-dev mailing list
> >>> infinispan-dev at lists.jboss.org
> <mailto:infinispan-dev at lists.jboss.org>
> >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>
> >>
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev at lists.jboss.org
> <mailto:infinispan-dev at lists.jboss.org>
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >> --
> >> SEBASTIAN ŁASKAWIEC
> >> INFINISPAN DEVELOPER
> >> Red Hat EMEA
> >>
> >>
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev at lists.jboss.org
> <mailto:infinispan-dev at lists.jboss.org>
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev at lists.jboss.org
> <mailto:infinispan-dev at lists.jboss.org>
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> <mailto:infinispan-dev at 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 at lists.jboss.org <mailto:infinispan-dev at lists.jboss.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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
More information about the infinispan-dev
mailing list