accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Berman <>
Subject SSL patch for comment
Date Tue, 13 Aug 2013 20:17:48 GMT
I attached the first draft of my SSL patch for comment to

To generate keys, in $ACCUMULO_HOME, mkdir conf/ssl and run:

bin/accumulo generate-all
--local-keystore conf/ssl/keystore.jks --root-keystore conf/ssl/root.jks
--root-truststore conf/ssl/truststore.jks

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

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
- 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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message