xand-secrets

本仓库包含一个核心特质 SecretKeyValueStore，它提供了一种从集中式密钥存储读取密钥并检查其健康状态的简单接口。公开的API旨在关注各种实现之间的共性；密钥通过单个字符串键索引。

此接口 不 支持在存储中填充或更新密钥；其管理留给了外部工具。

预期结构和用法

密钥存储旨在安全地存储API令牌、客户端证书或其他类似密钥，这些密钥旨在保持私密。典型用例是与第三方交互，尽管此概念也可应用于两个TPFS应用程序之间的交互。

用户预期将可以使用任何必要的身份验证来向他们选择的密钥存储发送请求，以及相关的连接细节。他们首先使用客户端（实现SecretKeyValueStore）从存储中检索密钥，然后使用返回的密钥向外部服务发出请求。目的是，托管应用程序 不 在发出上游请求后存储或缓存返回的密钥。

以下图表说明了此过程，包括假设的Kubernetes部署及其在密钥存储请求中的作用。此部署模式 不是 使用此crate所必需的，但几乎任何实例的宿主应用程序都需要通过某种方式提供密钥存储凭据。

可编辑源

用法

所有适配器都在各自的隔离crates中，没有用于创建它们的中央API。通常，应用程序会将密钥存储选择作为配置参数暴露给用户和/或应用程序管理员。

例如，反序列化的配置输入可能如下所示

pub enum SecretStoreConfig {
    Vault(VaultConfiguration),
    KeyVault(KeyVaultConfiguration),
    LocalFile(LocalFileSecretStoreConfiguration),
}

截至撰写本文时，现有的适配器都声明了一个*Configuration结构，在创建时作为参数传递，但这不是固有要求的。

一旦加载了SecretStoreConfig，应用程序就可以使用每个crate的独立API创建适当的存储。

match &configuration.secret_store {
    SecretStoreConfig::Vault(config) => Ok(Arc::new(
        VaultSecretKeyValueStore::create_from_config(config.clone())?,
    )),
    SecretStoreConfig::KeyVault(config) => Ok(Arc::new(
        KeyVaultSecretKeyValueStore::create_from_config(config.clone()),
    )),
    SecretStoreConfig::LocalFile(config) => Ok(Arc::new(
        LocalFileSecretKeyValueStore::create_from_config(config.clone()),
    )),
}

可用的适配器

• HashiCorp Vault: https://gitlab.com/TransparentIncDevelopment/product/libs/xand-secrets-vault
• Azure Key Vault: https://gitlab.com/TransparentIncDevelopment/product/libs/xand-secrets-key-vault
• 本地、未加密文件：https://gitlab.com/TransparentIncDevelopment/product/libs/xand-secrets-local-file
  • 本地文件存储仅作为临时解决方案，如果可能的话应尽量避免使用。