别再使用 .env 文件了！ - 哈喽比特

927次阅读 | 发布于2年以前

大家好！就我所知，99%的JavaScript教程都在说要使用.env进行生产环境的配置和加密，但是以我工作过大型企业系统的经验来看，这种行为是愚蠢的。

是时候纠正这种行为了。

那么，.env文件有什么问题呢？以及最终的解决方案是什么呢？让我们一起来探讨一下。

.env文件的问题

1.存储.env文件

首先，这是一个文件。不建议将“生产”文件存储在存储库中。放哪儿？直接放在VM根目录？还是Docker容器呢？会有密钥泄露的风险。

2.更新密钥配置

如果你需要更新数据库会发生什么？更新.env的人将有权访问文件中的每一个密钥。这我就不用解释有多糟糕了吧。每一次更新配置，更新的人都可以看到所有密钥。

3.版本控制

假设你正在部署一个需要更新config/secret变量的新功能，这时出现了问题，应用程序需要回滚。

哦，有人记得.env中的最后一个值吗？没有历史记录，但应用程序正好需要那个刚删除/覆盖的值。

解决所有这些问题的完美方案是使用配置服务器。配置服务器是用于存储配置和密钥的外部应用程序。它被认为是跨环境管理密钥的中心枢纽。

如AWS Parameter Store、Google Secrets Manager或HashiCorp Vault等多个云服务可以作为开源爱好者的配置服务器。

一旦你创建了secret或config，大多数时候会得到一个像https://app.com/config/DB_PASSWORD/v1这样的URL。

让我们看看配置服务器如何解决.env文件的问题。

使用配置服务器，所有密钥都集中在一个地方，加密，并且只能是经过你批准的应用程序和用户访问。

使用配置服务器，就不是更新密钥，而是创建新版本。创建新版本后，再更新密钥URL，如.../config/DB_PASSWORD/v2或.../config/DB_PASSWORD/v3。

与方案2一样，大多数配置服务器都有自动版本控制。如果你需要更新密钥，请创建一个新版本并更新应用程序中的配置 URL。如果应用程序被回滚，它将自动使用最后一个配置 URL。

这种方式，不但保护了现有的密钥，而且应用程序回滚也不会影响以前的密钥。

密钥可能会变旧，从而导致系统受到威胁！像AWS这样的集中式配置提供了自动密钥轮换。

如果你的团队都提取相同的配置，就会自动更新为最新值。无需发送，无需“受信任的”开发人员，也没有忘记更新.env文件的风险可能。轻松无痛！

配置服务器通常托管在VPC上，VPC提供localhost（本地主机）类似服务器连接。这允许无需接触互联网（几乎没有延迟）就可以提取密钥，且不允许外人查询服务器。

有没有密钥泄露？配置服务器通常带有审计日志，因此可以检查何时何地访问了密钥。

更新的配置会导致错误吗？如果需要，可以检查上次更新的时间，为所有服务器执行全局更新。无需编辑纯文本文件。

希望从现在开始开发人员可以为他们的生产服务使用集中配置。.env文件不可靠，因为没有访问管理、版本控制或安全更新。

然而这并不是说.env文件没有意义。它们可用于本地或面向开发的环境。

我想说的要点是不要将有价值的密钥存储在简单的文件中，不安全。

谢谢阅读！