You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Make key and trust stores reload automatically upon change

To be Reviewed By: February 17, 2021

Authors: Joris Melchior

Status: Draft | Discussion | Active | Dropped | Superseded

Superseded by: N/A

Related: N/A

Problem

Currently, in order to rotate certificates each member of the cluster needs to be restarted to load new certs and trust. It would be preferable if certificates can be rotated without having to restart members.

Anti-Goals

We do not try to change the format of key and trust stores and we do not try to change basic design of our TLS implementation for the Geode cluster.

Solution

When starting up a cluster member we currently read the TLS configuration which, when TLS is enabled has key and trust store files defined. In case those files are defined they are read, and the information inside them is loaded into the key and trust manager objects that are loaded into the SSLContext.

This solution will introduce wrapper objects for the key and trust managers and file/directory watcher(s) that can detect changes to the key and trust store files. When key and trust store files are changed this will trigger a reload into key and trust managers and through the wrapper objects these new key and trust managers will be injected into the SSLContext so that the context can start using the new key and trust managers in process.

Changes and Additions to Public Interfaces

This change will not have an impact on Public Interfaces.

Performance Impact

This change should reduce member restarts and therefor have a positive impact on system performance.

Backwards Compatibility and Upgrade Path

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

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

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?

We are not aware of alternatives to this solution.

If we don't solve the problem we will continue to require to restart members when certs are changed.

This proposal will simplify the administration task of rotating certs for a Geode cluster.

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?

  • No labels