web-dev-qa-db-ja.com

機密データを公開する場所Rails app？

私の個人的なRailsプロジェクトは、APIキー/シークレットをグローバル変数としてconfig/environment /production.ymlとdevelopment.ymlに保存するいくつかのAPIを使用しています。このプロジェクトをプッシュしたいと思います。他の人が使用できるようにgithubを使用しますが、機密データのビットを使用したくないです。また、アプリの実行に必要なため、このファイルを.gitignoreに含めたくありません。DBに配置することを検討しました。どこかにありますが、より良い解決策を見つけることを望んでいます。

ruby-on-railsenvironment-variablescredentialsapi-key
39
tybro0103

[〜＃〜] tldr [〜＃〜]：環境変数を使用してください！

@Bryceの comment が答えを提供していると思いますが、それをフラッシュします。 1つのアプローチのようです 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のように本番サーバーにSSH接続できないハンズオフデプロイメントが含まれる場合は、環境変数をリモートでセットアップする方法を検討する必要があります。 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

このソリューションのもう1つの利点は、Railsだけでなく、言語に依存しないことです。すべてのアプリが環境変数を取得できるため、どのアプリでも機能します。

49
yuvilio

これはどう...

新しいプロジェクトを作成し、production.ymlファイルとdevelopment.ymlファイルのプレースホルダー値を使用してGitHubにチェックインします。

.gitignoreを更新して、production.ymlとdevelopment.ymlを含めます。

プレースホルダーの値をシークレットに置き換えます。

これで、秘密を危険にさらすことなく、コードをGitHubにチェックインできます。

また、不足しているファイルを作成するための追加の手順なしで、誰でもリポジトリのクローンを作成できます（プレースホルダーの値は、あなたが行ったように置き換えるだけです）。

それはあなたの目標を満たしていますか？

3
Daniel Kehoe

それらはおそらく初期化子（config/initializers/api.yaml）に入れるのが最善ですが、あなたが作り上げたものは問題ないと思います。実際のキーを.gitignoreファイルに追加し、git rm config/environments/production.ymlを実行して、その機密データをリポジトリから削除します。公正な警告です。そのファイルも削除されるので、最初にバックアップしてください。

次に、実際のファイルの横にconfig/environment/production.yml.exampleファイルを作成し、関連する詳細を含め、機密データは省略します。本番環境にプルアウトするときは、.exampleなしでファイルをコピーし、適切なデータに置き換えてください。

1
brycemcd

Rails 4.1には、そのための規則があります。このようなものをsecrets.ymlに保存します。そのため、アプリ全体にグローバルなENV呼び出しが散在することはありません。

このyamlファイルは、解析されたdatabase.yml erbに似ているため、ここでENV呼び出しを引き続き使用できます。その場合、バージョン管理下に置くことができ、ENV変数を使用する必要があるドキュメントとして機能します。ただし、バージョン管理から除外して、実際の秘密をそこに保存することもできます。その場合、ドキュメント化の目的で、いくつかのsecrets.yml.defaultなどをパブリックリポジトリに配置します。

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

あなたが下でこのものにアクセスできるより

Rails.application.secrets.s3_secret

this エピソードの冒頭で詳細に議論されています

1
dre-hh

環境変数を使用します。

Rubyでは、次のようにアクセスできます。

ENV['S3_SECRET']

2つの理由：

  1. 値はソース管理にはなりません。
  2. 「機密データ」（別名パスワード）は、とにかく環境ごとに変更される傾向があります。例えば開発用と本番用に異なるS3認証情報を使用する必要があります。

これはベストプラクティスですか？
はい： http://12factor.net/config

ローカルで使用するにはどうすればよいですか？
foreman と dotenv はどちらも簡単です。または、 シェル を編集します。

本番環境でそれらを使用するにはどうすればよいですか？
大きく異なります。しかし、Railsの場合、 dotenv は簡単に勝ちます。

Platform-as-a-Serviceはどうですか？
どのPaaSでも、それらを設定する方法を提供する必要があります。たとえば、Heroku： https://devcenter.heroku.com/articles/config-vars

これにより、プロジェクトの新しい開発者を設定するのが難しくなりませんか？
おそらく、それだけの価値はあります。 .env.sampleファイルは、サンプルデータを含むソース管理にいつでもチェックインできます。プロジェクトのreadmeにそれに関するメモを追加します。

1
tybro0103