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 >
