Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Wed, 18 Sep 2013 18:37:51 +0000 (UTC)
From: "Christopher Tubbs (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12629984.1359576401192.156329.1379529471635@arcas>
In-Reply-To: <JIRA.12629984.1359576401192@arcas>
References: <JIRA.12629984.1359576401192@arcas>
Subject: [jira] [Commented] (ACCUMULO-1009) Support encryption over the wire
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

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

[~mberman] wrote:
{quote}I'm not sure I see the value in client properties being separated from server properties.{quote}

You're right. "rpc." might be an appropriate scope for both client and server configuration.

{quote}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.{quote}

Seems reasonable. I had hoped I'd have time for that in 1.6, but the timeline is advancing too quickly, and I'm doubtful I'm going to have time for it. My main concern at this point is that I don't want to set a precedent that we're stuck with that would prevent this improvement in 1.7.

[~kturner] wrote:
{quote}Introducing this feature in 1.6 and a proper client side config in 1.7 is sub-optimal for users.{quote}

Agreed, but I'm not sure I have time to re-prioritize. If we can avoid that, to reduce any potential churn, by hammering it out here, I'd rather do that.

[~mberman] wrote:
{quote}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.{quote}

Actually, there's precisely what [keytool-maven-plugin|http://mojo.codehaus.org/keytool/keytool-maven-plugin/] is for. I'd much rather have MiniAccumuloCluster use a specified keystore from config properties than to generate its own. That way, it more closely resembles a real Accumulo instance's configuration (a design goal for Mini is that it mimics a real instance as closely as possible).

{quote}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.{quote}

It's not always about reducing the work... sometimes, it's about doing stuff in the way they already know how to do (or have already done). I'd much rather not re-invent the wheel for provisioning certs. If we just make it simple to configure certs, system administrators can just provision using whatever process they currently know or use. No re-inventing the wheel at all.

As for "real CA" signing... I expect a common use case would be to use an intermediate CA that is signed by a "real CA". I'm not suggesting that anybody go through the headache of getting every tserver cert signed by a common public root. But... it doesn't really matter whether the "real CA" is one that is pre-configured in a browser (something like VeriSign's root)... so long as it's easy to configure. The point is to make it easy to *control* which one they'll trust... which may be generated from their root, or an intermediate root, or a trustStore that holds all the individual tserver public certs. The point is to not make decisions for users regarding certificate provisioning, and to just make it easy for them to use what they want.

I'll have to take a more detailed look at the updated patch sometime later today to see if I have any further feedback.
                
> 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