[
https://issues.apache.org/jira/browse/CASSANDRA-16666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385020#comment-17385020
]
Maulin Vasavada commented on CASSANDRA-16666:
---------------------------------------------
Hi [~stefan.miklosovic]
Sorry for late response. I read and re-read your comment several times and I
think we are in-sync. Thank you for pointing at the classes I can look as a
reference, that helped me understand your comment clearly. Based on this I
think my current PR that follows having a Map holds the ground compared to
having a CommonEncryptionOption class.
I also agree to rest of your comment on default implementation pick configs
based on understanding that it comes from EncryptionOptions and having a
contract of the interface to make sure it receives map of all params from
cassandra.yaml + params set as 'params' field for a given custom factory in the
casandra yaml (like I mention in the javadoc for ISslContextFactory
[here|https://github.com/maulin-vasavada/cassandra/blob/CEP-9-config-as-map/src/java/org/apache/cassandra/security/ISslContextFactory.java#L42])
With that I think, I will proceed to start addressing formatting and other
comments on the PR and start working on the example for a custom implementation.
> 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: [email protected]
For additional commands, e-mail: [email protected]
