+1 On Monday, September 12, 2016, John Blum <jb...@pivotal.io> wrote:
> +1 > > On Mon, Sep 12, 2016 at 11:31 AM, Udo Kohlmeyer <ukohlme...@pivotal.io > <javascript:;>> > 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 > <javascript:;>> 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 > <javascript:;>> > >>> 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 > <javascript:;>> > >>>> > >>> 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 > <javascript:;>> 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 > <javascript:;>> > >>>>>> > >>>>> 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 > <javascript:;>> > >>>>>>> > >>>>>> 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 > <javascript:;>> 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 <javascript:;>> > >>>> > >>>>> 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) >
