LoginSignup
70
59

More than 3 years have passed since last update.

【Rails5.2】秘匿情報はsecret.ymlではなくcredentials.yml.encで管理する【初心者】

Last updated at Posted at 2019-09-22

はじめに

credentials.yml.encについては下記の記事を参考に使用しました。
本稿は、そもそも本番環境の構築に不慣れな中で、個人的に詰まったところを含めつつまとめてみたものになります。

Rails5.2から追加された credentials.yml.enc のキホン
Add credentials using a generic EncryptedConfiguration class
※またRails 6以降からは、環境ごとのファイルについて追加変更があるようです。
Add support for multi environment credentials

特徴

  • 本番でのみ使われる想定で環境ごとの分割はない
    • 環境ごとに使い分けられるようにするgem【rails-env-credentials】あり
  • 秘匿情報の取得はRails.application.credentials.xxx
  • 復号はmaster.keyENV['RAILS_MASTER_KEY']

ポイント

  • rails newした際に、credentials.yml.encmaster.keyが生成される
  • 復号用のmaster.keyがなくてもRails自体は動く
  • credentials.yml.encは暗号化された状態でgitで共有可能
  • master.keyはgit.ignorに含まれているのでgit経由では共有できない
  • 中身の編集はvimで行う

どこにあるの?どこに置くの?

①ローカル

どちらもconfig下にいます。
app/config/credentials.yml.enc
app/config/master.key
※git cloneしたアプリなどはmaster.keyは無い状態。

②本番環境※

applicationname/current/config/master.key
applicationname/current/config/credentials.yml.enc
applicationname/shared/ここにmaster.key配置する
※個人差有

使うコマンド

エディタを初めに指定して、vimコマンドで開くことができます。
環境変数でエディタを指定しておけば、つける必要はありません。

credentials.yml.encを編集する

# 基本
$ rails credentials:edit

# 環境変数EDITORにviを指定
$ EDITOR=vim bin/rails credentials:edit
$ EDITOR="vi" bin/rails credentials:edit

# 本番環境ではルート権限つけてみたり
$ sudo EDITOR=vim rails credentials:edit

予めエディタを環境変数で指定する

# .bash_profileに環境変数 EDITOR を設定
$ echo 'export EDITOR="vi"' >> ~/.bash_profile

# sourceで変更内容を実行中のシェルに反映
$ source ~/.bash_profile

# 確認のためechoコマンドで表示
$ echo $EDITOR
  #=> vi

# もちろんvim開いて書き込んでもおっけー
$ vim ~/.bash_profile
$ source ~/.bash_profile

# 編集コマンドのみで開ける
$ bin/rails credentials:edit

master keyを本番環境にコピーする

$

credentials.yml.encの中身

初期値は下記の通り。
コメントアウトで入っているawsの記述を使う際は、取得サイドの記述と合うように気をつけると◎(例:取得ではaws_を付けてしまった、などの不一致でエラー)
※又聞きですが、他のシークレットキー(API関連など)を入れる時は、awsと同じインデントで揃えないと取得できない現象も有るよう!

credentials.yml.enc
# aws:
#   access_key_id: 123
#   secret_access_key: 456

# Used as the base secret for all MessageVerifiers in Rails, including the one protecting cookies.
secret_key_base: wsx3edc4rfv5tgb6yhn7ujm8ik.......

コメントアウトを外してid・keyを入れたら、コンソールで取得してみる

$ rails c
irb(main):001:0> Rails.application.credentials.aws[:access_key_id]
=> hogehogehoge
irb(main):002:0> exit

環境変数で読み取る

RAILS_MASTER_KEY

master.keyを共有できない環境であれば、環境変数RAILS_MASTER_KEYmaster keyを設定。
どちらもない場合はファイルの読み取りはできません。

$ rails c
irb(main):001:0> Rails.application.credentials.secret_key_base
=> nil

# 環境変数でmaster keyを指定
$ export RAILS_MASTER_KEY= "aaaaaaaaaa......."
irb(main):002:0> Rails.application.credentials.secret_key_base
=> wsx3edc4rfv5tgb6yhn7ujm8ik.......

irb(main):003:0> exit

オプション

require_master_key

本番環境で、master.keyの指定漏れ防止に推奨されているオプション。
開発&テストでは、secret_key_baseはデフォルトではnilが返ります。(復号キーがなくても仮の値が使われる)

config/environments/production.rb
config.require_master_key = true

注意点

ハマりやすいポイント

gitcloneしたアプリケーションや、途中でバージョンUPした人が詰まりやすいのかもしれません。

【例】

チームで、git cloneして開発中。
master.keyを持っていない状態で開こうとする=編集コマンドを叩くと、その時点でmaster.keyが生成される。
→本来の鍵と異なるmaster.keyなので、アプリケーションを立ち上げられなくなる。
そのため、下記のようなケースに注意するとトラブルを防げるかと思います。

【対応策】

master.keyは、秘匿情報を扱うメンバー間で共有しておく。(文字列をコピーしてmaster.keyを置いてから編集する)

家を借りた人が鍵持ってるから、出入りしたい人は合鍵をつくる感じですかね!

②うっかり新しい鍵を生成してしまった時→エディタに出現したconfig下のmaster.keyを削除する。

(その後、①同様本物のキー情報をコピー。)
AWSやSNS認証など管理するべきKeyが増えるときなど。
鍵無くした〜このお家入りたい〜って別の鍵でガチャガチャしているような状態。
その鍵捨てて正しい鍵を保持しましょう!

③newした人が鍵無くした場合→一度credentials.yml.encファイルを削除して編集コマンドを叩くことで、新しいファイルとキーを生成する。

鍵が無いのでドアごと替えてしまえ!みたいな状態です。

ただし、注意点。
内側のポストの中身まで、一緒に捨てることになります。

credentials.yml.encに何を記載しているか、他メンバーが登録した情報はないか、分かっている時のみにするべし。
(初期段階だったり作り直すにしてもrails newしたひとが行うのが一般的だとは思いますが、、、別メンバーが作り直して共有することも可能です。)

secret_key_baseはコマンドで生成して勝手に記述されるので、envbash等で管理していない無い場合は、そちらも作成し直す必要が出るかも知れません。

おわり

secret.ymlもあまり理解しないうちですが、シークレットキーを一元管理できるのは楽かな?という印象。
誤った記述があればお手数ですがご指摘ください・・・!

70
59
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
70
59