.Net Core 带有一个秘密管理工具，用于存储用于开发目的的秘密。如果我正确理解了文档，则不涉及加密，并且所有内容都以纯文本形式存储。
现在的问题是，如果我们可以从文件中读取，为什么要使用这种相对繁琐的方法，appsettings.secrets.json例如更容易使用和查看秘密并将其添加到 .gitignore 以便它永远不会出现在源代码管理中。
使用这种更简单的方法是否有任何我没有考虑过的安全问题？
PS我只能想到不小心提交秘密文件的危险，但除非你更改整个 .gitignore 文件，否则这并不容易
我想我应该把评论放在一个答案中。
主要问题是敏感数据不应使用与代码相同的分发渠道。这就是为什么 .gitignore 是不够的。您将使用相同的通道并依赖于正确处理任何用户都可以修改的 .gitignore 文件。出错的可能性永远存在。
这是否可以接受取决于机密的类型。这些数据有多敏感？如果它包含开发数据库的sa或sys密码，请不要使用该帐户。使用具有有限权限的单独帐户，这仅用于访问该数据库。丢失受限开发帐户的密码可能不是什么大问题。大概。
另一方面，如果它包含您的云开发/登台环境的 API 或帐户密钥，哎呀。它可能是一个临时环境，但仍然有人可以使用它们来启动虚拟机、创建帐户或窃取数据。
秘密工具的一大优势是它可以在配置架构中工作。对于应用程序来说，它只是另一个配置提供程序，可以根据例如环境变量或命令行选项使用或不使用。
它也不是唯一的选择，只是一种处理机密的便捷方式，尤其是在分布式或 OSS 开发环境中。还有其他选择：
在公司环境中，您可以将“秘密”文件放在只有团队成员具有读取权限的文件共享中，并通过另一个配置提供程序共享位置，例如通过环境变量。该文件可以通过安全组进行保护，这意味着添加/删除对其的访问权限将比添加/删除对单个文件的访问权限容易得多。您可以对文件共享启用审核，以查看谁也访问了机密文件。这是你不能做的事情.gitignore
您可以使用环境变量为每个环境选择不同的路径（开发、质量保证、构建服务器等）。
您甚至可以使用一个数据库，将不同的秘密返回给不同的角色/环境。毕竟，密钥管理系统可以看作是一个加密安全的设置数据库。
您还可以复制一些设置文件。您可以在 Linux 上使用 etcd 或在 Windows 上使用文件复制来做到这一点。这也是将设置更改传递到多个服务器/容器的一种方式。