在Public Rails应用程序中哪里存储敏感数据？

问题描述

| 我的个人Rails项目使用了一些API，我将这些API密钥/秘密存储在config / environments / production.yml和development.yml中作为全局变量。我现在想将这个项目推送到github上供其他人使用，但是我不希望他们拥有那些敏感数据。我也不想使用.gitignore文件，因为它是应用程序运行所必需的。我已经考虑过将它们放在数据库中的某个位置，但希望找到更好的解决方案。     

解决方法

TLDR：使用环境变量！ 我认为@Bryce的评论提供了一个答案，我将其冲洗掉。 Heroku建议的一种方法是使用环境变量来存储敏感信息（API密钥字符串，数据库密码）。因此，请检查您的代码，看看其中包含敏感数据。然后创建存储敏感数据值的环境变量（例如，在您的.bashrc文件中）。例如对于您的数据库：

export MYAPP_DEV_DB_DATABASE=myapp_dev
export MYAPP_DEV_DB_USER=username
export MYAPP_DEV_DB_PW=secret

现在，在本地框中，只要需要敏感数据，您就只需引用环境变量。例如在database.yml中：

development:
  adapter: mysql2
  encoding: utf8
  reconnect: false
  database: <%= ENV[\"MYAPP_DEV_DB_DATABASE\"] %>
  pool: 5
  username: <%= ENV[\"MYAPP_DEV_DB_USER\"] %>
  password: <%= ENV[\"MYAPP_DEV_DB_PW\"] %>
  socket: /var/run/mysqld/mysqld.sock

我认为database.yml只能在应用程序的初始化或重新启动时进行解析，因此这不会影响性能。因此，这将解决您的本地开发问题，并使您的存储库公开。除去敏感数据后，您现在可以像私下一样使用相同的存储库来公开。如果您使用的是VPS，也可以解决该问题。像在开发框中一样，仅需使用ssh并在生产主机上设置环境变量即可。 同时，如果您的生产设置涉及到无法部署到生产服务器的自动部署（如Heroku那样），则需要研究如何远程设置环境变量。对于Heroku，这是由

heroku config:add

完成的。因此，根据同一篇文章，如果您已将S3集成到您的应用中，并且您有来自环境变量的敏感数据：

AWS::S3::Base.establish_connection!(
  :access_key_id     => ENV[\'S3_KEY\'],:secret_access_key => ENV[\'S3_SECRET\']
)

只需让Heroku为它创建环境变量：

heroku config:add S3_KEY=8N022N81 S3_SECRET=9s83159d3+583493190

该解决方案的另一个优点是它与语言无关，而不仅仅是Rails。由于它们都可以获取环境变量，因此适用于任何应用程序。     ,这个怎么样...   创建一个新项目，并使用production.yml和development.yml文件中的占位符值将其检入GitHub。      更新.gitignore以包含production.yml和development.yml。      用您的秘密替换占位符值。 现在，您可以将代码检入GitHub，而不会破坏您的秘密。 而且任何人都可以克隆您的存储库，而无需执行任何其他步骤来创建丢失的文件（它们将像您一样替换占位符值）。 这符合您的目标吗？     ,他们可能最好放在初始化程序（config / initializers / api.yaml）中，尽管我认为您已经做好了准备。将实际密钥添加到.gitignore文件中，然后运行

git rm config/environments/production.yml

从存储库中删除该敏感数据。一般警告，它也会删除该文件，因此请先备份它。 然后，只需在实际文件旁边创建一个config / environments / production.yml.example文件，其中包含相关的详细信息，但忽略了敏感数据。将其投入生产时，只需复制不带.example的文件，然后替换适当的数据即可。     ,使用环境变量。 在Ruby中，可以这样访问它们：

ENV[\'S3_SECRET\']

两个原因： 这些值不会使其进入源代码管理。 无论如何，“敏感数据”（也称为密码）往往会根据每个环境进行更改。例如您应该对开发和生产使用不同的S3凭据。 这是最佳做法吗？ 是：http://12factor.net/config 如何在本地使用它们？ 工头和dotenv都很容易。或者，编辑您的外壳。 如何在生产中使用它们？ 在很大程度上，这取决于。但是对于Rails而言，dotenv是一个轻松的胜利。 平台即服务呢？ 任何PaaS都应为您提供一种设置方式。例如Heroku：https：//devcenter.heroku.com/articles/config-vars 这是否会使为该项目设立新的开发人员变得更加复杂？ 也许，但是值得。您始终可以将.env.sample文件检入带有某些示例数据的源代码管理中。在项目的自述文件中添加关于它的注释。     ,Rails 4.1现在有一个约定。您可以将这些内容存储在secrets.yml中。因此，您最终不会在您的应用程序中分散一些全局ENV调用。 这个yaml文件就像解析的database.yml erb一样，因此您仍然可以在这里使用ENV调用。在这种情况下，您可以将其置于版本控制下，然后将其用作必须使用ENV vars的文档。但是您也可以将其从版本控制中排除，并在其中存储实际机密。在这种情况下，您可以将一些secrets.yml.default或类似内容放入公共存储库中以用于记录。

development: 
   s3_secret: \'foo\'
production: 
   s3_secret: <%= ENV[\'S3_SECRET\']%>

比您可以在

Rails.application.secrets.s3_secret

在本集开始时对其进行了详细讨论