在使用Azure Key Vault配置提供程序的机密/配置时使用诸如Bind和GetConnectionString之类的IConfiguration方法

Question

因此，我们正在将下一代产品堆栈转换为在Azure中运行（包括有角度的客户端层，Web API层，一组用于后端处理和Azure sql数据库的Azure函数以及其他几个Azure PAAS）服务，例如流分析，事件网格，Azure表，Blob等）。

第一步是在ASP.NET Core中完全支持DI。下一步是将我们的配置模型从使用appsettings.json迁移到使用Azure Key Vault进行任何包含机密设置或需要由其他Azure服务使用的设置（可能共享中间层程序包并且需要连接字符串，机密和其他共享配置） （即单一来源的配置）。

该策略是将Azure Key Vault配置提供程序与托管服务标识一起使用。我们认为我们可以通过在Key Vault中的配置节名称对其进行键入（其中秘密值为复制和粘贴的JSON）来将appsettings.json中的大多数候选配置节“提升并转移”为Azure Key Vault中的秘密。从appsettings.json到Key Vault中的秘密值，而无需任何其他代码更改。

我们希望这样做的话，我们将能够完全像存储在appsettings.json中一样使用键库中的节。我们的配置对象不是简单的1：1 key：value对，而是实际上是强类型的实体。使用appsettings.json可以使用IConfiguration.Bind调用或在连接字符串IConfiguration.GetConnectionString调用的情况下正常工作。同样，对于services.Configure<T>(Configuration.GetSection("SectionName"))调用，需要为IOptions支持注册配置节。

在完成此过程后，我们发现，当尝试使用Key Vault中包含JSON的配置节时，我们无法按原样使用IConfiguration.Bind和IConfiguration.GetConnectionString方法，因为它们似乎并没有识别返回为JSON的值，因此除非我们进行类似JsonConvert.DeserializeObject<T>(Configuration.GetSection("SectionName").Value)

的操作，否则不要绑定

这导致我们的services.Configure<T>(Configuration.GetSection("SectionName"));看起来更像这样...

services.Configure<T>(options =>
            {
                var config = JsonConvert.DeserializeObject<T>(Configuration.GetSection("ConfigTypeName").Value);
                options.Property = config.Property;
            });

这行得通，但是感觉像是代码的味道...现在，任何时候我们需要扩展ConfigType时，我们还必须确保更新Startup.cs中的代码，以确保services.Configure<T>调用将全部复制通过options =>覆盖属性。这也意味着我们的启动代码需要知道配置属性是否来自密钥库或appsettings.json

问题是我们做错了吗？我们还有其他方法可以解决这个问题吗？显然，Azure密钥保管库配置提供程序在理论上应该像任何其他提供程序（例如appsettings.json的文件提供程序）一样工作。很高兴发现我们在这里遗漏了一些明显的东西，并很好奇地发现了为什么它似乎“应该看起来”不起作用。