Proposal is to add a new ssl property (ssl-use-default-sslcontext) to let Geode use default context (provided by either JDK provided provider or a custom provider). When using SSL, current implementation allows developers to set several ssl-* properties to define paths, types and passwords to keystore and truststores. Geode loads key & trust stores and initializes TrustManagerFactory(TMF) and KeyManagerFactory(KMF) to be used for secure socket management. This imposes certain limitations for developers who wants to bring in their custom implementation for some of the SPIs (Keystore/Truststore SPI, KeyManagerFactory/TrustManagerFactory SPI). Using this proposed new property ssl-use-default-sslcontext=true, developers can let Geode initialize the default context provided by the security provider and not loading keystores/truststores by using specific filesystem path.

Specifically on client-side, application running in containers letting GEODE to read CERT (key/trust stores) from a filesystem puts an overhead of re-building container images when these CERTs are rotated in case of security breach or in general for hygienic purposes. So allowing application developers to provide custom implementations of TMF/KMF can support reading CERTs from a non-filesystem based trust and key stores.

Eg: When using Geode on CloudFoundry, applications running using java-buildpack can take advantage of buildpack's "ContainerSecurityProvider", which provides a custom implementation for TurstMangaer and KeyManager and reads CERTs from environmental variables.

How Geode uses this flag:

geode-core/src/main/java/org/apache/geode/internal/net/SocketCreator.java
...

...

private SSLContext createAndConfigureSSLContext() throws GeneralSecurityException, IOException {

    if (sslConfig.useDefaultSSLContext()) {
      return SSLContext.getDefault();
    }

    SSLContext newSSLContext = getSSLContextInstance();
    KeyManager[] keyManagers = getKeyManagers();
    TrustManager[] trustManagers = getTrustManagers();

    newSSLContext.init(keyManagers, trustManagers, null /* use the default secure random */);
    return newSSLContext;
}

...

...

How developers can use this flag on the client:

1. Implement custom provider as per JDK guidlines.

2. Add the custom provider.

Add custom Provider
Security.insertProviderAt(new CustomProvider(), 2);

or

Security.addProvider(new CustomProvider());

3. Set these gemfire properties and initialize ClientCache.

Gemfire Properties
Properties pros = new Properties();

props.setProperty(ConfigurationProperties.SSL_ENABLED_COMPONENTS, SecurableCommunicationChannels.SERVER);

props.setProperty(ConfigurationProperties.SSL_REQUIRE_AUTHENTICATION, String.valueOf("true"));

props.setProperty(ConfigurationProperties.SSL_USE_DEFAULT_SSLCONTEXT, String.valueOf("true"));
  • No labels