accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Berman (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-1009) Support encryption over the wire
Date Wed, 18 Sep 2013 18:59:51 GMT

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

Michael Berman commented on ACCUMULO-1009:
------------------------------------------

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

I like rpc.  I'll update the patch.

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

I think we have a pretty graceful path at this point.  If we introduce the fully qualified
property names now, we can introduce a fallback to more general properties later and any old
config will continue to work fine.  It doesn't feel like these couple new properties motivate
separating into separate config files, since whenever we do that, we're going to have to keep
supporting a unified accumulo-site.xml, so having a couple extra properties in there doesn't
seem like it'll affect ease of implementation or migration one way or the other.

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

There's absolutely nothing preventing you from provisioning certs the way you know how, assuming
you already know how and you happen to have an intermediate cert handy.  I think it would
be nice for people to have an easy option as well if they're not already so equipped.  And
as [~mallen] says above, there are definitely security and operational reasons for wanting
a separate trust tree for your accumulo deployment.

I do think you're right that it would be good to be able to configure a MAC to use existing
certs...I'll make that update in the next round.  But I also think there's value in not _having_
to pre-provision certs just to use a MAC with SSL.  You say that a design goal for the MAC
is to mimic a real instance as closely as possible, but at the moment there's actually no
way for you to tell it to use an external config source at all.  You just configure a MiniAccumuloConfig,
and then it writes out its own entire conf directory.  It doesn't seem like it's compromising
the design to have it also write out certs as part of that step.
                
> 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