[
https://issues.apache.org/jira/browse/ACCUMULO-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13770080#comment-13770080
]
Michael Berman commented on ACCUMULO-1009:
------------------------------------------
{quote}
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.
{quote}
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 separate...it'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: https://issues.apache.org/jira/browse/ACCUMULO-1009
> 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: http://www.atlassian.com/software/jira
