accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-1009) Support encryption over the wire
Date Tue, 17 Sep 2013 21:53:51 GMT

    [ https://issues.apache.org/jira/browse/ACCUMULO-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13770033#comment-13770033
] 

Christopher Tubbs commented on ACCUMULO-1009:
---------------------------------------------

{quote}it sounds like you're fine with a service qualifier before the JSSE-like property key{quote}

Affirmative :) I'd prefer the JSSE properties go unprefixed, and the configuration location/context
perform the scoping (eg. client.conf contains raw JSSE properties, and monitor.conf contain
raw JSSE properties; vs. a single config file containing client.<JSSE property> and
monitor.<JSSE property>, but this is a decent compromise.)

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.

Regarding BC:

Automatic cert provisioning within Accumulo itself seems out of scope to me (if it were me,
I'd rather use the system's certs in /etc/pki/tls/certs/, which is the default location for
the Apache web server and a bunch of other apps, and uniquely identify the server cryptographically).
And, since BC is only needed for cert provisioning and signing, it seems to me that this code
(and dependencies) would make the most sense outside of Accumulo's core and provided as a
useful add-on. As long as we make sure Accumulo can be configured easily, we'll set the groundwork
for any provisioning utility or practice that users are already familiar with for their other
secure applications, according to their environment's policies and practices. I'd prefer not
trying to provide everything when those functions already exist in Linux environments in standard
ways. Instead, we should leverage those standard practices, and document how to interact with
them. This significantly reduces the learning curve for system administrators, I think.

As for the export stuff... [~vines] is probably right that it may be relevant to ACCUMULO-998
anyway (I'm certainly no expert), but I still don't see a need to add the dependency if it's
just for a provisioning tool that can be easily separated from core functionality.
                
> 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

Mime
View raw message