Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
Accumulo >> mail # dev >> SSL patch for comment


+
Michael Berman 2013-08-13, 20:17
Copy link to this message
-
Re: SSL patch for comment
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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB