+1 On Mon, Sep 12, 2016 at 11:31 AM, Udo Kohlmeyer <ukohlme...@pivotal.io> wrote:
> So it seems that we are all in agreement. > > The communication channel security (via SSL) is to be separated from the > RBAC. > > I suggest the enum that deals with the securing of the communication > channels is renamed to: SecurableCommunicationChannels. This internal > enum will not be shared with RBAC anymore nor exposed as a public API. > > In addition to this http will be renamed to web, which is non-protocol > specific. > > --Udo > > > > On 10/09/2016 3:17 AM, Michael Stolz wrote: > >> Cool! I agree with this completely. Wasn't clear to me in the earlier >> thread that we were keeping the thoughts separate. >> >> -- >> Mike Stolz >> Principal Engineer, GemFire Product Manager >> Mobile: 631-835-4771 >> >> On Fri, Sep 9, 2016 at 1:06 PM, John Blum <jb...@pivotal.io> wrote: >> >> I agree with Udo here. Securing the channel between component/services >>> has >>> really very little to do with Authentication/Authorization, and by >>> "Authentication", I mean in the user-centric sense, not the SSL "trusted" >>> sense (with "trusted" keys and such). >>> >>> Whether a user can or cannot do something (in other words, is >>> "authorized", >>> or allowed to invoke an action, given an ACL) is a function of the action >>> being performed and the privileges/rights that a user has been granted. >>> That is independent of whether or not the channel has been secured. >>> >>> I also agree with Kirk that HTTP should perhaps be renamed to WEB. >>> >>> Finally, while SSL is usually a cause to reboot the system, Auth has no >>> such restrictions. I could easily change Auth credentials of a user >>> (e.g. >>> revoke privileges) at runtime. >>> >>> My $0.02, >>> -John >>> >>> >>> On Fri, Sep 9, 2016 at 10:00 AM, Michael Stolz <mst...@pivotal.io> >>> wrote: >>> >>> In a pure world I would go for all or nothing, but I always worry about >>>> >>> the >>> >>>> upgrade path. If I have to redeploy and restart EVERYTHING around the >>>> >>> whole >>> >>>> world simultaneously, it's a non-starter. >>>> >>>> -- >>>> Mike Stolz >>>> Principal Engineer, GemFire Product Manager >>>> Mobile: 631-835-4771 >>>> >>>> On Fri, Sep 9, 2016 at 12:51 PM, Anthony Baker <aba...@pivotal.io> >>>> >>> wrote: >>> >>>> Mike, I was suggesting ON | OFF only for RBAC security, not for SSL >>>>> configuration. Any thoughts on that? >>>>> >>>>> Anthony >>>>> >>>>> On Sep 9, 2016, at 9:44 AM, Michael Stolz <mst...@pivotal.io> wrote: >>>>>> >>>>>> I think a reason that we might need to be less than all-or-nothing is >>>>>> >>>>> for >>>> >>>>> at least these two situations: >>>>>> >>>>>> 1. a user who started out with SSL disabled, and now wants to enable >>>>>> >>>>> it, >>>> >>>>> but can't take a full global outage, so needs to get it enabled for >>>>>> >>>>> the >>> >>>> WAN >>>>> >>>>>> first, and then for server-to-server and then for client/server. >>>>>> >>>>>> 2. SSL enabled over the WAN because that is not a trusted network, >>>>>> >>>>> but >>> >>>> they >>>>> >>>>>> can live without SSL for the server/server and client/server >>>>>> >>>>> connections >>>> >>>>> because they ARE in a trusted network and they don't need to pay the >>>>>> overhead for SSL on those links. >>>>>> >>>>>> There are probably other scenarios as well, but these are the two >>>>>> >>>>> that >>> >>>> come >>>>> >>>>>> to mind quickly. >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Mike Stolz >>>>>> Principal Engineer, GemFire Product Manager >>>>>> Mobile: 631-835-4771 >>>>>> >>>>>> On Fri, Sep 9, 2016 at 12:05 PM, Jinmei Liao <jil...@pivotal.io> >>>>>> >>>>> wrote: >>>> >>>>> That is my original thought as well. If we are protecting resources >>>>>>> (CLUSTER and DATA), it should be protected no matter which way user >>>>>>> >>>>>> is >>> >>>> trying to access it. I guess I'll leave this to the PMs to decide. >>>>>>> >>>>>>> On Thu, Sep 8, 2016 at 7:37 PM, Anthony Baker <aba...@pivotal.io> >>>>>>> >>>>>> wrote: >>>>> >>>>>> Udo, Kirk - this makes sense and thanks for the discussion to help >>>>>>>> >>>>>>> clarify >>>>>>> >>>>>>>> the issue. >>>>>>>> >>>>>>>> Regarding GEODE-1648, does it make sense to do at all? That is, >>>>>>>> >>>>>>> what >>> >>>> if >>>>> >>>>>> role-based access control is either ON | OFF instead of per >>>>>>>> >>>>>>> component. >>>> >>>>> If >>>>>>> >>>>>>>> we allow disabling RBAC for certain components, wouldn’t that make >>>>>>>> >>>>>>> it >>> >>>> possible to create a backdoor? Could we start with a binary option >>>>>>>> >>>>>>> and >>>> >>>>> enable more granular control when requested by users? >>>>>>>> >>>>>>>> Anthony >>>>>>>> >>>>>>>> On Sep 8, 2016, at 4:11 PM, Kirk Lund <kl...@pivotal.io> wrote: >>>>>>>>> >>>>>>>>> +1 overall with some feedback... >>>>>>>>> >>>>>>>>> 1) I think the list is reasonable with a few nitpicks below >>>>>>>>> >>>>>>>>> 2) If these are Channels and not Components, then I would probably >>>>>>>>> >>>>>>>> name >>>>> >>>>>> it >>>>>>>> >>>>>>>>> SecurableChannels or SecurableCommunicationChannels or whatever. >>>>>>>>> >>>>>>>>> 3) I'd prefer HTTP be renamed to Web or other non-protocol word -- >>>>>>>>> >>>>>>>> HTTP >>>>> >>>>>> is >>>>>>>> >>>>>>>>> a protocol and the names of the other channels are conceptual >>>>>>>>> >>>>>>>> channels >>>> >>>>> rather than a protocol (the others use TCP/IP or RMI but we don't >>>>>>>>> >>>>>>>> label >>>>> >>>>>> them as such). Or am I missing something here? >>>>>>>>> >>>>>>>>> 4) JMX is probably ok. Currently we are using (and securing) JMX >>>>>>>>> >>>>>>>> over >>>> >>>>> RMI >>>>>>> >>>>>>>> (javax.management.remote.rmi.RMIConnectorServer). There are other >>>>>>>>> connectors for JMX including HTTP (ex: mx4j.tools.adaptor.http. >>>>>>>>> >>>>>>>> HttpAdaptor) >>>>>>>> >>>>>>>>> and SNMP (ex: com.sun.jmx.snmp.daemon.SnmpAdaptorServer). We only >>>>>>>>> >>>>>>>> need >>>>> >>>>>> JMX >>>>>>>> >>>>>>>>> over RMI for now, but would we add those others as new enums to >>>>>>>>> SecurableChannels later if we add anything like that to Geode? Or >>>>>>>>> >>>>>>>> would >>>>> >>>>>> we >>>>>>>> >>>>>>>>> try to group those all together under the name JMX? Or decide when >>>>>>>>> >>>>>>>> the >>>> >>>>> time >>>>>>>> >>>>>>>>> comes? >>>>>>>>> >>>>>>>>> I think we should try to steer away from being overly controlled >>>>>>>>> >>>>>>>> by >>> >>>> specs >>>>>>> >>>>>>>> especially for reasonable changes. We all follow agile process, >>>>>>>>> >>>>>>>> so a >>> >>>> decision made one iteration could easily be undone or changed in >>>>>>>>> >>>>>>>> the >>> >>>> next >>>>>>> >>>>>>>> iteration and most of us are following weekly iterations. >>>>>>>>> >>>>>>>>> After a release anything exposed in a User API is very difficult >>>>>>>>> >>>>>>>> to >>> >>>> change >>>>>>>> >>>>>>>>> due to backwards compatibility constraints. I think we should be >>>>>>>>> >>>>>>>> much >>>> >>>>> more >>>>>>>> >>>>>>>>> careful with User APIs in Geode going forward to avoid some of the >>>>>>>>> >>>>>>>> problems >>>>>>>> >>>>>>>>> we have with pre-existing Geode User APIs that we inherited. >>>>>>>>> >>>>>>>>> -Kirk >>>>>>>>> >>>>>>>>> On Thu, Sep 8, 2016 at 2:07 PM, Udo Kohlmeyer < >>>>>>>>> >>>>>>>> ukohlme...@pivotal.io> >>>> >>>>> wrote: >>>>>>>> >>>>>>>>> As GEODE-420 deals with SSL comms configuration and GEODE-1648 >>>>>>>>>> >>>>>>>>> with >>> >>>> Authentication&Authorization I think we need to be careful in >>>>>>>>>> >>>>>>>>> what >>> >>>> is >>>> >>>>> feasible and what is logical. >>>>>>>>>> >>>>>>>>>> For SSL comms it was decided that the following components are >>>>>>>>>> >>>>>>>>> relevant >>>>>>> >>>>>>>> [1] <https://cwiki.apache.org/confluence/display/GEODE/Revised+S >>>>>>>>>> SL+properties>: >>>>>>>>>> >>>>>>>>>> * Locator => The comms channel between Locators + the initial >>>>>>>>>> >>>>>>>>> comms >>> >>>> channel between clients and locator >>>>>>>>>> * Cluster => Internode comms channel (peer to peer) >>>>>>>>>> * Server => Client-server comms channel >>>>>>>>>> * Gateway => Comms channel between WAN Gateway senders/receivers >>>>>>>>>> * HTTP => Any HTTP comms. incl REST and Pulse >>>>>>>>>> * JMX => Any JMX comms >>>>>>>>>> >>>>>>>>>> These components were selected as they seem to be logical >>>>>>>>>> >>>>>>>>> boundaries >>>> >>>>> and >>>>>>> >>>>>>>> communication interfaces. >>>>>>>>>> >>>>>>>>>> I think the specialization of HTTP, for >>>>>>>>>> >>>>>>>>> Authentication&Authorization >>>> >>>>> are >>>>>>> >>>>>>>> functions of those interfaces: >>>>>>>>>> >>>>>>>>>> * REST-admin >>>>>>>>>> * REST-dev >>>>>>>>>> * Pulse >>>>>>>>>> >>>>>>>>>> I think that comms and functions exposed by those comms should >>>>>>>>>> >>>>>>>>> not >>> >>>> be >>>> >>>>> mixed. I think that securing the comms channel is a factor of >>>>>>>>>> >>>>>>>>> "trust". >>>>> >>>>>> Do I >>>>>>>> >>>>>>>>> implicitly trust the interface/system that I am connected to or >>>>>>>>>> >>>>>>>>> are >>> >>>> connecting to. >>>>>>>>>> >>>>>>>>>> I think concepts like "management" is a concept in function. Do I >>>>>>>>>> >>>>>>>>> allow >>>>>>> >>>>>>>> a >>>>>>>> >>>>>>>>> user to access admin API's? The function of management should not >>>>>>>>>> >>>>>>>>> determine >>>>>>>> >>>>>>>>> if a system trusts another systems connection. When a new comms >>>>>>>>>> >>>>>>>>> interface >>>>>>>> >>>>>>>>> is added (say messaging), we want to be able to trust that comms >>>>>>>>>> >>>>>>>>> channel. >>>>>>>> >>>>>>>>> The "management" function should still work regardless of >>>>>>>>>> >>>>>>>>> interface, >>>> >>>>> be >>>>>>> >>>>>>>> it >>>>>>>> >>>>>>>>> jmx,http/rest,prop tcp,messaging. >>>>>>>>>> >>>>>>>>>> --Udo >>>>>>>>>> >>>>>>>>>> [1]: https://cwiki.apache.org/confluence/display/GEODE/ >>>>>>>>>> >>>>>>>>> Revised+SS >>> >>>> L+properties >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 9/09/2016 5:49 AM, Swapnil Bawaskar wrote: >>>>>>>>>> >>>>>>>>>> GEODE-1648 and GEODE-420 are both trying to add geode properties >>>>>>>>>>> >>>>>>>>>> to >>>> >>>>> secure >>>>>>>> >>>>>>>>> only some components. >>>>>>>>>>> GEODE-1648 is intending to add a property named >>>>>>>>>>> "security-enabled-components" that will allow users to turn off >>>>>>>>>>> authentication/authorization for some components >>>>>>>>>>> GEODE-420 is intending to add a property named >>>>>>>>>>> >>>>>>>>>> "ssl-enabled-components" >>>>>>> >>>>>>>> that will allow users to turn off ssl. for either client/server, >>>>>>>>>>> peer-to-peer or wan communication. >>>>>>>>>>> >>>>>>>>>>> Since both deal with security, I think we should have the same >>>>>>>>>>> >>>>>>>>>> list >>>> >>>>> of >>>>>>> >>>>>>>> components for these new geode properties. Intent of this thread >>>>>>>>>>> >>>>>>>>>> is >>>> >>>>> to >>>>>>> >>>>>>>> arrive at a consensus on what these components are. >>>>>>>>>>> >>>>>>>>>>> I would like to propose the following components: >>>>>>>>>>> Cluster => stands for peer-to-peer >>>>>>>>>>> Server => client/server and developer rest API >>>>>>>>>>> WAN => gateway sender/receiver >>>>>>>>>>> Management => jmx, admin-rest, pulse >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> Swapnil. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> Cheers >>>>>>> >>>>>>> Jinmei >>>>>>> >>>>>>> >>>>> >>> >>> -- >>> -John >>> 503-504-8657 >>> john.blum10101 (skype) >>> >>> > -- -John 503-504-8657 john.blum10101 (skype)
