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?