如何开源我的 Rails?应用程序无需泄露应用程序的密钥和凭据
我在 GitHub 上托管了许多 Rails 应用程序。它们目前都是私有的,我经常从它们的 GitHub 存储库中部署它们。我希望能够将其中一些开源,就像您可以在 http://opensourcerails.com< 上找到的那样/a>.
我的问题是:如何在不泄露超级秘密凭证的情况下公开这些存储库?
例如,我可以查看 /config/initializers/cookie_verification_secret.rb 并查看几乎每一个的 cookie 秘密。我不明白这是如何可以接受的。这些用户是否都以某种方式在其部署环境中更改了这些值?
有些用户甚至暴露了他们的 AWS 秘密和密钥!其他人会将他们的 AWS 秘密设置为类似以下内容:
ENV['aws-secret']
尽管我不确定他们在什么时候设置该值。
那么,在不影响应用程序安全性的情况下开源 Rails 应用程序的最佳实践是什么?
I have a number of Rails apps hosted on GitHub. They are all currently private, and I often will deploy them from their GitHub repository. I'd like to be able to make some of them open source, just like the ones you can find on http://opensourcerails.com.
My question is: How can I make these repositories public without giving away super secret credentials?
For example, I can look in /config/initializers/cookie_verification_secret.rb and see the cookie secret for nearly every one of them. I don't understand how this is acceptable. Are these users all changing these values in their deploy environments somehow?
Some users even expose their AWS secret and key! Others will instead set their AWS secret to something like:
ENV['aws-secret']
although I'm not sure at what point they're setting that value.
So, what are the best practices for open sourcing your Rails app without compromising your app's security.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
我最近用我自己的一个应用程序经历了这个过程。我的解决方案是将任何秘密存储在 git-ignored YAML 配置文件中,然后使用初始值设定项目录中的简单类来访问该文件。配置文件存储在 Capistrano 部署的“共享”文件夹中,并在每次部署时复制到 config。
配置存储: http://github.com/tsigo/jugglf/ blob/master/config/initializers/juggernaut.rb
示例用法: https://github.com/tsigo/jugglf/blob/6b91baae72fbe4b1f7efa2759bb472541546f7cf/config/initializers/session_store.rb
您可能还想从源代码管理中删除使用这些秘密值的文件的所有历史记录。以下是我使用的 Git 中执行此操作的指南: http://help.github.com/删除敏感数据/
I recently went through this with one of my own apps. My solution was to store anything secret in a git-ignored YAML config file, and then to access that file using a simple class in the initializers directory. The config file is stored in the 'shared' folder for the Capistrano deployment and copied to config at each deploy.
Config store: http://github.com/tsigo/jugglf/blob/master/config/initializers/juggernaut.rb
Example usage: https://github.com/tsigo/jugglf/blob/6b91baae72fbe4b1f7efa2759bb472541546f7cf/config/initializers/session_store.rb
You may also want to remove from source control all history of the file that used these secret values. Here's a guide for doing this in Git that I used: http://help.github.com/removing-sensitive-data/
如果您使用的是 foreman,请将
.env
文件放入应用的根目录中。 (foreman 文档).env
将然后,当您需要使用这些键时,请插入:
尽管重要的是不要将此
.env
提交到版本控制中。因此,如果您使用 git,请将.env
添加到.gitignore
中。奖金回合! - Heroku
如果部署到 Heroku,这些环境变量也需要在 Heroku 环境中配置。有两个选项:
heroku config:add
命令手动添加密钥If you're using foreman, put an
.env
file in the root of your app. (foreman docs).env
will haveThen when you need to use the keys, insert:
Though it's important that you don't commit this
.env
to your version control. So if you're using git, add the.env
to your.gitignore
.Bonus round! - Heroku
If deploying to Heroku, these environment variables need to be configured in the Heroku environment, too. There are two options:
heroku config:add
command根本不存储任何秘密值。 Git 存储库历史上的任何时刻。
这些值应该存储在其他地方,只保留模板配置文件的版本,以及能够执行以下操作的脚本:
从 数据分开(一侧是源,另一侧是秘密值),然后您可以开源源存储库,而不包含任何秘密。
Not storing any secret value at all. At any point in the history of a Git repo.
Those values should be stored elsewhere, leaving only template config files versioned, along with a script able:
By keeping the tow set of data separate (sources on one side, secret values on the other), you can then open source the sources repo without comprising any secrets.
实际上,我使用 ENV 从你的问题中得到了暗示。
我有三个不同的秘密值,但我不想让它们可用。当然,它们是应用程序的秘密令牌,也是 Twitter 的消费者密钥和秘密。在我的秘密令牌初始值设定项中:
我在 Heroku 上托管我的项目,因此我将这些作为配置变量添加到 Heroku。
现在,这些值已在我的下一次推送中准备就绪。但是,如果您不使用 Heroku 该怎么办?显然,我不是每个 Rails 部署的专家(天哪,甚至不是 Heroku 专业人士),但一个例子是执行 db:migrate 进行测试。
命令之前的 KEY=value 对设置环境变量,因此运行此命令,
echo ENV['RAILS_ENV']
将打印test
。因此,无论您的环境如何设置,您都会这样做。但是,环境变量不在您的代码中,所以这就是技巧。I actually took a hint from your question, using ENV.
I had three different secret values that I didn't want made available. They're the app's secret token of course, and Twitter's consumer key and secret. In my secret token initializer:
I'm hosting my project on Heroku, so I added these as configuration variables to Heroku.
Now, the values are ready on my next push. But, what if you aren't using Heroku? I'm obviously not an expert on every single rails deployment (jeesh, not even a Heroku pro), but an example of this would be doing a db:migrate for testing.
The KEY=value pair before the command sets the environment variable, so running this command,
echo ENV['RAILS_ENV']
would printtest
. So however this is set up in your environment is how you would do it. But, the environment variables aren't in your code, so that's the trick.[编辑 - 以下方法有一个烦恼,即必须切换到生产分支来运行“rails 服务器”才能包含必要的 cookie。因此,在服务器时进行编辑很困难......而且我仍在寻找一个好的解决方案]
经过进一步调查,我认为我正在寻找的解决方案是从我的 Git 存储库的主分支中排除任何存储秘密值的内容(正如@VonC所说)。但我没有从单独的存储库中读取这些文件,而是简单地创建一个新的“生产”分支并将它们添加到其中。
这样它们就被排除在 Master 之外,我可以将其推送到 Github 或其他一些公共存储库。当我准备好部署时,我可以签出 Production 分支并将 Master 合并到其中并部署 Production。
我需要能够做到这一点,因为 Heroku 和其他主机需要将单个 git 存储库推送到他们的服务器。
更多信息请参见:
http://groups.google.com/group/ heroku/browse_thread/thread/d7b1aecb42696568/26d5249204c70574
[EDIT - The following method has the annoyance of having to switch to the Production branch to run "rails server" in order to include necessary cookies. Thus, making edits while the server is difficult... and I'm still looking for a good solution]
After further investigation, I think the solution I was looking for was to exclude anything that stored a secret value from my Git repo's master branch (just as @VonC said). But instead of then reading from those files in a separate repo, I simply create a new "production" branch and add them to that.
This way they're excluded from Master and I can push that to Github or some other public repo just fine. When I'm ready to deploy, I can checkout the Production branch and merge Master into it and deploy Production.
I need to be able to do this because Heroku and other hosts require a single git repo to be pushed to their servers.
More information here:
http://groups.google.com/group/heroku/browse_thread/thread/d7b1aecb42696568/26d5249204c70574