mirror of
https://github.com/rustfs/rustfs.git
synced 2026-08-02 19:39:17 +00:00
Zhengchao An
ad721bff42
* fix(kms): honour the configured metadata cache TTL and metrics switch KmsManager::new built the KmsCache from cache_config.max_keys alone, so cache_config.ttl was dead configuration: every deployment ran the hardcoded 300s window whatever the admin configure API was given, while CacheSummary and the KMS config endpoint reported the configured value back. cache_config.enable_metrics was never read anywhere. Build the cache from the whole CacheConfig. The documented default is reconciled down to the 300s the cache has always used rather than up to the advertised 3600s, and now lives in one place (DEFAULT_CACHE_TTL) instead of being duplicated across the four configure-request converters, so the default path behaves exactly as before. Behaviour change: a deployment configured through the admin API already has ttl 3600 persisted, because the old converters wrote that default into the stored config, so its describe_key staleness window widens from an effective 300s to the 3600s it asked for. No cryptographic or authorization path widens - encrypt, decrypt and generate_data_key go straight to the backend and never read this cache. The Vault Transit backend's own metadata cache, which does gate crypto through ensure_key_state_allows, stays fixed at 300s and is now documented as deliberately not operator-tunable. The configured duration now reaches moka's builder, which panics above 1000 years, so CacheConfig::effective_ttl clamps to a 24h maximum the way effective_timeout already clamps its own, and validate rejects a zero TTL beside the existing max_keys check. Both config summaries and the KMS config endpoint report the effective value, so the admin API cannot advertise a lifetime the cache does not honour. enable_metrics gates publication of the rustfs_kms_metadata_cache_* families only; the counters behind the admin status API keep running either way. No configure-request field sets it yet. Refs rustfs/backlog#1584 * docs(kms): state why the Transit metadata TTL is not bound to the default The comment claimed the constant matches config::DEFAULT_CACHE_TTL, which reads as an invariant the code does not enforce. Say plainly that the equality is a coincidence rather than a contract, and why binding the two would be wrong: this cache gates crypto through ensure_key_state_allows, so a later change to the operator-facing describe-cache default must not be able to widen its staleness window.