+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)
> >
>

Reply via email to