Story: convention for sensitive configuration values

[paullatzelsperger]

Discussed in #4649

Feature Request

For sensitive configuration values, a consistent naming scheme and resolution mechanism will be implemented.

A sensitive configuration value should primarily be resolved from the Vault using its config key plus the ".alias" suffix as secret key.
For example, "edc.dataspace.default.url" would be stored as "edc.dataspace.default.url.alias" in the Vault.

If the sensitive configuration value is not found in the vault, it is resolved from the Config using its config key minus the ".alias" suffix, i.e. "edc.dataspace.default.url".

Note that this does not apply to public or private keys. They must always be resolved from the vault!

Which Areas Would Be Affected?

• SQL connection pool (CommonsConnectionPoolServiceExtension)
• token-based API auth (TokenBasedAuthenticationExtension), just to verify
• STS client configuration (RemoteSecureTokenService, StsRemoteClientConfigurationExtension)
• possibly others?

Why Is the Feature Desired?

consistent naming conventions, faster startup (no need to look in the vault, if the alias is not configured), ground work for a more integrated approach through config injection

Future work

Once this manual approach is implemented, we can investigate how to integrate this into the configuration injection, something like this:

@Setting(..., sensitive = true, key = "some.config.value")
private String sensitiveValueWithFallback; // vault of config

@Setting(..., sensitive = true, allowFallback = false)
private String supersecretValue; // must be resolved from Vault, no fallback

Steps

• Sensitive config values with fallback #4657
• Decision Record about sensitive config injection #4658
• Config injection of sensitive values (depends on Decision Record about sensitive config injection #4658)

[github-actions]

This issue is stale because it has been open for 28 days with no activity.