.NET Core 的机密存储有据可查。
但是，在 .NET Core 世界中，我找不到一篇关于如何在团队之间共享此类信息的好文章。
例如，假设我们有一个 .NET Core 项目，该项目的信息存储在secrets.json中，并且有 10 个开发人员使用该项目。
我能想到的选项：
将某些内容签入源代码管理 - 似乎违背了重点(除了不意外地将测试设置发布到实时(。
只是在我们自己之间交谈 - 感觉如果有人添加了一个秘密并去度假，其他开发人员会浪费时间弄清楚缺少什么。如果两个开发人员同时添加某些内容，也可能会导致问题。
忽略
secrets.json并始终使用 Azure 密钥保管库 - 即使对于开发也是如此。更复杂的是，我还没有在任何地方看到这个推荐，但它也适用于在构建服务器上构建。缺点是 Vault 可能会被未使用的设置弄得乱七八糟，并且不清楚哪些设置需要在实时复制。
我可能错过了其他选择。
与其他开发人员共享/同步机密的最佳方式是什么？
编辑以下答案：
转到密钥保管库路由将起作用。如前所述，这需要额外的设置(例如，使用证书(。有关更多详细信息，请参阅Microsoft文档。
尽管这是有偏见的：选择 3，请使用密钥保管库。
<小时 />索赔人
有许多关于这个主题的博客文章和文档，在这里我将讨论问题范围的非常狭窄的部分。
另一种建议是或使用此处所述的 GitOps/SOPS 等方法。
至于 Vault 选项，它有一些好处，我将列举其中的一些：
- 机密存储在一个中心位置，使治理和轮换更容易
- 开发人员不知道机密，或者只是在需要知道的基础上，这使得它更安全
- 如果正确实现机密，则不是版本控制的一部分，这也使其更安全。
一些缺点
- 正确设置需要一些时间
- 它不太灵活，尤其是在流程尚未到位的情况下。
- 如果正确实现机密，则不是版本控制的一部分，这使得恢复更加困难。
详细说明最后一个：在某些情况下，您需要一个"稳定"且可恢复的机密，例如：当客户端需要以特定方式集成时，这需要您控制机密。尽管从安全角度来看，这不是最佳做法，但很常见。GitOps/SOPS 更适合这种情况。
一般来说，开发人员访问机密的次数越多，它就越不安全。
理想情况下，如果设置正确，则最终将在所有环境中以相同的方式处理此问题(测试，暂存产品(。最后，解决方案和工艺应独立于环境，以最大限度地提高生产稳定性。
但正如我所说;这是有偏见的，是基于意见的。