Versions Compared

Key

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

...

Below is the interface suggested for this.

In the interface we provide a way to customize SSLContext and SSLEngine both because SSLContext ideally has all the data points to be customized (see JSSE reference diagram) but for Kafka SSLEngine needs to be further configured based on Client or Server Mode as it is done currently.

Code Block
package org.apache.kafka.common.security.ssl;

import org.apache.kafka.common.network.Mode;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLEngine;
import java.util.Map;
import java.util.Set;

public interface SslEngineFactory {

	/**
     * Creates SSLContext by providing required key material and {@code java.security.SecureRandom}
     *
     * @return	The SSLContext.
     */
	SSLContext createSSLContext();

    /**
     * Creates a new SSLEngine object.
     *
     * @param mode      Whether to use client or server mode.
     * @param peerHost  The peer host to use. This is used in client mode if endpoint validation is enabled.
     * @param peerPort  The peer port to use. This is a hint and not used for validation.
     * @param endpointIdentification Endpoint identification algorithm for client mode.
     * @return          The new SSLEngine.
     */
    SSLEngine createSSLEngine(Mode mode, String peerHost, int peerPort, String endpointIdentification);

    /**
     * Returns the currently used configurations by this engine.
     * @return
     */
    Map<String, Object> currentConfigs();

    /**
     * Returns the reconfigurable configs used by this engine.
     * @return
     */
    Set<String> reconfigurableConfigs();

    /**
     * Returns true if this engine needs to be rebuilt.
     *
     * @param nextConfigs       The configuration we want to use.
     * @return                  True only if this builder should be rebuilt.
     */
    boolean shouldRebuiltFor(Map<String, Object> nextConfigs);
}

Why we allow SSLContext and SSLEngine creation in the interface?

...


Proposed Changes

Currently SslFactory.java uses SslEngineBuilder.java. Instead of that we will modify SslFactory.java to load a class configured via the new configuration 'ssl.engine.factory.class' and delegate the SSLEngine creation call to the implementation. 

...

Default implementation would be along the lines (but not necessarily the same) of - sample code which is copied from current very similar to the current SslEngineBuilder.java.

Which classes will be deleted?

...

  • SslEngineFactory.java Interface
  • SslEngineFactoryInstantiator.java (as an inner class to SslFactory)
  • DefaultSslEngineFactory.java (mostly having code from existing SslEngineBuilder)

Which classes will be modified primarily?

  • SslFactory.java 

How does configs get to the implementation class?

...

By custom configs we mean the configs used by the SslEngineFactory's implementation. Those configs does not have to be part of definition of Kafka configs since only the implementation class knows what are those. This need to be explored more. We don't have clarity on how this can be achieved. At a surface level it seems the provider of the SslEngineFactory's implementation also should provide classes to trigger the reconfiguration since only that provider knows about the configs.Kafka already supports custom configs so this should not be a new challenge. 

Other challenge

Currently reconfigurations are pushed from Kafka code base to the reconfigurable classes. However, depending upon SslEngineFactory's implementation we could have some events/changes detected by the implementation first and we would need to trigger reconfiguration on SslFactory in order to get re-initialized!

...

This is because currently SslFactory does certain validations which we want to keep separate and mandate those checks across any possible implementation of pluggable class. Also, once we start writing the reconfigurable classes we realize that we need two classes - 1) Engine factory implementation and 2) Container of the factory implementation. We believe that keeping SslFactory as Reconfigurable object and help reconfigure the underlying SslEngineFactory will simplify the implementations of SslEngineFactory.