Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> Config in ZooKeeperInstance


Copy link to this message
-
Re: Config in ZooKeeperInstance
I'm not sure I see much point implementing server-side features to
support a "use SSL, if available" client mode. Such a feature is
effectively no more secure than the basic "insecure" mode, and as
such, I think is a waste of resources to implement (and, more
importantly, to maintain). Besides, clients can implement a "use SSL,
if available" feature (if they really must) without the server side
revealing any information about how it is configured (your suggested
"try, then fallback on failure" would work, and it wouldn't be too
bad, if you did it once per "Instance"
(org.apache.accumulo.core.client.Instance).

The "connection string" for Accumulo *is* client configuration, so
that seems the most sensible route to me.
For example, one of:

// one of these could respect the JSSE javax.net.ssl system properties
ZooKeeperInstance(instanceName, zookeepers,
secureMode).getConnector(user, token);
SecureZooKeeperInstance(instanceName, zookeepers).getConnector(user, token);
Instance(instanceName, zookeepers).getSslConnector(user, token);

On the other hand, if you mean per-tserver connection strings
(locations in metadata or server advertisements/locks in ZK), I'd
steer clear, because you really need such a setting consistent for
everything related to an entire o.a.a.core.client.Instance. If even
one tserver is insecure and operating within the cluster, and the
client is configured to fallback to insecure mode on a per-connection
basis, then the whole system is insecure.

You could implement a ZK flag that reports which mode (set by the
Master) the entire instance is running in, but I think this should be
used only as a fast-failure when constructing a secure client
connector. Otherwise, if the client is going to change its operation
mode based on this flag, you're going to have to set up an additional
layer of trust with ZK before you can trust that it's safe to respect
this flag in the first place (because the flag has the possibility of
forcing an insecure mode).

Setting up that trust seems complicated and unnecessary to me (I
really don't like the idea of an insecure fallback mode), but it might
be worth it for other reasons anyway. I'm not sure what options are
available to lock down ZK more. Perhaps an additional shared secret
for clients (again, distributed as client configuration)? or
client-certificate authentication for the read-only client areas of
ZK?

I suggest:

Have the master set a flag in ZK in an area that the client can read,
to inform the client which mode the server is operating in, for
fast-failure only (to enable client logic to fall back, if desired).
Provide an Instance that will use SSL mode for all its RPC calls, and
will fail if the server's flag doesn't match the specified mode.
Make clients configurable, to use either the secure Instance or the
insecure Instance (do this entirely in client code).
Do additional research on securing/trusting ZK itself.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Wed, Jul 31, 2013 at 11:52 AM, Michael Berman <[EMAIL PROTECTED]> wrote:
> Oh, I absolutely agree we can't trust remote config to tell us where to
> find the trusted root...that needs to be consciously configured for every
> client.  I was thinking more along the lines of your "http can
> automatically redirect to https" example.  If I have an accumulo cluster up
> and running, and I want to switch to SSL, it would be nice to be able to
> flip the switch on the server, distribute my root cert, and then have all
> the existing client apps able to figure out that they should make SSL
> connections to accumulo automatically based on some cue from ZK.  If it's
> really entirely up to the client to decide, probably that switch would
> require a recompile of my client apps to add the "use SSL" flag.  I
> wouldn't want that flag to be in a conf file (although I think that's a
> great place for the path to the root cert), because on any given machine I
> may want to connect to both SSL and non-SSL accumulos...it seems like a