[infinispan-dev] Hot Rod secured by default
Tristan Tarrant
ttarrant at redhat.com
Mon Feb 5 06:02:40 EST 2018
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
More information about the infinispan-dev
mailing list