-Re: SSL patch for comment
Christopher 2013-08-26, 22:20
Going to add some comments to the ticket. :)
Christopher L Tubbs II
On Tue, Aug 13, 2013 at 4:17 PM, Michael Berman <[EMAIL PROTECTED]> wrote:
> 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 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
> 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.