Azure Key Vault Secrets是否主要用于VM等，而不是Azure Functions和WebJobs？
似乎在这两个开发中都增加了一个额外的步骤（更新Key Vault中的Secret和Secret Identifier）。应用程序设置）和运行时的额外步骤（从Key Vault进行的其他检索），唯一的好处是应用程序设置中的密码是标识符而不是实际密码。我看不到安全性的好处，但有损。
#1 楼
我看到的好处是使用Azure Key Vault的一般原因秘密集中存储有授权，审核等选项。
Azure可以编写脚本以进行更新计时器上的机密-因此，如果连接字符串被不正确的人使用，它仅在一天（或一周，或任何其他时间）内有效。
如果机密在多个应用程序之间共享，则仅必须将其更新到一个位置（不是最大的好处，但仍然不错）
评论
在我看来，您是在说密钥库仅在多个应用服务器共享同一秘密时才有用。如果连接字符串由单个应用程序服务器使用，则密钥库没有任何优势。
–约翰·亨克尔（John Henckel）
18/12/13在19:34
#2 楼
我和您有相同的看法，在这种情况下使用Key Vault是没有意义的。相反，我使用Azure应用程序配置https://docs.microsoft.com/zh-cn/azure / azure-app-configuration / overview，我只在其中存储所有应用程序设置。
和我一起存储在实际应用程序服务/ func / Web作业中的唯一字符串是用于访问Azure应用程序配置的连接字符串。
在我的启动环境中，配置设置为如果应用，则从..settings.json中读取，如果不存在（如果在Azure上运行，则不应该存在），我会寻找与Azure应用配置的连接字符串。
如果..找到settings.json，这意味着我在本地运行。
..settings.json如果不在gitignore文件中，则会被加密。
看起来像这样：
var appConfigEndpoint = Environment.GetEnvironmentVariable("AppConfigEndpoint");
var appConfigLabel = Environment.GetEnvironmentVariable("AppConfigLabel");
if (!string.IsNullOrEmpty(appConfigEndpoint))
{
config.AddAzureAppConfiguration(options =>
{
options.Connect(appConfigEndpoint);
options.Use(keyFilter: "*", labelFilter: appConfigLabel);
});
}
else
{
config.AddJsonFile("appsettings.test.json", optional: false);
}
评论
我为时已晚，但是如果您仍然有相同的意见，则必须更改它。配置（您的参考资料）不是存储机密，而是存储配置。数据库连接字符串是一个秘密而不是配置。 KeyVault用于存储机密，Configuration用于将配置存储在集中存储中。我希望这是有道理的
–RAM
19/12/2在9:27
#3 楼
密钥库检索可能是性能问题。从密钥库读取需要几秒钟。 Azure SLA仅表示将花费不到5秒的99.9％的时间。它不能保证平均时间，但是根据我的经验和传闻，平均时间大约为2秒。除非您的Web应用程序“始终处于运行状态”，否则如果空闲5-20分钟，它将被卸载。分钟。这意味着，除非您的流量很大，否则您的站点响应时间会很糟糕。
评论
在应用程序启动期间，您一次即可获取大多数应用程序机密。
– Miroslav Holec
19年1月29日在12:51
#4 楼
我们计划在下方使用秘密-Azure Key-Vault
始终加密列的主密钥旋转
证书存储（可以轻松地编写一个.NET中的提供程序）
连接之类的敏感项目
字符串（隐藏其他资源信息），密码等。
配置-Azure应用配置（仍在预览中）
监视是一种发现服务的绝妙方法，特别是如果您
需要更新标志或值以用于运营用途。
无需重新启动容器或实例。
评论
如果在github上出现错误时提供公共数据库连接字符串，那就太酷了：）（如果真的需要原因的话）我不知道怎么回事。我说的是在“应用程序设置”中有连接字符串，该字符串存储在云中，并且永远不会触及代码库。
只要在gui交互中一切都可以在云中完成，就转移到纯IaC，其中所有云配置都以代码形式完成，并且这种情况将有一天发生，这就是使用保管库的主要原因。如果您认为没有必要，请不要使用它。
是的，只是秘密标识符似乎和数据库连接字符串一样安全/不安全。您要么需要更改，要么都不需要更改。
嗯..并非如此，例如，在应用程序设置中引用的名为“ DB_Cx_String”的问题要比“ jdbc：// host：port / DBname”的问题少。