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 >>
signature.asc
Description: Message signed with OpenPGP using GPGMail
