...

Current state: Under Discussion

Discussion thread: TBDhere

JIRA: CASSANDRA-16666

Released: TBD

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

Cassandra's adoption is growing day-by-day in the industry and it is used by all sizes of organizations serving varied technical and business domains like banking, entertainment, food/transportation logistics, financial technology to name a few. These organizations depending upon their size and domain may have more internal and external InfoSec/AppSec/Compliance standards they have to meet while using Cassanddra. SSL/TLS communication is very critical part of those standards. While Cassandra supports SSL communication sometimes it becomes challenging to use out-of-the-box solution provided by Cassandra for SSL/TLS given the organization's needs.

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 with the absence of any customized requirements on the Keys/Certificate formats.

According to JSSE Documentation SSLContext and SSLEngine are the endpoint classes for the secure connection. Moreover, SSLEngine is created by SSLContext and can be further customized according to the needs. Hence if Cassandra provides a way to customize SSLContext it would be a great lever and provide the ultimate extensibility for the Cassandra users.

My proposal here is to make the SSLContext creation pluggable/extensible and have the current SSLFactory.java implement an extensible interface. Of course we would need to also address requirements of Hot reloading of the SSLContext, currently implemented by this class for file based keystores.

Audience

Cassandra users.

Goals

...