如何在Azure Key Vault中实现类似HashiCorp Vault的分层数据存储？

我来分享几个实用的方案，帮你在Azure Key Vault的扁平结构限制下，实现类似HashiCorp Vault的分层数据存储与访问体验：

方案1：前缀命名+过滤检索（最接近路径式访问） #

虽然Azure Key Vault底层是扁平结构，但你可以通过统一的前缀命名规范模拟层级路径，比如直接用AppName/Prod/Data/TestConnection作为密钥名称。这种命名方式完全贴合你想要的路径格式，检索时可以通过前缀过滤来获取整个层级的密钥：

• 使用Azure CLI批量获取某层级的密钥：

  az keyvault secret list --vault-name your-vault-name --query "[?starts_with(name, 'AppName/Prod/Data/')]"
  

• 在.NET中直接通过完整"路径"获取单个密钥：

  var client = new SecretClient(new Uri("https://your-vault.vault.azure.net/"), new DefaultAzureCredential());
  var secret = await client.GetSecretAsync("AppName/Prod/Data/TestConnection");
  

这个方案的优势是密钥粒度细，每个秘密独立管理，完全模拟HashiCorp Vault的路径访问逻辑，唯一的小缺点是密钥数量会随层级节点增多而增加，但管理起来依然清晰。

方案2：存储结构化JSON密钥（集中式管理） #

这也是你目前考虑的方向，把整个应用/环境的分层配置打包成一个JSON字符串，存储为单个密钥。比如创建名为AppName-Prod-Config的密钥，值为：

{
  "Prod": {
    "Data": {
      "TestConnection": "your-connection-string",
      "OtherSecret": "another-secret-value"
    }
  }
}

在.NET Core中，你可以通过自定义配置逻辑解析这个JSON，让它直接融入配置系统：

var builder = new ConfigurationBuilder();
builder.AddAzureKeyVault(
    new Uri("https://your-vault.vault.azure.net/"),
    new DefaultAzureCredential(),
    new CustomKeyVaultSecretManager());

// 自定义密钥管理器类
public class CustomKeyVaultSecretManager : KeyVaultSecretManager
{
    public override bool Load(SecretProperties properties) => true;

    public override IEnumerable<string> GetKey(KeyVaultSecret secret)
    {
        if (secret.Name == "AppName-Prod-Config")
        {
            // 解析JSON并生成分层配置键
            var configDict = JsonSerializer.Deserialize<Dictionary<string, object>>(secret.Value);
            return FlattenConfig(configDict).Select(kv => kv.Key);
        }
        return base.GetKey(secret);
    }

    private IEnumerable<KeyValuePair<string, object>> FlattenConfig(Dictionary<string, object> config, string parentKey = "")
    {
        foreach (var kv in config)
        {
            var currentKey = string.IsNullOrEmpty(parentKey) ? kv.Key : $"{parentKey}:{kv.Key}";
            if (kv.Value is Dictionary<string, object> nestedDict)
            {
                foreach (var nestedKv in FlattenConfig(nestedDict, currentKey))
                {
                    yield return nestedKv;
                }
            }
            else
            {
                yield return new KeyValuePair<string, object>(currentKey, kv.Value);
            }
        }
    }
}

之后就能像访问普通分层配置一样获取值：configuration["Prod:Data:TestConnection"]

这个方案的好处是密钥数量少，管理集中，但要注意Azure Key Vault单个秘密的大小限制（最大25KB），如果配置内容过大，需要拆分多个JSON密钥按层级存储。

方案3：RBAC权限隔离+前缀命名（安全维度的分层） #

结合Azure RBAC的权限控制，给不同应用/环境的服务分配仅能访问对应层级密钥的权限。比如：

• 给AppName的Prod服务分配权限，仅允许访问前缀为AppName/Prod/*的密钥
• 给Test服务分配权限，仅允许访问前缀为AppName/Test/*的密钥

这种方式从安全层面实现了分层隔离，即使密钥是扁平存储，不同服务也只能看到自己权限范围内的"层级"密钥，适合多团队、多环境的复杂场景。

补充：复用.NET Core的--分隔命名 #

你之前提到的MySettings--SomeSection--SecretThing命名方式，其实.NET Core配置系统原生支持将其解析为MySettings:SomeSection:SecretThing的分层结构。如果团队能接受这种命名风格，不需要额外开发就能直接实现分层配置的读取，也是一种低成本的解决方案。

内容的提问来源于stack exchange，提问作者Tab