[
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
