Question

我们已经偏离了公司的Microsoft标准环境设置。

我们有以下环境

本地-用于以基础结构作为容器运行的docker compose文件进行本地设计的环境
开发-3rd Party Teams的集成环境，我们将api连接到他们正在研究的前端。不稳定，因为集成环境应该是
分期-为利益相关者提供更稳定的环境进行审核

我们的Startup.cs类看起来像这样

    public void ConfigureLocalServices(IServiceCollection services)
    {
        services
            .AddApplicationServices(Configuration)
            .AddLocalIntegrationEvents(Configuration)
            .AddLocalLogging(Configuration);
    }

    public void ConfigureDevelopmentServices(IServiceCollection services)
    {
        services
            .AddApplicationServices(Configuration)
            .AddDevelopmentLogging(Configuration)
            .AddDevelopmentIntegrationEvents(Configuration);
    }

如您所见，它很漂亮，很整洁，我们根据环境配置应用程序。

现在解决我们的问题-由于默认的Web构建器仅在环境为“开发”时才添加用户密码（据我了解，如果在本地工作，则应使用默认环境），因此我们遇到了运行时异常的问题却未加载红est HTTPS证书，因为此机密是现在缺少"Kestrel:Certificates:Development:Password": "100e0e22-09ea-40e4-bef9-469289bf8786"。

我已经暂时解决了这个问题

        public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .ConfigureAppConfiguration((hostingContext, config) =>
            {
                //Load in secrets if environment is local as well to get our HTTPS certs loaded correctly
                if (hostingContext.HostingEnvironment.EnvironmentName.Equals("Local", StringComparison.InvariantCultureIgnoreCase))
                    config.AddUserSecrets<Startup>();

            })
             .UseStartup<Startup>()
             .UseSerilog();

尽管有些开发人员设置了秘密，但这些秘密是针对另一个环境的，这会在运行时引起更多问题。

据我了解，机密文件不是特定于环境的，因此我们无法添加“本地机密”。

为我们解决此问题的最佳方法是什么？我们的方法完全不正确吗？

Answer 1

用户机密仅用于本地开发。这就是为什么它们默认仅在环境设置为Development时处于活动状态的原因。

这也是您需要使用变通方法的原因：

.ConfigureAppConfiguration((hostingContext, config) =>
            {
                //Load in secrets if environment is local as well to get our HTTPS certs loaded correctly
                if (hostingContext.HostingEnvironment.EnvironmentName.Equals("Local", StringComparison.InvariantCultureIgnoreCase))
                    config.AddUserSecrets<Startup>();

            })

解决方法：每个环境的用户机密

一种解决方法是拥有多个秘密文件GUID，并根据您的环境将此重载用于不同的GUID：

var env = hostingContext.HostingEnvironment.EnvironmentName;
if(env == 'Local')
  config.AddUserSecrets(new Guid("00000000-0000-0000-0000-000000000000").ToString());
if(env == 'Development')
  config.AddUserSecrets(new Guid("11111111-1111-1111-1111-111111111111").ToString());

注意：如果您执行此操作，则在单击Manage User Secrets时，Visual Studio中的上下文菜单可能无法显示正确的文件。

代替找到此目录：
C:\Users\<USER>\AppData\Roaming\Microsoft\UserSecrets
在该目录中，使用与您上面使用的相同的GUID创建目录（如果尚不存在）。然后添加一个secrets.json文件，如下所示：

替代1：不同的配置提供程序

但是，既然听起来您也想在开发人员之间共享秘密。您可以使用其他配置提供程序。

例如，此处概述的Azure Key Vault provider：
https://docs.microsoft.com/en-us/aspnet/core/security/key-vault-configuration?view=aspnetcore-3.1

这允许管理云中的所有秘密，而无需通过即时消息等发送它们。

替代2：自定义配置提供程序

如果您不喜欢azure，可以使用提供程序对其他服务执行相同的操作，或者如果它们都不适合您，则可以创建一个满足您需求的自定义服务。

这是一篇博客文章，记录了如何做到这一点：
https://codeburst.io/create-a-custom-configuration-provider-in-asp-net-core-cdd6a32b8ecb

ASP .Net核心机密问题中的自定义环境

1 个答案:

解决方法：每个环境的用户机密

替代1：不同的配置提供程序

替代2：自定义配置提供程序