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] [Commented] (CASSANDRA-16666) Make SSLContext creation pluggable/extensible
Date Sat, 17 Jul 2021 01:11:00 GMT

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

Maulin Vasavada commented on CASSANDRA-16666:
---------------------------------------------

[~stefan.miklosovic] Given that now CEP is in Accepted state, I think we should continue
discussing technical details here.

 

About using Map vs CommonEncryptionOptions-

Now I have a reference implementation for [Map|https://github.com/maulin-vasavada/cassandra/commit/256ad30ecedbc50d66d8a039f8ca9e47074737ce]
and [CommonEncryptionOptions|https://github.com/maulin-vasavada/cassandra/commit/f8a38194cd209beac9c8e018cd90f404b4ff9b16].
I was thinking more about your previous comments on the getting sensitive information leaked
if we use Map. While that is true, I don't think there is a good way until Cassandra starts
supporting "types" for the Config keys and have sort of Password type for some keys (I've
used that in some other Apache projects). Also, as soon as we talk about additional configuration
needed for a custom ISslContextFactory implementation, we would end up passing open-ended
string key-value pairs via the Map like [this|https://github.com/maulin-vasavada/cassandra/blob/CEP-9-common-encryption-options/test/conf/cassandra-sslcontextfactory.yaml#L56] and
that essentially leaves that hole open.

 

Also, looking at both options implementation I feel apart from your comments on parsing the
params etc I like the Map option better for the following reasons,
 # It gives complete control of every single SSL configuration parameter to the ISslContexFactory's
implementation (like how accepted protocols are decided based on the input, cipher suite,
protocol value treatment etc). Example [this line|https://github.com/maulin-vasavada/cassandra/blob/CEP-9-config-as-map/src/java/org/apache/cassandra/config/EncryptionOptions.java#L309]
 # I am personally not satisfied with how I ended up doing CommonEncryptionOptions (may be
its different than what you had in mind)
 # With the CommonEncryptionOptions (at-least in the way I have currently), it seems very
convoluted to understand. Example line [this one|https://github.com/maulin-vasavada/cassandra/blob/CEP-9-common-encryption-options/src/java/org/apache/cassandra/security/SSLFactory.java#L193]
. It is very confusing to say "Hey 'options' create Netty Ssl Context and by-the-way here
are the 'options' :)  

 

Please let me know your thoughts on the same. 

 

> 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