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