Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Status

Current state:  Under DiscussionDone

Discussion threadhere

Vote thread: here

JIRACASSANDRA-16666 (PR#1027 Pending review)

ReleasedTBD: will be in 4.1, https://github.com/apache/cassandra/commit/24dcc280c2e442eea27e7129c4c948eb6199ed91

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

...

Code Block
languagejava
titleISslContextFactory
package org.apache.cassandra.security;

import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLException;

import io.netty.handler.ssl.CipherSuiteFilter;
import io.netty.handler.ssl.SslContext;
import org.apache.cassandra.config.EncryptionOptions;

/**
 * The purpose of this interface is to provide pluggable mechanism for creating custom JSSE and Netty SSLContext
 * objects. Please use the Cassandra configuration key {@code ssl_context_factory/**
 * The purpose of this interface is to provide pluggable mechanism for creating custom JSSE and Netty SSLContext
 * objects. Please use the Cassandra configuration key {@code ssl_context_factory} as part of {@code
 * client_encryption_options}/{@code server_encryption_options} and provide a custom class-name
 * implementing this
 * interface with parameters to be used to plugin a your own way to load the SSLContext.
 *
 * Implementation of this interface must have a constructor with argument of type {@code Map<String,String>Object>} to allow
 * custom parameters, needed by the implementation, to be passed from the Cassandra yaml configuration.
 Common *SSL
 * Sinceconfigurations onlike top{@code ofprotocol, Nettyalgorithm, Cassandra is internally cipher_suites, accepted_protocols, require_client_auth,
 * require_endpoint_verification, enabled, optional} will also be passed to that map by Cassanddra.
 *
 * Since on top of Netty, Cassandra is internally using JSSE SSLContext also for certain use-cases- this interface
 * has methods for both.
 *
 * Below is an example of how to configure a custom implementation with parameters
 * <pre>
 * ssl_context_factory:
 *       class_name: org.apache.cassandra.security.YourSslContextFactoryImpl
 *       parameters:
 *         key1: "value1"
 *         key2: "value2"
 *         key3: "value3"
 * </pre>
 */
public interface ISslContextFactory
{
    /**
     * Creates JSSE SSLContext.
     *
     * @param options EncryptionOptions that could be used for the SSL context creation
     * @param buildTruststore {@code true} if the caller requires Truststore; {@code false} otherwise
     * @return
     * @throws SSLException in case the Ssl Context creation fails for some reason
     */
    SSLContext createJSSESslContext(EncryptionOptions options, boolean buildTruststore) throws SSLException;

    /**
     * Creates Netty's SslContext object.
     *
     * @param optionsbuildTruststore EncryptionOptions{@code thattrue} couldif bethe usedcaller forrequires the SSL context creation
     * @param buildTruststore {@code true} if the caller requires Truststore; Truststore; {@code false} otherwise
     * @param socketType {@link SocketType} for Netty's Inbound or Outbound channels
     * @param useOpenSsl {@code true} if openSsl is enabled;{@code false} otherwise
     * @param cipherFilter to allow Netty's cipher suite filtering, e.g.
     * {@link io.netty.handler.ssl.SslContextBuilder#ciphers(Iterable, CipherSuiteFilter)}
     * @return
     * @throws SSLException in case the Ssl Context creation fails for some reason
     */
    SslContext createNettySslContext(EncryptionOptions options, boolean buildTruststore, SocketType socketType,
                                     boolean useOpenSsl, CipherSuiteFilter cipherFilter) throws SSLException;

    /**
     * Initializes hot reloading of the security keys/certs. The implementation must guarantee this to be thread safe.
     * @param@throws optionsSSLException
 Client encryption options (Native Protocol)*/
     * @throws SSLException
     */
    void initHotReloading(EncryptionOptions optionsvoid initHotReloading() throws SSLException;

    /**
     * Returns if any changes require the reloading of the SSL context returned by this factory.
     * This will be called by Cassandra's periodic polling for any potential changes that will reload the SSL context
     * . However only newer connections established after the reload will use the reloaded SSL context.
     * @return
     */
    boolean shouldReload();

    /**
     * Returns if this factory uses private keystore.
     * @param options Encryption options
     * @return {@code true} by default unless the implementation overrides this
     */
    default boolean hasKeystore(EncryptionOptions options) {
        return true;
    }

    /**
     * IndicatesReturns ifthe theprepared processlist holdsof the inbound/listening end of the socket ({@link SSLFactory.SocketType#SERVER})), oraccepted protocols.
     * @return array of protocol names suitable for passing to Netty's SslContextBuilder.protocols, or null if the
     * outbounddefault
   side ({@link SSLFactory.SocketType#CLIENT}). */
    List<String> getAcceptedProtocols();

     /**/
    enum SocketType* {
Returns the list of cipher suites supported by SERVER, CLIENT;the implementation.
     * }
}

Important note about common SSL configurations 

@return
     */
    List<String> getCipherSuites();

    /**
     * Indicates if the process holds the inbound/listening end of the socket ({@link SSLFactory.SocketType#SERVER})), or the
     * outbound side ({@link SSLFactory.SocketType#CLIENT}).
     */
    enum SocketType {
        SERVER, CLIENT;
    }
}

Important note about common SSL configurations 

Currently the EncryptionOptions contains the keystore/truststore paths and other important SSL configuration parameters for the SSL connection (like ciphers, ssl protocol version, client-auth-required flag, endpoint verification flag etc). These "other important" configuration options we refer as the "common Currently the EncryptionOptions contains the keystore/truststore paths and other important SSL configuration parameters for the SSL connection (like ciphers, ssl protocol version, client-auth-required flag, endpoint verification flag etc). These "other important" configuration options we refer as the "common SSL configurations" in the title here.

...

  1. Should not ideally we move out the common SSL configurations in the EncryptionOption and may be define a parent class like CommonEncryptionOption?
    1. Response: Ideally yes. While it is little weird to have conflicting configuration options in the EncryptionOption (i.e. file based keystore/truststore paths and pluggable sslcontext factory which mostly intended toward not using file based artifacts), practically we could still live with little imperfection. However we will be open to discuss if the community members feel it is best to have a parent class to move out 'common' ssl configurations between file based and pluggable sslcontext factory.
    2. Above stated reason results into the current design of the interface which requires EncryptionOptions to be passed to most of it's methods because the implementation needs to know the "common SSL configurations".
    3. Changes would look like this Git commit
  2. Should we move to model of having Map<String,String> type as passing all the SSL configuration options to any implementation of the ISslContextFactory including the Default/Common one?
    1. Yes we could do that but for that we would have to "copy" all the common SSL configurations to the Map<String,String> while creating the instance of the ISslContextFactory's implementation including the Default one. This would also help make the imperfection of not adding CommonEncryptionOption suggested in the 1st question.
    2. Again, we would need community's input on the preference. Changes would look like this Git commit
    3. As you would notice from the above Git commit link, this option means we would need to move EncryptedOptions#acceptedProtocols() and EncryptionOptions#cipherSuiteArray() to ISslContextFactory interface commit link, this option means we would need to move EncryptedOptions#acceptedProtocols() and EncryptionOptions#cipherSuiteArray() to ISslContextFactory interface 

Final recommendation

Based on community input (discussion on the JIRA), having a Map makes more sense here. However a minor modification we have to do is it would be a Map<String,Object> instead of Map<String,String> since there are certain SSL configurations which are List type (e.g. cipher suites, accepted protocols etc).

Compatibility, Deprecation, and Migration Plan

...

  • When will we remove the existing behavior?

Not applicable

Test Plan

  • Successful integration tests
  • Successful local system test to use existing mechanism for the keystores and make sure the default SslContextFactory works for JSSE and Netty SSL Context creation
  • For any additional requirements from the Cassandra community, will seek guidance on the discussion thread

Rejected Alternatives

Modify existing SSLFactory to allow custom mechanism to load keystores only

  • Successful integration tests
  • Successful local system test to use existing mechanism for the keystores and make sure the default SslContextFactory works for JSSE and Netty SSL Context creation
  • For any additional requirements from the Cassandra community, will seek guidance on the discussion thread

Rejected Alternatives

Modify existing SSLFactory to allow custom mechanism to load keystores only

If we allow custom mechanism to load keystores from any source, it could still limit ability to customize other parameters in the SSLContext. This could become a limitation for a use-case. Delegating the creation of the whole SSLContext object is more flexible approach that can fit variety of use-cases. 

Writing a new JSSE Security Provider

JSSE Security Provider is more suitable when we need to customize security implementation for validating certs (example SPIFFE) or other specific JSSE 'services' like digest etc. Here our primary goal is to make SSLContext creation only as a pluggable mechanism and the JSSE Security Provider seems a mis-fit solution for that.If we allow custom mechanism to load keystores from any source, it could still limit ability to customize other parameters in the SSLContext. This could become a limitation for a use-case. Delegating the creation of the whole SSLContext object is more flexible approach that can fit variety of use-cases.