cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maulin Vasavada (Jira)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-16666) Make SSLContext creation pluggable/extensible
Date Fri, 09 Jul 2021 00:38:00 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-16666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17377652#comment-17377652
] 

Maulin Vasavada edited comment on CASSANDRA-16666 at 7/9/21, 12:37 AM:
-----------------------------------------------------------------------

On second thoughts [~stefan.miklosovic], I feel if we examine the interface properly and make
sure of the contract and dependencies - input arguments to the methods and construction of
the implementation (for which I agree there is no good way given an interface) object AND
the return types/exceptions, it could be evaluated without sample of a specific/custom implementation.
The premise is very simple - Allow SSLContext (in this case JSSE's and Netty's) creation to
be pluggable. Once we do that the specific implementation should not matter. However the Cassandra's
current integration point with that pluggable interface does matter and need to make sure
we are not violating existing behavior - example - Caching of the Netty's ssl contexts, invocation
of context for Inbound/Outbound and Client/Native connections, threads running for enabling
hot reloading periodically etc. I know its a long answer to your question but I have done
very similar work for Apache Kafka ([reference|[https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=128650952]])
and feel confident that it will work for custom implementations (like ours is running in production
for about 2 years now, albeit private implementation). I've consulted many security experts
internally and externally to validate that - making SSLContext customizable/pluggable is the
best way to support various specific needs of bigger eco-systems.

 

In fact based on my evaluation of the design - I do have two [sub options|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable#CEP9:MakeSSLContextcreationpluggable-ImportantnoteaboutcommonSSLconfigurations]
that I seek input from the community on - about consolidating all the encryption options as
a open ended Map argument coming to the interface's implementation vs having a notion of CommonEncryptionOptions
to keep some of the existing implementation as-is.


was (Author: maulin.vasavada):
On second thoughts [~stefan.miklosovic], I feel if we examine the interface properly and make
sure of the contract and dependencies - input arguments to the methods and construction of
the implementation (for which I agree there is no good way given an interface) object AND
the return types/exceptions, it could be evaluated without sample of a specific/custom implementation.
The premise is very simple - Allow SSLContext (in this case JSSE's and Netty's) creation to
be pluggable. Once we do that the specific implementation should not matter. However the Cassandra's
current integration point with that pluggable interface does matter and need to make sure
we are not violating existing behavior - example - Caching of the Netty's ssl contexts, invocation
of context for Inbound/Outbound and Client/Native connections, threads running for enabling
hot reloading periodically etc. I know its a long answer to your question but I have done
very similar work for Apache Kafka ([reference|[https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=128650952])] and
feel confident that it will work for custom implementations (like ours is running in production
for about 2 years now, albeit private implementation). I've consulted many security experts
internally and externally to validate that - making SSLContext customizable/pluggable is the
best way to support various specific needs of bigger eco-systems.

 

In fact based on my evaluation of the design - I do have two [sub options|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable#CEP9:MakeSSLContextcreationpluggable-ImportantnoteaboutcommonSSLconfigurations]
that I seek input from the community on - about consolidating all the encryption options as
a open ended Map argument coming to the interface's implementation vs having a notion of CommonEncryptionOptions
to keep some of the existing implementation as-is.

> 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-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message