cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maulin Vasavada (Jira)" <>
Subject [jira] [Commented] (CASSANDRA-16666) Make SSLContext creation pluggable/extensible
Date Wed, 21 Jul 2021 17:41:00 GMT


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


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:
>             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 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 implement an extensible interface. 
> I contributed a similar change that is live now in Apache Kafka (2.6.0) - 
> I can spare some time writing the pluggable interface and run by the required reviewers.
> Created [CEP-9: Make SSLContext creation pluggable|] 
> cc: [~dcapwell] [~djoshi]

This message was sent by Atlassian Jira

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message