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
