.NET Core带有一个秘密管理工具，用于存储用于开发目的的秘密。如果我正确理解了文档，因此不涉及加密，所有内容都存储在纯文本中。
现在的问题是，如果我们只能从appsettings.secrets.json文件中读取，例如，我们为什么会使用这种相对繁琐的方法。这更容易使用并查看秘密并将其添加到.gitignore中，因此它永远不会出现在源控件中。
使用这种更简单的方法我没有考虑过任何安全问题？
P.S。我只能想到意外犯下秘密文件的危险，但是除非您更改整个.gitignore文件
我想我应该将评论放在一个答案中。
主要问题是，敏感数据不应使用与代码相同的分布通道。这就是为什么.gitignore还不够。您将使用非常相同的频道，并取决于对任何用户可以修改的.gitignore文件的正确处理。错误的可能性将永远存在。
这是否可以接受取决于秘密的类型。该数据有多敏感？如果它包含用于开发数据库的sa或sys密码，则不要使用该帐户。使用具有有限特权的单独帐户，这仅是为了访问该数据库。将密码丢给有限的开发帐户可能并不是一个大问题。大概。
另一方面，如果它包含了云开发/登台环境的API或帐户键，请糟糕。这可能是一个分阶段的环境，但仍然可以使用它们来启动VM，创建帐户或窃取数据。
秘密工具的最大优势是它在配置体系结构中起作用。在应用程序中，它只是可以使用或不根据环境变量或命令行选项使用或不使用的另一个配置提供商。
也不是选项，只是一种处理秘密的方便方式，尤其是在分布式或OSS开发环境中。还有其他选择：
在公司环境中，您可以在文件共享中放置一个"秘密"文件，其中只有团队成员可以通过另一个配置提供商进行读取并共享位置，例如通过环境变量。该文件可以通过安全组确定，这意味着添加/删除对其的访问要比添加/删除对单个文件的访问要容易得多。您可以在文件共享上启用审核，以查看谁也访问了秘密文件。这是您无法使用
.gitignore
做的事情您可以使用环境变量来选择每个环境（开发，QA，构建服务器等）的不同路径。
您甚至可以使用将不同秘密返回到不同角色/环境的数据库。钥匙管理系统毕竟可以看作是密码固定的设置数据库。
您还可以复制某些设置文件。您可以使用Linux上的ETCD或Windows上的文件复制来执行此操作。这也是将设置交付到多个服务器/容器的一种方法。