[ 
https://issues.apache.org/jira/browse/CASSANDRA-16666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Maulin Vasavada updated CASSANDRA-16666:
----------------------------------------
    Description: 
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.

 

cc: [~dcapwell] [~djoshi]

  was:
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). 

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.

 

cc: [~dcapwell] [~djoshi]


> Make SSLContext creation pluggable/extensible
> ---------------------------------------------
>
>                 Key: CASSANDRA-16666
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-16666
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Maulin Vasavada
>            Assignee: Maulin Vasavada
>            Priority: Normal
>
> 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.
>  
> 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

Reply via email to