It would be nice if DJ could use commons secrets for certain credentials. A natural way to do this, that does not impact the configuration model, would be to provide a "commons secrets" configuration expression resolver. Using this approach it would be possible to configure a configuration property while remaining independent of the underlying source of the property's value, whether it is derived from an environment variable, file, KMS secret, Vault secret, etc:
The fix for
COMMONS-466 provides a commons expression resolver for commons secrets. Secrets may change over time, such as when they are rotated, so DJ should be reactive to any run-time changes. Unfortunately, DJ only reacts to configuration changes that impact the underlying config.ldif file, so it will not react to run-time changes to secrets unless there is an accompanying change to the configuration, which seems unlikely. It should be noted that DJ does re-evaluate expressions when a configuration change occurs.
This issue can be closed once the configuration framework detects run-time changes to secrets and notifies their associated components.
Care should be taken to avoid caching of secrets in memory, although we'll need to store some kind of representation in order to determine if a secret has changed or not (a secure hash should be sufficient). The configuration framework could keep track of expressions and periodically refresh them to see if they have changed or not.