Rails 6.0 最佳实践中的 secret_key_base答案

【问题标题】：secret_key_base in Rails 6.0 best practicesRails 6.0 最佳实践中的 secret_key_base
【发布时间】：2020-08-30 22:21:39
【问题描述】：

在以前的 rails 版本中，机密文件未加密。所以最好的做法是阅读，例如secret_key_base，来自环境。

这是有道理的，而且很简单：

# config/secrets.yml

# Do not keep production secrets in the repository,
# instead read values from the environment.
production:
  secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>

Secrets 作为密钥的简单逻辑目录。

在 Rails 6.0 中，文件被加密并且不被解析，这意味着它必须包含硬编码的字符串，即真正的秘密。

将值硬编码并在所有环境中使用相同的密钥是最佳做法吗？这似乎不对。

【问题讨论】：

它没有被解析的关键原因是你不应该在其中使用 ENV 变量。虽然 ENV var 在许多方面比将凭据存储在纯文本文件中更安全，但它们也非常容易受到攻击，因为任何 gem 都可能通过草率的调试泄漏整个 ENV 哈希。
@max 但是您仍然必须将秘密放入环境中，对吗？所以这几乎是一样的。
不完全。如果 gem 泄漏 ENV，他们只会获得加密密钥。攻击者仍需要获得文件系统访问权限才能读取实际凭据。我想这是一个有争议的问题，但如果你的代码在公共仓库中。
密钥也可以通过文件提供。
@max 是的，但是将密钥与加密文件放在一起是毫无意义的......

标签： ruby-on-rails encryption configuration

【解决方案1】：

当在 5.2 中引入安全凭证时，您只有一个凭证文件。

根据普遍需求，Rails 6 将加载一个单独的 config/credentials/*.yml.enc 文件 - 如果文件存在，* 是环境的名称。此文件完全优先于 config/credentials.yml.enc - 两者没有合并。

您可以通过传递环境选项来编辑特定环境的凭据：

rails credentials:edit --environment development

见：

Rails PR #335219

【讨论】：

这是最佳实践吗？我们有不同的阶段和设置，它们都配置相同（生产环境）。只有一些键不同。如果依赖这个概念，我们将不得不有不同的环境来存储不同的 API 密钥（因此复制了 production.rb、demo.rb 等）。我想出了问题，是我们滥用secrets 来组织配置，尽管这不是必需的。感谢分享！
这实际上只是内置于 Rails 中的内容，DHH 特别希望使其尽可能简单和向后兼容，同时将其扩展为更高级的用例，“留作开发人员练习”。如果这真的是“最佳实践方式”，那就见仁见智了。