[
https://issues.apache.org/jira/browse/CASSANDRA-16666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17382936#comment-17382936
]
Stefan Miklosovic commented on CASSANDRA-16666:
-----------------------------------------------
I dont think it is confusing to pass the map of params into that constructor
for that factory only and having options in the method for context creation.
Why is it confusing for you? That is the way how it is done for other cases,
maps into constructors.
Check how it is done for BinAuditLogger, AuditLogManager and AuditLogOptions.
Actually, encryption options should not ideally be passed into these methods
for context creation at all. Since you said in the cep (i think) that passing
options class containing file-based stuff is weird for custom implementations
which are going to deal with something completely different, the implementation
itself should not be aware of that then (the interface's methods). So yes, the
map solution of your does make sense here. So everything should be pushed via
map then and default implementation would pick what it is interested in,
knowing it comes from EncryptionOptions from cassandra.yaml, but we do not have
to mention it in the interface's methods.
However, if there is some custom implementation which would like to see these
options in the map in its constructor, if we do not always pass it there upon
initialisation, it would have to repeat some parameters from underlying options
to have them there. We might just say that the contract of that interface is
such that the constructor receives a map of all params from cassandra.yaml +
params he set into "params" field for that factor and it is upon implementator
what he is going to do about that.
> 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: [email protected]
For additional commands, e-mail: [email protected]
