[
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:31 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.
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 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.
> 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
