Allow multiple trust and key store files to be configured for a Geode cluster

To be Reviewed By:

Authors: Joris Melchior

Status: Draft | Discussion | Active | Dropped | Superseded

Superseded by: N/A

Related: N/A

Problem

In our current TLS configuration we can only define one trust and one key file for the system. It would be convenient to have multiple files so we can source the information from more than one place in case clients have separate files for mTLS for example.

Anti-Goals

We do not want to change the format of the files or make change to the core implementation of TLS in Geode.

Solution

Change our configuration in such a way that the properties SSL_TRUSTSTORE, SSL_TRUSTSTORE_PASSWORD, SSL_KEYSTORE, SSL_KEYSTORE_PASSWORD are renamed to show that they represent multiple values.

Change our configuration code so that we can parse these parameters as comma separated values.

Change our configuration code so that we can use the parsed values to load multiple files with associated passwords when loading TLS key and trust store information.

Changes and Additions to Public Interfaces

The configuration parameters are part of the Public interface of Geode so this is a change to that interface.

Performance Impact

Apart from a possible minute impact on startup this should not impact the performance of a Geode cluster.

Backwards Compatibility and Upgrade Path

Will the regular rolling upgrade process work with these changes? No

How do the proposed changes impact backwards-compatibility? Are message or file formats changing? Yes (backwards-compatibility)

Is there a need for a deprecation process to provide an upgrade path to users who will need to adjust their applications? No

Prior Art

What would be the alternatives to the proposed solution? What would happen if we don’t solve the problem? Why should this proposal be preferred?

As an alternative we could leave the existing parameters unchanged and add the parameters that represent multiple values of the existing ones as new parameters and adjust the code to use one or the other depending on what information is provided in the configuration.

The benefit of the alternate approach is that it would be fully backwards compatible.

The downside of the alternate approach is that it would make the code more complex and that we would have to deprecate some parameters and at some point in the future remove the deprecated parameters and code that allows for the different approaches.

FAQ

Answers to questions you’ve commonly been asked after requesting comments for this proposal.

Errata

What are minor adjustments that had to be made to the proposal since it was approved?