Stefan Podkowinski created CASSANDRA-13314:
----------------------------------------------
Summary: Config file based SSL settings
Key: CASSANDRA-13314
URL: https://issues.apache.org/jira/browse/CASSANDRA-13314
Project: Cassandra
Issue Type: Improvement
Components: Configuration, Tools
Reporter: Stefan Podkowinski
Assignee: Stefan Podkowinski
Priority: Minor
Fix For: 4.x
As follow up of CASSANDRA-13259, I'd like to continue discussing how we can
make SSL less awkward to use and further move SSL related code out of our code
base. Currently we construct our own SSLContext in SSLFactory based on
EncryptionOptions passed by the MessagingService or any individual tool where
we need to offer SSL support. This leads to a situation where the user has not
only to learn how to enable the correct settings in cassandra.yaml, but these
settings must also be reflected in each tool's own command line options. As
argued in CASSANDRA-13259, these settings could be done as well by setting the
appropriate system and security properties
([overview|http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#InstallationAndCustomization])
and we should just point the user to the right files to do that (jvm.options
and java.security) and make sure that daemon and all affected tools will source
them.
Since giving this a quick try on my WIP branch, I've noticed the following
issues in doing so:
* Keystore passwords will show up in process list
(-Djavax.net.ssl.keyStorePassword=..). We should keep the password setting in
cassandra.yaml and clis and do a System.setProperty() if they have been
provided.
* It's only possible to configure settings for a single default
key-/truststore. Since we currently allow configuring both
ServerEncryptionOptions and ClientEncryptionOptions with different settings,
we'd have to make this a breaking change. I don't really see why you would want
to use different stores for node-to-node and node-to-client, but that wouldn't
be possible anymore.
* This would probably only make sense if we really remove the affected CLI
options, or we'll end up with just another way to configure this stuff. This
will break existing scripts and obsolete existing documentation.
Any opinions?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
