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 23:44:52 GMT

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

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

{quote}I think we have a pretty graceful path at this point.{quote}

Agreed.

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

No (so long as you're making it configurable... and I think we're on the same page on that),
there's nothing preventing you from doing that. But, by providing a "security on" button,
you're encouraging users to not even think about security by creating an easy button (like
your proposed "bin/accumulo init-ssl") that presumably implements some sort of security without
thinking about what kind of security, what protections it offers, and what risks it mitigates.
This is a bad precedent, and it feels like your coding to developers (like us, for ease in
testing) rather than users... either that, or users who want security but really don't know
what they're doing and who just want the comfort of "security" (not a good target audience
to cater to, as a rule).

Besides, you're *not* doing end users any favors by providing an "easy button" for security.
Anybody whose first experience with certificate management and provisioning is with this "easy
button", will have to learn it all over again when they use SSL in *any other Java application*,
and users who do have the experience will want to configure the details themselves, to ensure
they are set up correctly (or they'll learn an unnecessary shortcut).

The short of it is that Accumulo should not be in the business of provisioning or managing
certificates. We should make it easy to configure and use whatever certificates user provide,
and any external convenience provisioning software should be left as an external tool, because
that's outside the scope of Accumulo (just as its outside the scope of Tomcat, Apache Web
Server, Jetty, JBoss, Thrift, and any other SSL-capable application).

The best thing for provisioning is to simply document how one might provision certificates...
perhaps as a sequence of keytool or openssl commands. That way, it's clear to users that Accumulo's
security isn't anything special or custom or novel. It's simply leveraging the same kinds
of security that is available to them in other applications... the same that they may already
understand, or that is well documented, or that they can get help with on StackOverflow or
the countless message boards.

I can certainly get behind an external tool to help provision certificates for an entire cluster...
I'd probably use something like that, but I think that's way outside the scope of Accumulo.

I know it seems like it, but I'm really not trying to argue for the rougher path for end users.
I want things to go easy for them, too. But, I don't want them to have to re-learn custom
things, and I don't want compromise security by automating security considerations that are
necessary when provisioning certificates. I also don't want our public API and configuration
to reflect our internal needs for development and testing, instead of the end-user's needs.
I also want to protect against bloat, and the tendency to try to make software do all the
things.

{quote}And as Michael Allen says above, there are definitely security and operational reasons
for wanting a separate trust tree for your accumulo deployment.{quote}

I don't disagree. This is not an argument against that use case... I concede the utility and
convenience of that. I do not concede that we should provide tools for provisioning that type
of certificate chain and encourage users to turn on security "auto-magically" with an "easy
button".

{quote}no way for you to tell it to use an external config source{quote}

That's not quite true. MiniAccumuloConfig accepts a map of keys to values, for configuration
elements, which mimics the accumulo-site.xml file. It's relatively trivial to construct this
map from any arbitrary external source. Provisioning certs is not part of regular Accumulo
initialization, and it shouldn't be part of MAC's initialization.
                
> 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