Re: securing geode components

2016-09-12 Thread Swapnil Bawaskar
+1 On Mon, Sep 12, 2016 at 11:43 AM, Kirk Lund wrote: > +1 > > On Monday, September 12, 2016, John Blum wrote: > > > +1 > > > > On Mon, Sep 12, 2016 at 11:31 AM, Udo Kohlmeyer > > > > wrote: > > > > > So it seems

Re: securing geode components

2016-09-09 Thread John Blum
I agree with Udo here. Securing the channel between component/services has really very little to do with Authentication/Authorization, and by "Authentication", I mean in the user-centric sense, not the SSL "trusted" sense (with "trusted" keys and such). Whether a user can or cannot do something

Re: securing geode components

2016-09-09 Thread Anthony Baker
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 wrote: > > I think a reason that we might need to be less than all-or-nothing is for > at least these two

Re: securing geode components

2016-09-09 Thread Jinmei Liao
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 wrote: > Udo, Kirk -

Re: securing geode components

2016-09-08 Thread Kirk Lund
+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

Re: securing geode components

2016-09-08 Thread Udo Kohlmeyer
As GEODE-420 deals with SSL comms configuration and GEODE-1648 with Authentication 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]