RustFS KMS 开发与测试指南后端矩阵、Vault 测试通道与 Local 密钥导出实战【免费下载链接】rustfs2.3x faster than MinIO for 4KB object payloads. RustFS is an open-source, S3-compatible high-performance object storage system supporting migration and coexistence with other S3-compatible platforms such as MinIO and Ceph.项目地址: https://gitcode.com/GitHub_Trending/rus/rustfsRustFS 的密钥管理服务KMS位于 crates/kmscrate 名rustfs-kms负责主密钥Master Key、数据加密密钥DEK的生成、存储与对象加密并支撑 SSE-S3、SSE-KMS、SSE-C 三种服务端加密模式。本文以该目录下的 AGENTS.md 为核心骨架结合仓库源码与管理 API系统讲解 KMS 的变更协调范围、安全红线、本地端到端测试、黑盒行为测试套件与 Vault 测试通道以及面向 SSE-S3 迁移场景的 Local 密钥导出方法帮助开发者在修改密钥管理行为时保持兼容性并正确驱动仅由 Vault 后端提供的轮换rotation与版本化versioning能力测试。一、适用范围与变更协调改 KMS 前必须核对的下游crates/kms/AGENTS.md开篇即声明其适用范围为crates/kms/目录并给出了修改密钥管理行为时的强制兼容性核对清单rustfs/src/storage/ecfs.rs —— 存储层的加密文件系统路径是 KMS 加密服务的主要消费方rustfs/src/admin/handlers/kms.rs —— KMS 基础管理接口rustfs/src/admin/handlers/kms_dynamic.rs —— KMS 动态配置接口rustfs/src/admin/handlers/kms_keys.rs —— 密钥生命周期创建、列表、删除等接口rustfs/src/admin/handlers/kms_management.rs —— KMS 管理路由注册与状态查询。从源码结构看rustfs-kms是一个通过KmsServiceManager暴露全局单例的独立 cratelib.rs 提供init_global_kms_service_manager、get_global_encryption_service等入口管理 API 与存储层都经由这些全局入口获得加密服务实例。例如存储侧在 rustfs/src/storage/runtime_sources.rs 通过current_encryption_service()解析最新的ObjectEncryptionService管理侧在 rustfs/src/admin/handlers/kms_management.rs 注册了POST /v3/kms/create-key、GET /v3/kms/describe-key、GET /v3/kms/list-keys、POST /v3/kms/generate-data-key、GET|POST /v3/kms/status、GET /v3/kms/config、POST /v3/kms/clear-cache等路由。因此任何对外行为错误变体、返回字段、状态语义的调整都会波及管理 API 与对象读写路径变更前应以上述文件为回归基线。二、安全红线明文密钥与错误路径AGENTS.md 明确了两条不可妥协的安全约束绝不记录明文密钥不得将明文密钥、密钥材料或敏感请求载荷写入日志。这一点在源码中有系统化落实——config.rs 定义了KMS_CONFIG_REDACTION_RULES将kms.local.master_key、kms.vault.token、kms.vault.approle.secret_id、kms.static.secret_key等字段标记为RedactionLevel::Secret并在Debug实现中以***redacted***脱敏见redacted_secret/redacted_secret_option。优先显式错误传播而非 panic 路径KMS 的错误体系集中在 error.rs以KmsError枚举承载UnsupportedCapability、KeyNotFound、MaterialAuthenticationFailed、ContextMismatch、InvalidKeyState等具名错误变体。同时 lib.rs 首行#![deny(clippy::unwrap_used)]从 lint 层面强制代码库避免直接unwrap配合zeroize::Zeroizing对密钥材料的内存擦除如 local_kms_key_decrypt.rs 中的Zeroizing::new(...)形成错误显式、密钥不留痕的双重保障。三、本地 KMS 端到端测试代理旁路与单线程约束AGENTS.md 提供了本地 KMS 端到端测试的标准命令NO_PROXY127.0.0.1,localhost HTTP_PROXY HTTPS_PROXY http_proxy https_proxy \ cargo test --package e2e_test test_local_kms_end_to_end -- --nocapture --test-threads1要点如下代理旁路测试会启动 RustFS 本地进程并通过127.0.0.1访问其管理/对象接口因此必须同时清空大写与小写的HTTP_PROXY/HTTPS_PROXY并设置NO_PROXY127.0.0.1,localhost否则流量会被环境代理截走导致连接失败。--test-threads1串行执行避免多个测试进程争用同一端口或同一本地密钥目录。该测试位于 crates/e2e_test/src/kms/kms_local_test.rs通过LocalKMSTestEnvironment以--kms-backend local自动拉起 RustFS覆盖动态配置 API、SSE-C/SSE-S3/SSE-KMS 上传下载、密钥生命周期管理更完整的套件说明见 crates/e2e_test/src/kms/README.md。四、黑盒行为测试套件从公开入口驱动 cratecrates/kms/tests/behavior_*.rs如 behavior_rotation.rs、behavior_keys.rs、behavior_serde.rs、behavior_backup.rs等构成 KMS 的黑盒行为套件。其共享 harness 在 crates/kms/tests/common/mod.rs 中实现遵守两条纪律只通过 crate 的公开入口KmsServiceManager - KmsManager / ObjectEncryptionService驱动不触碰pub(crate)内部实现不解析磁盘密钥格式断言只针对可观察契约——错误变体、返回值、以及重启后依然成立的状态——绝不针对实现细节。该 harness 为每个测试实例持有独立的KmsServiceManager刻意回避进程级全局单例以避免 nextest 并行执行时测试间串扰。默认情况下套件只运行Local与Static两个后端for_each_backend矩阵因为两者无需外部依赖即可启动。五、Vault 测试通道把 KV2 与 Transit 后端加入矩阵设置环境变量RUSTFS_KMS_VAULT_TOKEN后Vault KV2 与 Vault Transit 后端会被加入每一个for_each_backend规格连接实时 Vault 服务器地址由RUSTFS_KMS_VAULT_ADDR指定默认http://127.0.0.1:8200NO_PROXY127.0.0.1,localhost HTTP_PROXY HTTPS_PROXY http_proxy https_proxy \ RUSTFS_KMS_VAULT_TOKENdev-token cargo test -p rustfs-kms服务器需要满足与 crate 配置默认值一致的两个引擎KV v2 引擎挂载在secret/对应DEFAULT_VAULT_TRANSIT_METADATA_KV_MOUNT secret见 config.rsTransit 引擎挂载在transit/注意KV2 后端配置里的mount_path字段默认值也是transit但该字段是遗留字段KV2 后端实际不调用 Transit 引擎仅为保证旧配置可反序列化而保留见 config.rs。与后端的真实调用方式可从源码得到印证Vault 后端通过vaultrs/reqwest(rustls)访问 Vault APITransit 后端的rewrap_data_key针对带上下文绑定的信封走解密 重新加密携带关联数据路径见 vault_transit.rs 的注释AWS 后端则通过aws-sdk-kms访问凭据走标准aws-configprovider chain环境变量、共享配置文件、IMDS/容器角色crate 本身不接触 AWS 凭据材料见 Cargo.toml。5.1 为什么轮换/版本化测试必须开 Vault 通道AGENTS.md 特别强调每当你改动轮换或版本化逻辑时务必运行 Vault 通道。原因在 behavior_rotation.rs 的文档注释与代码中写得很清楚BackendCapabilities::rotate与versioning只有 Vault 后端KV2 与 Transit会声明。Local 后端的capabilities()刻意不开启 rotate/versioning见 local.rs注释说明在历史密钥版本可保留之前轮换保持不宣告Static 后端更是只保留minimal()见 static_kms.rs。因此若不开 Vault 通道behavior_rotation.rs中所有能力门控分支都会走UnsupportedCapability一侧永远不执行轮换后旧密文仍可解密这一核心断言——一个悄悄丢弃旧版本密钥材料的轮换也会测试通过绿灯而这会静默摧毁所有旧对象。对比各后端的能力矩阵见capabilities()实现能力LocalStaticVault KV2Vault TransitAWSencrypt / decrypt / generate_data_key✅✅✅✅✅rotate保留历史版本❌❌✅✅✅versioning❌❌✅✅✅enable_disable✅❌✅✅✅schedule_deletion / physical_delete✅❌✅✅仅 schedule窗口由 AWS 掌控update_key_metadata / rewrap✅❌✅✅未宣告 rewrapproduction_supported❌❌✅✅✅上表可从 local.rs、static_kms.rs、vault.rs、vault_transit.rs、aws.rs 一一核实BackendCapabilities的保守默认minimal()与各能力位语义定义在 mod.rs。production_supported是一个显式定位声明Local/Static 将加密根保留在本地主机仅用于开发、测试与演示因此永远不为 true。5.2 Vault 测试通道的密钥清理纪律Vault 通道每次运行都会在唯一命名behavior-kv2-*、behavior-transit-*下创建真实密钥且不自动删除开发用 Vault 会随运行次数累积密钥。AGENTS.md 给出的清理指引是只删除能确认属于当前任务的精确密钥共享前缀不能证明归属必须保留其他运行创建的密钥模棱两可的密钥留给运维人员判断。Transit 类型密钥先允许删除再删除vault write transit/keys/task-owned-transit-key/config deletion_allowedtrue vault delete transit/keys/task-owned-transit-keyKV2 类型密钥vault kv metadata delete secret/rustfs/kms/keys/task-owned-kv2-key注意secret/rustfs/kms/keys/前缀与 config.rs 中VaultConfig::default()的key_path_prefix rustfs/kms/keys一致。六、Local 密钥导出为 SSE-S3 迁移测试准备RUSTFS_SSE_S3_MASTER_KEYSSE-S3 的迁移测试需要把 Local KMS 的 AES-256 主密钥以 base64 形式交给RUSTFS_SSE_S3_MASTER_KEY。AGENTS.md 给出的标准做法是使用只读示例程序local_kms_key_decryptexport RUSTFS_KMS_LOCAL_MASTER_KEYlocal-kms-at-rest-master-key export RUSTFS_SSE_S3_MASTER_KEY$( cargo run -q -p rustfs-kms --example local_kms_key_decrypt -- \ /absolute/path/to/key-id.key )细节与边界条件仅当密钥文件被加密存储时才需要RUSTFS_KMS_LOCAL_MASTER_KEY。对于plaintext-dev-only开发模式明文的 Local 密钥文件无需设置该变量——这正对应LocalConfig中master_key: OptionString的语义与allow_insecure_dev_defaults开关见 config.rs。输出纪律示例只把 base64 编码的 32 字节密钥写到 stdout所有诊断信息走 stderr见 local_kms_key_decrypt.rs。严禁把其输出粘贴进日志、shell 历史、issue 评论或提交的配置文件中导出路径必须保持只读。实现一致性示例通过LocalKmsClient::new_for_key_export(LocalConfig { key_dir, master_key, file_permissions: Some(0o600), ... })与decrypt_key_material_for_export(key_id)复用与后端相同的LocalKmsClient解码路径因此当前 Argon2id 派生与旧版密钥文件格式的兼容性始终与后端保持一致——这一点对应 local.rs 中编译期固定的 KDF 参数LOCAL_KMS_MASTER_KEY_SALT_LEN 16、LOCAL_KMS_MASTER_KEY_LEN 32、Argon2idM19*1024 KiB、T2、P1。入参校验示例要求传入文件必须是.key扩展名且从文件名 stem 解析 key idresolve_key_file含单元测试覆盖非.key扩展名的拒绝路径。导出后的RUSTFS_SSE_S3_MASTER_KEY由 SSE-S3 路径消费在 rustfs/src/storage/sse.rs 中当 KMS 未配置时SSE-S3 要求该变量是合法的 base64 编码 32 字节密钥否则报出SSE-S3 requires RUSTFS_SSE_S3_MASTER_KEY ...的显式错误相关迁移/复制场景在 rustfs/src/app/multipart_usecase.rs、rustfs/src/app/object/on_demand_migration_put.rs 的测试中均有使用。七、相关示例与进一步探索除local_kms_key_decrypt外crates/kms/examples 还提供了kms_local_demo.rs —— Local 后端全流程演示初始化全局服务管理器、配置、启动、创建主密钥、生成 DEK、加解密与缓存统计kms_vault_kv_demo.rs —— Vault KV2 后端演示kms_dr_drill.rs —— 灾备演练与crates/kms/src/backup/模块的本地导出/恢复、清单与干跑能力配套。若需修改 KMS 行为请严格遵循第三节的兼容性清单回归 rustfs/src/storage/ecfs.rs 与四个 admin handler并至少运行一次带RUSTFS_KMS_VAULT_TOKEN的完整黑盒套件确保轮换与版本化这类破坏即静默丢数据的能力始终处于被真实断言覆盖的状态。【免费下载链接】rustfs2.3x faster than MinIO for 4KB object payloads. RustFS is an open-source, S3-compatible high-performance object storage system supporting migration and coexistence with other S3-compatible platforms such as MinIO and Ceph.项目地址: https://gitcode.com/GitHub_Trending/rus/rustfs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 RustFS KMS 开发与测试指南：后端矩阵、Vault 测试通道与 Local 密钥导出实战
RustFS KMS 开发与测试指南后端矩阵、Vault 测试通道与 Local 密钥导出实战【免费下载链接】rustfs2.3x faster than MinIO for 4KB object payloads. RustFS is an open-source, S3-compatible high-performance object storage system supporting migration and coexistence with other S3-compatible platforms such as MinIO and Ceph.项目地址: https://gitcode.com/GitHub_Trending/rus/rustfsRustFS 的密钥管理服务KMS位于 crates/kmscrate 名rustfs-kms负责主密钥Master Key、数据加密密钥DEK的生成、存储与对象加密并支撑 SSE-S3、SSE-KMS、SSE-C 三种服务端加密模式。本文以该目录下的 AGENTS.md 为核心骨架结合仓库源码与管理 API系统讲解 KMS 的变更协调范围、安全红线、本地端到端测试、黑盒行为测试套件与 Vault 测试通道以及面向 SSE-S3 迁移场景的 Local 密钥导出方法帮助开发者在修改密钥管理行为时保持兼容性并正确驱动仅由 Vault 后端提供的轮换rotation与版本化versioning能力测试。一、适用范围与变更协调改 KMS 前必须核对的下游crates/kms/AGENTS.md开篇即声明其适用范围为crates/kms/目录并给出了修改密钥管理行为时的强制兼容性核对清单rustfs/src/storage/ecfs.rs —— 存储层的加密文件系统路径是 KMS 加密服务的主要消费方rustfs/src/admin/handlers/kms.rs —— KMS 基础管理接口rustfs/src/admin/handlers/kms_dynamic.rs —— KMS 动态配置接口rustfs/src/admin/handlers/kms_keys.rs —— 密钥生命周期创建、列表、删除等接口rustfs/src/admin/handlers/kms_management.rs —— KMS 管理路由注册与状态查询。从源码结构看rustfs-kms是一个通过KmsServiceManager暴露全局单例的独立 cratelib.rs 提供init_global_kms_service_manager、get_global_encryption_service等入口管理 API 与存储层都经由这些全局入口获得加密服务实例。例如存储侧在 rustfs/src/storage/runtime_sources.rs 通过current_encryption_service()解析最新的ObjectEncryptionService管理侧在 rustfs/src/admin/handlers/kms_management.rs 注册了POST /v3/kms/create-key、GET /v3/kms/describe-key、GET /v3/kms/list-keys、POST /v3/kms/generate-data-key、GET|POST /v3/kms/status、GET /v3/kms/config、POST /v3/kms/clear-cache等路由。因此任何对外行为错误变体、返回字段、状态语义的调整都会波及管理 API 与对象读写路径变更前应以上述文件为回归基线。二、安全红线明文密钥与错误路径AGENTS.md 明确了两条不可妥协的安全约束绝不记录明文密钥不得将明文密钥、密钥材料或敏感请求载荷写入日志。这一点在源码中有系统化落实——config.rs 定义了KMS_CONFIG_REDACTION_RULES将kms.local.master_key、kms.vault.token、kms.vault.approle.secret_id、kms.static.secret_key等字段标记为RedactionLevel::Secret并在Debug实现中以***redacted***脱敏见redacted_secret/redacted_secret_option。优先显式错误传播而非 panic 路径KMS 的错误体系集中在 error.rs以KmsError枚举承载UnsupportedCapability、KeyNotFound、MaterialAuthenticationFailed、ContextMismatch、InvalidKeyState等具名错误变体。同时 lib.rs 首行#![deny(clippy::unwrap_used)]从 lint 层面强制代码库避免直接unwrap配合zeroize::Zeroizing对密钥材料的内存擦除如 local_kms_key_decrypt.rs 中的Zeroizing::new(...)形成错误显式、密钥不留痕的双重保障。三、本地 KMS 端到端测试代理旁路与单线程约束AGENTS.md 提供了本地 KMS 端到端测试的标准命令NO_PROXY127.0.0.1,localhost HTTP_PROXY HTTPS_PROXY http_proxy https_proxy \ cargo test --package e2e_test test_local_kms_end_to_end -- --nocapture --test-threads1要点如下代理旁路测试会启动 RustFS 本地进程并通过127.0.0.1访问其管理/对象接口因此必须同时清空大写与小写的HTTP_PROXY/HTTPS_PROXY并设置NO_PROXY127.0.0.1,localhost否则流量会被环境代理截走导致连接失败。--test-threads1串行执行避免多个测试进程争用同一端口或同一本地密钥目录。该测试位于 crates/e2e_test/src/kms/kms_local_test.rs通过LocalKMSTestEnvironment以--kms-backend local自动拉起 RustFS覆盖动态配置 API、SSE-C/SSE-S3/SSE-KMS 上传下载、密钥生命周期管理更完整的套件说明见 crates/e2e_test/src/kms/README.md。四、黑盒行为测试套件从公开入口驱动 cratecrates/kms/tests/behavior_*.rs如 behavior_rotation.rs、behavior_keys.rs、behavior_serde.rs、behavior_backup.rs等构成 KMS 的黑盒行为套件。其共享 harness 在 crates/kms/tests/common/mod.rs 中实现遵守两条纪律只通过 crate 的公开入口KmsServiceManager - KmsManager / ObjectEncryptionService驱动不触碰pub(crate)内部实现不解析磁盘密钥格式断言只针对可观察契约——错误变体、返回值、以及重启后依然成立的状态——绝不针对实现细节。该 harness 为每个测试实例持有独立的KmsServiceManager刻意回避进程级全局单例以避免 nextest 并行执行时测试间串扰。默认情况下套件只运行Local与Static两个后端for_each_backend矩阵因为两者无需外部依赖即可启动。五、Vault 测试通道把 KV2 与 Transit 后端加入矩阵设置环境变量RUSTFS_KMS_VAULT_TOKEN后Vault KV2 与 Vault Transit 后端会被加入每一个for_each_backend规格连接实时 Vault 服务器地址由RUSTFS_KMS_VAULT_ADDR指定默认http://127.0.0.1:8200NO_PROXY127.0.0.1,localhost HTTP_PROXY HTTPS_PROXY http_proxy https_proxy \ RUSTFS_KMS_VAULT_TOKENdev-token cargo test -p rustfs-kms服务器需要满足与 crate 配置默认值一致的两个引擎KV v2 引擎挂载在secret/对应DEFAULT_VAULT_TRANSIT_METADATA_KV_MOUNT secret见 config.rsTransit 引擎挂载在transit/注意KV2 后端配置里的mount_path字段默认值也是transit但该字段是遗留字段KV2 后端实际不调用 Transit 引擎仅为保证旧配置可反序列化而保留见 config.rs。与后端的真实调用方式可从源码得到印证Vault 后端通过vaultrs/reqwest(rustls)访问 Vault APITransit 后端的rewrap_data_key针对带上下文绑定的信封走解密 重新加密携带关联数据路径见 vault_transit.rs 的注释AWS 后端则通过aws-sdk-kms访问凭据走标准aws-configprovider chain环境变量、共享配置文件、IMDS/容器角色crate 本身不接触 AWS 凭据材料见 Cargo.toml。5.1 为什么轮换/版本化测试必须开 Vault 通道AGENTS.md 特别强调每当你改动轮换或版本化逻辑时务必运行 Vault 通道。原因在 behavior_rotation.rs 的文档注释与代码中写得很清楚BackendCapabilities::rotate与versioning只有 Vault 后端KV2 与 Transit会声明。Local 后端的capabilities()刻意不开启 rotate/versioning见 local.rs注释说明在历史密钥版本可保留之前轮换保持不宣告Static 后端更是只保留minimal()见 static_kms.rs。因此若不开 Vault 通道behavior_rotation.rs中所有能力门控分支都会走UnsupportedCapability一侧永远不执行轮换后旧密文仍可解密这一核心断言——一个悄悄丢弃旧版本密钥材料的轮换也会测试通过绿灯而这会静默摧毁所有旧对象。对比各后端的能力矩阵见capabilities()实现能力LocalStaticVault KV2Vault TransitAWSencrypt / decrypt / generate_data_key✅✅✅✅✅rotate保留历史版本❌❌✅✅✅versioning❌❌✅✅✅enable_disable✅❌✅✅✅schedule_deletion / physical_delete✅❌✅✅仅 schedule窗口由 AWS 掌控update_key_metadata / rewrap✅❌✅✅未宣告 rewrapproduction_supported❌❌✅✅✅上表可从 local.rs、static_kms.rs、vault.rs、vault_transit.rs、aws.rs 一一核实BackendCapabilities的保守默认minimal()与各能力位语义定义在 mod.rs。production_supported是一个显式定位声明Local/Static 将加密根保留在本地主机仅用于开发、测试与演示因此永远不为 true。5.2 Vault 测试通道的密钥清理纪律Vault 通道每次运行都会在唯一命名behavior-kv2-*、behavior-transit-*下创建真实密钥且不自动删除开发用 Vault 会随运行次数累积密钥。AGENTS.md 给出的清理指引是只删除能确认属于当前任务的精确密钥共享前缀不能证明归属必须保留其他运行创建的密钥模棱两可的密钥留给运维人员判断。Transit 类型密钥先允许删除再删除vault write transit/keys/task-owned-transit-key/config deletion_allowedtrue vault delete transit/keys/task-owned-transit-keyKV2 类型密钥vault kv metadata delete secret/rustfs/kms/keys/task-owned-kv2-key注意secret/rustfs/kms/keys/前缀与 config.rs 中VaultConfig::default()的key_path_prefix rustfs/kms/keys一致。六、Local 密钥导出为 SSE-S3 迁移测试准备RUSTFS_SSE_S3_MASTER_KEYSSE-S3 的迁移测试需要把 Local KMS 的 AES-256 主密钥以 base64 形式交给RUSTFS_SSE_S3_MASTER_KEY。AGENTS.md 给出的标准做法是使用只读示例程序local_kms_key_decryptexport RUSTFS_KMS_LOCAL_MASTER_KEYlocal-kms-at-rest-master-key export RUSTFS_SSE_S3_MASTER_KEY$( cargo run -q -p rustfs-kms --example local_kms_key_decrypt -- \ /absolute/path/to/key-id.key )细节与边界条件仅当密钥文件被加密存储时才需要RUSTFS_KMS_LOCAL_MASTER_KEY。对于plaintext-dev-only开发模式明文的 Local 密钥文件无需设置该变量——这正对应LocalConfig中master_key: OptionString的语义与allow_insecure_dev_defaults开关见 config.rs。输出纪律示例只把 base64 编码的 32 字节密钥写到 stdout所有诊断信息走 stderr见 local_kms_key_decrypt.rs。严禁把其输出粘贴进日志、shell 历史、issue 评论或提交的配置文件中导出路径必须保持只读。实现一致性示例通过LocalKmsClient::new_for_key_export(LocalConfig { key_dir, master_key, file_permissions: Some(0o600), ... })与decrypt_key_material_for_export(key_id)复用与后端相同的LocalKmsClient解码路径因此当前 Argon2id 派生与旧版密钥文件格式的兼容性始终与后端保持一致——这一点对应 local.rs 中编译期固定的 KDF 参数LOCAL_KMS_MASTER_KEY_SALT_LEN 16、LOCAL_KMS_MASTER_KEY_LEN 32、Argon2idM19*1024 KiB、T2、P1。入参校验示例要求传入文件必须是.key扩展名且从文件名 stem 解析 key idresolve_key_file含单元测试覆盖非.key扩展名的拒绝路径。导出后的RUSTFS_SSE_S3_MASTER_KEY由 SSE-S3 路径消费在 rustfs/src/storage/sse.rs 中当 KMS 未配置时SSE-S3 要求该变量是合法的 base64 编码 32 字节密钥否则报出SSE-S3 requires RUSTFS_SSE_S3_MASTER_KEY ...的显式错误相关迁移/复制场景在 rustfs/src/app/multipart_usecase.rs、rustfs/src/app/object/on_demand_migration_put.rs 的测试中均有使用。七、相关示例与进一步探索除local_kms_key_decrypt外crates/kms/examples 还提供了kms_local_demo.rs —— Local 后端全流程演示初始化全局服务管理器、配置、启动、创建主密钥、生成 DEK、加解密与缓存统计kms_vault_kv_demo.rs —— Vault KV2 后端演示kms_dr_drill.rs —— 灾备演练与crates/kms/src/backup/模块的本地导出/恢复、清单与干跑能力配套。若需修改 KMS 行为请严格遵循第三节的兼容性清单回归 rustfs/src/storage/ecfs.rs 与四个 admin handler并至少运行一次带RUSTFS_KMS_VAULT_TOKEN的完整黑盒套件确保轮换与版本化这类破坏即静默丢数据的能力始终处于被真实断言覆盖的状态。【免费下载链接】rustfs2.3x faster than MinIO for 4KB object payloads. RustFS is an open-source, S3-compatible high-performance object storage system supporting migration and coexistence with other S3-compatible platforms such as MinIO and Ceph.项目地址: https://gitcode.com/GitHub_Trending/rus/rustfs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考