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] [Updated] (ACCUMULO-1009) Support encryption over the wire
Date Tue, 13 Aug 2013 20:16:47 GMT

     [ https://issues.apache.org/jira/browse/ACCUMULO-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michael Berman updated ACCUMULO-1009:
-------------------------------------

    Attachment: ACCUMULO-1009_thriftSsl.patch

Attaching first draft of SSL patch for comment.  To generate keys, in $ACCUMULO_HOME, {{mkdir
conf/ssl}} and run:

{code}
bin/accumulo org.apache.accumulo.server.security.ssl.CertUtils generate-all --local-keystore
conf/ssl/keystore.jks --root-keystore conf/ssl/root.jks --root-truststore conf/ssl/truststore.jks
{code}

then you can turn it on with instance.ssl.enabled=true in your site config.  Keystore locations
and passwords are all configurable, but the defaults should work without any additional config
(private keys protected with instance secret, and the public root cert is in a separate passwordless
truststore).

To create an SSL connection from a client, you can use the new ZKInstance constructor that
takes an additional {{boolean ssl}} parameter, or just {{echo instance.ssl.enabled=true >>
~/.accumulo/config}} to SSL all of your client connections.  If you're running your client
on the same machine where you generated certs, the default path will still work for you. 
Otherwise, {{echo ssl.client.truststore.path=/path/to/truststore.jks >> ~/.accumulo/config}}.
 I'm imagining the common usage scenario will be to have your truststore path in local client
config, but leave whether or not SSL is enabled up to each individual client application.

I added a couple SSL-enabled integration tests that cover a range of connection scenarios
(plain instance connectors, mapreduce jobs, admin commands), and you can also run _all_ the
ITs with SSL enabled with {{mvn verify -DuseSslForIT}}.

A few tasks I know I still have remaining:
- Fail fast if client and server SSL switch is mismatched based on flag in ZK
- Interactive cert generation process more like `bin/accumulo init`, rather than running CertUtils
with a big pile of switches
- SSL support on the client side of the proxy
- Docs

One known risk is that the Thrift SSL transport only supports blocking connections.  This
means that when SSL is enabled, we have to switch to a TThreadPoolServer instead of a THsHaServer.
 In theory the performance impact of this change can be mitigated by cranking up the thread
pool size, but I haven't done any scale testing to see what the practical impact of this constraint
actually is.  At the moment, as long as we use Thrift for transport, I don't think we have
much choice.

I would love comments, suggestions, questions, etc.
                
> 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