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

Reply via email to