[
https://issues.apache.org/jira/browse/CASSANDRA-16666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17382398#comment-17382398
]
Maulin Vasavada edited comment on CASSANDRA-16666 at 7/17/21, 1:33 AM:
-----------------------------------------------------------------------
[~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 Password kind of "types" for some of
the Config 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|https://github.com/maulin-vasavada/cassandra/blob/CEP-9-config-as-map/src/java/org/apache/cassandra/config/EncryptionOptions.java#L203]
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]
## This kind of broader flexibility ensures we don't end up making people get
stuck 'just because some smaller thing is not pluggable' for them
# 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' :)
May be there is a way we can still leave complete autonomy to the
ISslContextFactory implementation and keep CommonEncryptionConfig.
Please let me know your thoughts on the same.
was (Author: maulin.vasavada):
[~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 Password kind of "types" for some of
the Config 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|https://github.com/maulin-vasavada/cassandra/blob/CEP-9-config-as-map/src/java/org/apache/cassandra/config/EncryptionOptions.java#L203]
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]
## This kind of broader flexibility ensures we don't end up making people get
stuck 'just because some smaller thing is not pluggable' for them
# 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-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
