[infinispan-dev] Hot Rod secured by default

Sanne Grinovero sanne at infinispan.org
Mon Feb 5 06:15:18 EST 2018 

+1

To improve convenience, would be nice to also have some examples to
configure credentials in some automated fashion; e.g. CLI scripts and
an example of running them for a Maven integration test?

Thanks,
Sanne


On 5 February 2018 at 11:02, Tristan Tarrant <ttarrant at redhat.com> wrote:
> Sorry for reviving this thread, but I want to make sure we all agree on
> the following points.
>
> DEFAULT CONFIGURATIONS
> - The endpoints MUST be secure by default (authentication MUST be
> enabled and required) in all of the supplied default configurations.
> - We can ship non-secure configurations, but these need to be clearly
> marked as such in the configuration filename (e.g.
> standalone-unsecured.xml).
> - Memcached MUST NOT be enabled by default as we do not implement the
> binary protocol which is the only one that can do authn/encryption
> - The default configurations (standalone.xml, domain.xml, cloud.xml)
> MUST enable only non-plaintext mechs (e.g. digest et al)
>
> SERVER CHANGES
> - Warn if a plain text mech is enabled on an unencrypted endpoint
>
> API
> - We MUST NOT add a "trust all certs" switch to the client config as
> that would thwart the whole purpose of encryption.
>
> OPENSHIFT
> - In the context of OpenShift, all pods MUST trust the master CA. This
> means that the CA must be injected into the trusted CAs for the pods AND
> into the JDK cacerts file. This MUST be done by the OpenShift JDK image
> automatically. (Debian does this on startup: [1])
>
> Tristan
>
> [1]
> https://git.mikael.io/mikaelhg/ca-certificates-java/blob/debian/20170531/src/main/java/org/debian/security/UpdateCertificates.java
>
> On 9/14/17 5:45 PM, Galder Zamarreño wrote:
>> Gustavo's reply was the agreement reached. Secured by default and an easy way to use it unsecured is the best middle ground IMO.
>>
>> So, we've done the securing part partially, which needs to be completed by [2] (currently assigned to Tristan).
>>
>> More importantly, we also need to complete [3] so that we have ship the unsecured configuration, and then show people how to use that (docus, examples...etc).
>>
>> If you want to help, taking ownership of [3] would be best.
>>
>> Cheers,
>>
>> [2] https://issues.jboss.org/browse/ISPN-7815
>> [3] https://issues.jboss.org/browse/ISPN-7818
>>
>>> On 6 Sep 2017, at 11:03, Katia Aresti <karesti at redhat.com> wrote:
>>>
>>> @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 at infinispan.org> wrote:
>>> Comments inlined
>>>
>>> On Tue, Sep 5, 2017 at 5:03 PM, Katia Aresti <karesti at 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 at 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 at 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 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
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>> Galder Zamarreño
>> Infinispan, Red Hat
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> --
> Tristan Tarrant
> Infinispan Lead and Data Grid Chief Architect
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

More information about the infinispan-dev mailing list