[
https://issues.apache.org/jira/browse/CASSANDRA-16666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17358655#comment-17358655
]
Sumanth Pasupuleti commented on CASSANDRA-16666:
------------------------------------------------
[~maulin.vasavada] left a couple of review comments, but lgtm overall.
One of the things I was hoping we can also achieve is to be able to provide
mechanics to transparently transition from using one SSLFactory implementation
to another, and using those mechanics, one could do the following on their
cluster for moving from say Implementation1 to Implementation2
Stage #1: Current state of being only Implementation1 aware. Use keystore and
trustmanager of implementation1
Stage #2: Start trusting both implementation1 and implementation2. Use keystore
of implementation1, but use trustmanager of both implementation1 and
implementation2 (using MultiTrustManagerFactory) (and perform a rolling restart
of the cluster)
Stage #3: Start using implementation2 for keystore, and perform a rolling
restart of the cluster
Stage #4: At this point, all nodes of the cluster are using implementation2 for
keystore, but trust both implementation1 and implementation2, and we can now
remove implementation1 from trustmanagers, and do a rolling restart.
Since this ticket is about making SSLContext pluggable, I believe this is out
of scope; cut a separate ticket CASSANDRA-16719 to track that work (I did an
internal 3.0 patch for this transition work, and I can try porting it to 4.x
once this ticket is committed)
> Make SSLContext creation pluggable/extensible
> ---------------------------------------------
>
> Key: CASSANDRA-16666
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16666
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Internode
> Reporter: Maulin Vasavada
> Assignee: Maulin Vasavada
> Priority: Normal
> Fix For: 4.x
>
>
> Currently Cassandra creates the SSLContext via SSLFactory.java. SSLFactory is
> a final class with static methods and not overridable. The SSLFactory loads
> the keys and certs from the file based artifacts for the same. While this
> works for many, in the industry where security is stricter and contextual,
> this approach falls short. Many big organizations need flexibility to load
> the SSL artifacts from a custom resource (like custom Key Management
> Solution, HashiCorp Vault, Amazon KMS etc). While JSSE SecurityProvider
> architecture allows us flexibility to build our custom mechanisms to validate
> and process security artifacts, many times all we need is to build upon
> Java's existing extensibility that Trust/Key Manager interfaces provide to
> load keystores from various resources in the absence of any customized
> requirements on the Keys/Certificate formats.
> My proposal here is to make the SSLContext creation pluggable/extensible and
> have the current SSLFactory.java implement an extensible interface.
> I contributed a similar change that is live now in Apache Kafka (2.6.0) -
> https://issues.apache.org/jira/browse/KAFKA-8890
> I can spare some time writing the pluggable interface and run by the required
> reviewers.
>
> Created [CEP-9: Make SSLContext creation
> pluggable|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable]
>
>
> cc: [~dcapwell] [~djoshi]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
