<div dir="ltr"><div>@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. </div><div><br></div><div>@Gustavo<br></div><div>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 !! :) </div><div><br></div><div>Thank you for your replies !</div><div><br></div><div>Katia</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 6, 2017 at 10:52 AM, Gustavo Fernandes <span dir="ltr"><<a href="mailto:gustavo@infinispan.org" target="_blank">gustavo@infinispan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Comments inlined<br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Tue, Sep 5, 2017 at 5:03 PM, Katia Aresti <span dir="ltr"><<a href="mailto:karesti@redhat.com" target="_blank">karesti@redhat.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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 ?</div></div></blockquote><div><br></div><div><br></div></span><div>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.</div><span class=""><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I wonder if you want to reconsider the "secured by default" point after my experience. </div></div></blockquote><div><br></div><div><br></div></span><div>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. </div><span class="HOEnZb"><font color="#888888"><div><br></div><div><br></div><div>Gustavo</div></font></span><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>My 2 cents,</div><div><br></div><div>Katia</div></div><div class="m_5026721265893419612HOEnZb"><div class="m_5026721265893419612h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 9, 2017 at 2:24 PM, Galder Zamarreño <span dir="ltr"><<a href="mailto:galder@redhat.com" target="_blank">galder@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
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:<br>
<br>
1. Remove auth check in server's CacheDecodeContext.<br>
2. Default server configuration should require authentication in all entry points.<br>
3. Provide an unauthenticated configuration that users can easily switch to.<br>
4. Remove default username+passwords in docker image and instead show an info/warn message when these are not provided.<br>
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.<br>
<br>
Cheers,<br>
<br>
[1] <a href="https://issues.jboss.org/browse/ISPN-7811" rel="noreferrer" target="_blank">https://issues.jboss.org/brows<wbr>e/ISPN-7811</a><br>
<span class="m_5026721265893419612m_-3729651859084924635im m_5026721265893419612m_-3729651859084924635HOEnZb">--<br>
Galder Zamarreño<br>
Infinispan, Red Hat<br>
<br>
</span><div class="m_5026721265893419612m_-3729651859084924635HOEnZb"><div class="m_5026721265893419612m_-3729651859084924635h5">> On 19 Apr 2017, at 12:04, Tristan Tarrant <<a href="mailto:ttarrant@redhat.com" target="_blank">ttarrant@redhat.com</a>> wrote:<br>
><br>
> That is caused by not wrapping the calls in PrivilegedActions in all the<br>
> correct places and is a bug.<br>
><br>
> Tristan<br>
><br>
> On 19/04/2017 11:34, Sebastian Laskawiec wrote:<br>
>> The proposal look ok to me.<br>
>><br>
>> But I would also like to highlight one thing - it seems you can't access<br>
>> secured cache properties using CLI. This seems wrong to me (if you can<br>
>> invoke the cli, in 99,99% of the cases you have access to the machine,<br>
>> so you can do whatever you want). It also breaks healthchecks in Docker<br>
>> image.<br>
>><br>
>> I would like to make sure we will address those concerns.<br>
>><br>
>> On Wed, Apr 19, 2017 at 10:59 AM Tristan Tarrant <<a href="mailto:ttarrant@redhat.com" target="_blank">ttarrant@redhat.com</a><br>
>> <mailto:<a href="mailto:ttarrant@redhat.com" target="_blank">ttarrant@redhat.com</a>>> wrote:<br>
>><br>
>> Currently the "protected cache access" security is implemented as<br>
>> follows:<br>
>><br>
>> - if authorization is enabled || client is on loopback<br>
>> allow<br>
>><br>
>> The first check also implies that authentication needs to be in place,<br>
>> as the authorization checks need a valid Subject.<br>
>><br>
>> Unfortunately authorization is very heavy-weight and actually overkill<br>
>> even for "normal" secure usage.<br>
>><br>
>> My proposal is as follows:<br>
>> - the "default" configuration files are "secure" by default<br>
>> - provide clearly marked "unsecured" configuration files, which the user<br>
>> can use<br>
>> - drop the "protected cache" check completely<br>
>><br>
>> And definitely NO to a dev switch.<br>
>><br>
>> Tristan<br>
>><br>
>> On 19/04/2017 10:05, Galder Zamarreño wrote:<br>
>>> Agree with Wolf. Let's keep it simple by just providing extra<br>
>> configuration files for dev/unsecure envs.<br>
>>><br>
>>> Cheers,<br>
>>> --<br>
>>> Galder Zamarreño<br>
>>> Infinispan, Red Hat<br>
>>><br>
>>>> On 15 Apr 2017, at 12:57, Wolf Fink <<a href="mailto:wfink@redhat.com" target="_blank">wfink@redhat.com</a><br>
>> <mailto:<a href="mailto:wfink@redhat.com" target="_blank">wfink@redhat.com</a>>> wrote:<br>
>>>><br>
>>>> I would think a "switch" can have other impacts as you need to<br>
>> check it in the code - and might have security leaks here<br>
>>>><br>
>>>> So what is wrong with some configurations which are the default<br>
>> and secured.<br>
>>>> and a "*-dev or *-unsecure" configuration to start easy.<br>
>>>> Also this can be used in production if there is no need for security<br>
>>>><br>
>>>> On Thu, Apr 13, 2017 at 4:13 PM, Sebastian Laskawiec<br>
>> <<a href="mailto:slaskawi@redhat.com" target="_blank">slaskawi@redhat.com</a> <mailto:<a href="mailto:slaskawi@redhat.com" target="_blank">slaskawi@redhat.com</a>>> wrote:<br>
>>>> I still think it would be better to create an extra switch to<br>
>> run infinispan in "development mode". This means no authentication,<br>
>> no encryption, possibly with JGroups stack tuned for fast discovery<br>
>> (especially in Kubernetes) and a big warning saying "You are in<br>
>> development mode, do not use this in production".<br>
>>>><br>
>>>> Just something very easy to get you going.<br>
>>>><br>
>>>> On Thu, Apr 13, 2017 at 12:16 PM Galder Zamarreño<br>
>> <<a href="mailto:galder@redhat.com" target="_blank">galder@redhat.com</a> <mailto:<a href="mailto:galder@redhat.com" target="_blank">galder@redhat.com</a>>> wrote:<br>
>>>><br>
>>>> --<br>
>>>> Galder Zamarreño<br>
>>>> Infinispan, Red Hat<br>
>>>><br>
>>>>> On 13 Apr 2017, at 09:50, Gustavo Fernandes<br>
>> <<a href="mailto:gustavo@infinispan.org" target="_blank">gustavo@infinispan.org</a> <mailto:<a href="mailto:gustavo@infinispan.org" target="_blank">gustavo@infinispan.org</a><wbr>>> wrote:<br>
>>>>><br>
>>>>> On Thu, Apr 13, 2017 at 6:38 AM, Galder Zamarreño<br>
>> <<a href="mailto:galder@redhat.com" target="_blank">galder@redhat.com</a> <mailto:<a href="mailto:galder@redhat.com" target="_blank">galder@redhat.com</a>>> wrote:<br>
>>>>> Hi all,<br>
>>>>><br>
>>>>> As per some discussions we had yesterday on IRC w/ Tristan,<br>
>> Gustavo and Sebastian, I've created a docker image snapshot that<br>
>> reverts the change stop protected caches from requiring security<br>
>> enabled [1].<br>
>>>>><br>
>>>>> In other words, I've removed [2]. The reason for temporarily<br>
>> doing that is because with the change as is, the changes required<br>
>> for a default server distro require that the entire cache manager's<br>
>> security is enabled. This is in turn creates a lot of problems with<br>
>> health and running checks used by Kubernetes/OpenShift amongst other<br>
>> things.<br>
>>>>><br>
>>>>> Judging from our discussions on IRC, the idea is for such<br>
>> change to be present in 9.0.1, but I'd like to get final<br>
>> confirmation from Tristan et al.<br>
>>>>><br>
>>>>><br>
>>>>> +1<br>
>>>>><br>
>>>>> Regarding the "security by default" discussion, I think we<br>
>> should ship configurations cloud.xml, clustered.xml and<br>
>> standalone.xml with security enabled and disabled variants, and let<br>
>> users<br>
>>>>> decide which one to pick based on the use case.<br>
>>>><br>
>>>> I think that's a better idea.<br>
>>>><br>
>>>> We could by default have a secured one, but switching to an<br>
>> insecure configuration should be doable with minimal effort, e.g.<br>
>> just switching config file.<br>
>>>><br>
>>>> As highlighted above, any secured configuration should work<br>
>> out-of-the-box with our docker images, e.g. WRT healthy/running checks.<br>
>>>><br>
>>>> Cheers,<br>
>>>><br>
>>>>><br>
>>>>> Gustavo.<br>
>>>>><br>
>>>>><br>
>>>>> Cheers,<br>
>>>>><br>
>>>>> [1] <a href="https://hub.docker.com/r/galderz/infinispan-server/tags/" rel="noreferrer" target="_blank">https://hub.docker.com/r/galde<wbr>rz/infinispan-server/tags/</a><br>
>> (9.0.1-SNAPSHOT tag for anyone interested)<br>
>>>>> [2]<br>
>> <a href="https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/main/java/org/infinispan/server/hotrod/CacheDecodeContext.java#L114-L118" rel="noreferrer" target="_blank">https://github.com/infinispan/<wbr>infinispan/blob/master/server/<wbr>hotrod/src/main/java/org/infin<wbr>ispan/server/hotrod/CacheDecod<wbr>eContext.java#L114-L118</a><br>
>>>>> --<br>
>>>>> Galder Zamarreño<br>
>>>>> Infinispan, Red Hat<br>
>>>>><br>
>>>>>> On 30 Mar 2017, at 14:25, Tristan Tarrant <<a href="mailto:ttarrant@redhat.com" target="_blank">ttarrant@redhat.com</a><br>
>> <mailto:<a href="mailto:ttarrant@redhat.com" target="_blank">ttarrant@redhat.com</a>>> wrote:<br>
>>>>>><br>
>>>>>> Dear all,<br>
>>>>>><br>
>>>>>> after a mini chat on IRC, I wanted to bring this to<br>
>> everybody's attention.<br>
>>>>>><br>
>>>>>> We should make the Hot Rod endpoint require authentication in the<br>
>>>>>> out-of-the-box configuration.<br>
>>>>>> The proposal is to enable the PLAIN (or, preferably, DIGEST) SASL<br>
>>>>>> mechanism against the ApplicationRealm and require users to<br>
>> run the<br>
>>>>>> add-user script.<br>
>>>>>> This would achieve two goals:<br>
>>>>>> - secure out-of-the-box configuration, which is always a good idea<br>
>>>>>> - access to the "protected" schema and script caches which is<br>
>> prevented<br>
>>>>>> when not on loopback on non-authenticated endpoints.<br>
>>>>>><br>
>>>>>> Tristan<br>
>>>>>> --<br>
>>>>>> Tristan Tarrant<br>
>>>>>> Infinispan Lead<br>
>>>>>> JBoss, a division of Red Hat<br>
>>>>>> ______________________________<wbr>_________________<br>
>>>>>> infinispan-dev mailing list<br>
>>>>>> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
>> <mailto:<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.j<wbr>boss.org</a>><br>
>>>>>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/infinispan-dev</a><br>
>>>>><br>
>>>>><br>
>>>>> ______________________________<wbr>_________________<br>
>>>>> infinispan-dev mailing list<br>
>>>>> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
>> <mailto:<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.j<wbr>boss.org</a>><br>
>>>>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/infinispan-dev</a><br>
>>>>><br>
>>>>> ______________________________<wbr>_________________<br>
>>>>> infinispan-dev mailing list<br>
>>>>> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
>> <mailto:<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.j<wbr>boss.org</a>><br>
>>>>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/infinispan-dev</a><br>
>>>><br>
>>>><br>
>>>> ______________________________<wbr>_________________<br>
>>>> infinispan-dev mailing list<br>
>>>> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
>> <mailto:<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.j<wbr>boss.org</a>><br>
>>>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/infinispan-dev</a><br>
>>>> --<br>
>>>> SEBASTIAN ŁASKAWIEC<br>
>>>> INFINISPAN DEVELOPER<br>
>>>> Red Hat EMEA<br>
>>>><br>
>>>><br>
>>>> ______________________________<wbr>_________________<br>
>>>> infinispan-dev mailing list<br>
>>>> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
>> <mailto:<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.j<wbr>boss.org</a>><br>
>>>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/infinispan-dev</a><br>
>>>><br>
>>>> ______________________________<wbr>_________________<br>
>>>> infinispan-dev mailing list<br>
>>>> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
>> <mailto:<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.j<wbr>boss.org</a>><br>
>>>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/infinispan-dev</a><br>
>>><br>
>>><br>
>>> ______________________________<wbr>_________________<br>
>>> infinispan-dev mailing list<br>
>>> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
>> <mailto:<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.j<wbr>boss.org</a>><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/infinispan-dev</a><br>
>>><br>
>><br>
>> --<br>
>> Tristan Tarrant<br>
>> Infinispan Lead<br>
>> JBoss, a division of Red Hat<br>
>> ______________________________<wbr>_________________<br>
>> infinispan-dev mailing list<br>
>> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a> <mailto:<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.j<wbr>boss.org</a>><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/infinispan-dev</a><br>
>><br>
>> --<br>
>><br>
>> SEBASTIANŁASKAWIEC<br>
>><br>
>> INFINISPAN DEVELOPER<br>
>><br>
>> Red HatEMEA <<a href="https://www.redhat.com/" rel="noreferrer" target="_blank">https://www.redhat.com/</a>><br>
>><br>
>> <<a href="https://red.ht/sig" rel="noreferrer" target="_blank">https://red.ht/sig</a>><br>
>><br>
>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> infinispan-dev mailing list<br>
>> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/infinispan-dev</a><br>
>><br>
><br>
> --<br>
> Tristan Tarrant<br>
> Infinispan Lead<br>
> JBoss, a division of Red Hat<br>
> ______________________________<wbr>_________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/infinispan-dev</a><br>
<br>
<br>
______________________________<wbr>_________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/infinispan-dev</a></div></div></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/infinispan-dev</a><br></blockquote></div></div></div><br></div></div>
<br>______________________________<wbr>_________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/infinispan-<wbr>dev</a><br></blockquote></div><br></div>