如您所知,带有环境变量的文件(通常具有带或不带文件名的扩展名.env
)通常不会被版本控制系统跟踪,以防止数据库密码等数据泄露。SLL 密钥和证书文件怎么样?我请你分别考虑本地开发、分期和制作的情况。
关于这个话题的思考过程
本土化发展模式
如果在本地开发模式下您使用自行颁发的(例如,使用mkcert)SSL 密钥和证书,那么通常我认为没有理由将它们排除在版本控制系统的跟踪之外。它似乎不包含任何敏感数据。
强制每个团队成员自己颁发证书的唯一可能原因是 mkcert 中可能缺少强制浏览器信任已颁发证书的命令。如果确实没有这样的命令,那么每个参与者都必须自己运行该命令mkcert
,这不仅会颁发密钥和证书,而且浏览器也会信任它们。在 Windows 上没有 mkcert 的情况下执行此操作并不容易(在我提出问题时我无法做到这一点)。
根据评论更新
正如@andreymal 评论的那样,
如果您将自行颁发的证书添加到受信任的浏览器中,那么泄露其私钥将允许攻击者发起中间人攻击,因此非常危险
我希望这不会成为在本地开发模式下仅使用 HTTP 协议(而不是 HTTPS)的理由。
生产
我不确定,但我认为生产模式的 SSL 密钥和证书是不应泄露的秘密信息。有一定的可能性,它们也可以使用浏览器开发者模式作为 CSS 或 JS 文件进行一般查看,但这又是一个假设。
与本地开发模式下每个团队成员都可以拥有自己的自行颁发的 SSL 密钥和证书不同,在生产模式下,每个人都会有一个密钥和一个证书(很可能由授权组织以可报销的方式颁发)。如果是这样,它们将不得不被排除在版本控制之外,并以其他方式在团队成员之间转移。
根据评论更新
有人提出这样的问题:如果理论上一两个生产服务器管理员知道就足够了,为什么团队成员应该了解生产 SSL?我的答案是:根据项目组装和部署的自动化的组织方式,有时在源代码文件中拥有 SLL 密钥和证书会很方便。
首先值得警惕的是,只有生产服务器的管理员才应该知道 SSL 密钥。我并不是说这是错误的,但在这种情况下,当只有一两个团队成员拥有 SSL 密钥和证书时,可能会出现问题。例如,管理员没有上班,但需要发布应用程序修补程序。或者应用程序运行所需的文件分散在团队成员中而不是组织在一起。
再说一次,我并不是说每个人都应该这样做,但我将项目收集在一个文件夹中,该文件夹中放置了应用程序在服务器上工作所需的所有内容,特别是 ssl 密钥、证书和环境变量文件:
因此,构建项目后,剩下的就是以一种或另一种方式将文件发送到 VPS 并docker compose build
在 VPS 上重新启动它。
我知道有各种各样的高级部署方法,特别是 GitHub 上的 CI/CD 或各种 AWS 工具。例如,您可以使用 AWS 组织环境变量的注入,而无需使用 .env 文件 - SSL 可能有类似的东西。但所有这些都将开发商与特定的供应商联系在一起。有时这是合理的,但当最初只有一个使用裸 Ubuntu 的 VPS 时,仍然必须有某种方法来有效地组织部署。