Going to add some comments to the ticket. :) -- Christopher L Tubbs II http://gravatar.com/ctubbsii
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 > https://issues.apache.org/jira/browse/ACCUMULO-1009. > > 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 > 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. > > Michael
