+1 On Mon, Sep 12, 2016 at 11:43 AM, Kirk Lund <kirk.l...@gmail.com> wrote:
> +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) > > >
