So it seems that we are all in agreement.
The communication channel security (via SSL) is to be separated from the
RBAC.
I suggest the enum that deals with the securing of the communication
channels is renamed to: SecurableCommunicationChannels. This internal
enum will not be shared with RBAC anymore nor exposed as a public API.
In addition to this http will be renamed to web, which is non-protocol
specific.
--Udo
On 10/09/2016 3:17 AM, Michael Stolz wrote:
Cool! I agree with this completely. Wasn't clear to me in the earlier
thread that we were keeping the thoughts separate.
--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: 631-835-4771
On Fri, Sep 9, 2016 at 1:06 PM, John Blum <jb...@pivotal.io> wrote:
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 (in other words, is "authorized",
or allowed to invoke an action, given an ACL) is a function of the action
being performed and the privileges/rights that a user has been granted.
That is independent of whether or not the channel has been secured.
I also agree with Kirk that HTTP should perhaps be renamed to WEB.
Finally, while SSL is usually a cause to reboot the system, Auth has no
such restrictions. I could easily change Auth credentials of a user (e.g.
revoke privileges) at runtime.
My $0.02,
-John
On Fri, Sep 9, 2016 at 10:00 AM, Michael Stolz <mst...@pivotal.io> wrote:
In a pure world I would go for all or nothing, but I always worry about
the
upgrade path. If I have to redeploy and restart EVERYTHING around the
whole
world simultaneously, it's a non-starter.
--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: 631-835-4771
On Fri, Sep 9, 2016 at 12:51 PM, Anthony Baker <aba...@pivotal.io>
wrote:
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
--
-John
503-504-8657
john.blum10101 (skype)
