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 Wed, 18 Sep 2013 18:37:51 GMT

    [ 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

Mime
View raw message