Page History

Proposal is to add a new ssl property (ssl-use-default-providersslcontext) to let Geode use system default security provider context (provided by either JDK provided provider or a user provided custom provider). When using SSL, current implementation allows developers to set several ssl-* properties to define paths, types and passwords to keystore and truststoretruststores. Geode loads key and & 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-providersslcontext=true, developers can let Geode initialize the TrustMangaer & KeyManager that are default context provided by the system defaultsecurity provider and not loading keystores/truststores by using specific filesystem path.

Specifically on client-side, in a container world, having to read CERTs application running in containers letting GEODE to read CERT (key/trust stores) from a filesystem puts a an overhead of re-building application container images when these CERTs are rotated for security(Hygenic) in case of security breach or in general for hygienic purposes. So allowing application developers can 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 provides a “ContainerSecurityProvider” with 's "ContainerSecurityProvider", which provides a custom implementation for TurstMangaer and KeyManager to read and reads CERTs from CredHubenvironmental variables.

How Geode uses this flag:

...

Code Block
language java theme Emacs title geode-core/src/main/java/org/apache/geode/internal/net/SocketCreator.java
... ... private TrustManager[]SSLContext getTrustManagerscreateAndConfigureSSLContext() throws KeyStoreException, NoSuchAlgorithmException, CertificateExceptionGeneralSecurityException, IOException { if (sslConfig.isUseDefaultProvideruseDefaultSSLContext()) { TrustManagerFactory tmf =return TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithmSSLContext.getDefault()); tmf.init((KeyStore) null);} SSLContext newSSLContext return= tmf.getTrustManagersgetSSLContextInstance(); } else { //current implementation of reading truststore and initializing TMF ... ... } } private KeyManager[] getKeyManagers()keyManagers throws KeyStoreException, IOException, NoSuchAlgorithmException, CertificateException, UnrecoverableKeyException { if (sslConfig.isUseDefaultProvider()) { = getKeyManagers(); KeyManagerFactoryTrustManager[] keyManagerFactorytrustManagers = KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm()getTrustManagers(); keyManagerFactorynewSSLContext.init(nullkeyManagers, trustManagers, null); /* use the return keyManagerFactory.getKeyManagers(); } else { //current implementation of reading keystore and initializing KMF default secure random */); ... ... return newSSLContext; } } ... ...

How developers can use this flag on the client:

1. Implement custom provider as per JDK guidlines.

...

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_PROVIDERSSLCONTEXT, String.valueOf("true"));

...