mirror of
https://github.com/rustfs/rustfs.git
synced 2026-08-15 17:43:13 +00:00
ab7e777e55
The server startup path built its Vault backend config field by field from the command-line struct, hardcoding VaultAuthMethod::Token and requiring a token. KmsConfig::from_env(), which already resolved AppRole and token-file auth plus namespace, TLS and mount settings, was never called outside tests, so those environment variables were silently dropped whenever RUSTFS_KMS_ENABLE=true and the documented AppRole / Vault Agent deployments could not start. Move the assembly into vault_kv2_config_from_env / vault_transit_config_from_env in the KMS crate and route both from_env() and init.rs through them, with the command line supplying only the values it owns. One implementation now serves both entry points, so they cannot drift apart again. On top of that, add VaultAuthMethod::Kubernetes: the pod's projected ServiceAccount token is exchanged for a lease-bound Vault token and renewed like AppRole. The token is re-read on every login because the kubelet rotates it, and the file mode is deliberately not checked since the kubelet mounts it world-readable. This removes the Vault Agent sidecar requirement on Kubernetes and leaves no credential to distribute. VaultCliOverrides deliberately does not derive Debug: it carries the raw token, so denying the derive turns a future interpolation into a compile error.