accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Berman (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-1009) Support encryption over the wire
Date Tue, 17 Sep 2013 22:25:53 GMT


Michael Berman commented on ACCUMULO-1009:

Also, if say "client.ssl.enabled = true", and those JSSE properties prefixed with "client."
are absent, a fallback to the unprefixed ones read out of the configuration file or the system
properties might be prudent. So, when "client.ssl.enabled" is set to "true", the relevant
properties can be configured with the "client." prefix or without, and those without are treated
as a global fallback. I don't think they should be mix-and-matched, though (prefixed and non-prefixed),
so if any have the prefix for that scope, no unprefixed ones are used.

I'm not sure I see the value in client properties being separated from server properties.
 If ssl is enabled for the server, it should be enabled for clients.  For the most part these
don't need to overlap, since server properties will come out of accumulo-site.xml and client
properties will come out of local client config, but it would be nice if, for example, the
shell continued to work without special configuration, because it just picked up general.ssl.enabled
from the site config.

The prefix fallback process sounds like a good addition, but it seems like it makes more sense
in combination with a bigger conf refactor (for example splitting into client.conf, monitor.conf,
etc).  I'd like to defer that work to the broader effort so changes in conf patterns can be
considered holistically.

Regarding BC:

Right now it's not totally's used by the MAC if you enable SSL to provision
its own local cert (much like it generates all its own config as part of initialization).
 Thus it's also used by the ITs to test SSL.  I suppose we could make the MAC not natively
support SSL, requiring users to provide their own certs, and just include pre-generated certs
in the ITs' resources directory, but that feels less elegant than being able to say simply
miniAccumuloConfig.useSsl(true) if you want to test SSL connections.

Also, regarding provisioning scenarios, I think some people will want to use certs signed
by public CAs the same way they would want to for a webserver, but I still believe this will
be unwieldy for tservers.  I think the much more common scenario would be for someone to generate
a self-signed root on one box, and then want to just cut however many more local certs on
each of the nodes in the cluster.  As far as reducing the learning curve for system administrators,
I think running {{bin/accumulo init-ssl}} on each machine, and having that generate certs
in default locations and not require any additional config would actually be less work than
making them configure a bunch of properties and figure out what relationships they want among
all their certs, even if the properties point to standardish locations.  Having a separate
root and trust tree for accumulo also provides some additional protection.  I may not want
to trust any accumulo that has a cert signed by a public CA, since anyone could have a cert
signed by a public CA.  If my cluster has its own root, I can be confident that any cert signed
by that root is part of my cluster.
> Support encryption over the wire
> --------------------------------
>                 Key: ACCUMULO-1009
>                 URL:
>             Project: Accumulo
>          Issue Type: New Feature
>            Reporter: Keith Turner
>            Assignee: Michael Berman
>             Fix For: 1.6.0
>         Attachments: ACCUMULO-1009_thriftSsl.patch
> Need to support encryption between ACCUMULO clients and servers.  Also need to encrypt
communications between server and servers.   
> Basically need to make it possible for users to enable SSL+thrift.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message