読者です 読者をやめる 読者になる 読者になる

みんな機密情報ってどうやって設置/管理してるんだろう?

たまにはモヤモヤしてることを書き連ねてみます。
この記事に答えはないので、期待しないで読み進めてください。

データベースの接続情報とかの機密情報ってどうやって管理するの?

よく言われるのは DB への接続情報とか、AWS とかのトークンはアプリのコードと一緒にコミットするな、というもの。
環境変数から読み取るようにしたり、Pit を使ったりする方法が割と有名ですね。この前の rubykaigi では dotenv なんてのものが紹介されてました。
capistrano では設定ファイルを symlink で差し替えるやり方(shared ディレクトリを使う)が一般的です。

chef と機密情報

ここまでは僕も実践していますし、アプリのコードに設定が埋め込まれるようなことは避けているわけですが、
chef を使うようになってから、同じ問題にぶち当たっています。
chef は環境設定を担当するので、さっき挙げた

  • .bashrc (またはその仲間)
  • .pit/
  • .env
  • shared/database.yml やその仲間

などを作るのは chef の役目だと僕は考えています。

そうした時に、chef-solo の場合はこれらの設定をコミットして管理することになります。
(その形態は cookbooks, attributes, data_bags など様々だと思います)
このとき、chef のリポジトリにはトークンやらパスワードなどの情報が含まれちゃうんですよね。
これをどう回避すればいいのか、たまにこの問題を思い出す度に頭を抱えています。

encrypt data_bag 使えばいいんじゃね? 論

Chefで公開したくないJSONデータを暗号化するためにDataBagsを利用してみた記録 などで紹介されている
chef-solo_data_bag を使うと data_bags の中身を暗号化することができるので、
暗号化された状態でコミットすればいいじゃん、というアイディアもあります。

ですが、chef の data_bags の暗号化というのは共通鍵暗号を使っているので、鍵の保管がキモになります。
data_bags を復号化できる鍵なのですから、data_bags と同じリポジトリにコミットしては意味がありません。
でも、chef-solo を実行するために鍵を各サーバに kitchen の各ファイルと鍵を転送するとなると、
なるべく近い場所で管理しておきたいという思いがあります。

結局どうしてるの?

最初は chef のリポジトリと鍵のリポジトリを分けることも考えたのですが、
chef のリポジトリにアクセスできる人は、もう一方にも容易にアクセスできるはずだ、ということに気づき、
今のところは chef のリポジトリに鍵を置いています。
ぱっと見の難読化がなされている、というそれだけの防御になっています。

まあ、そもそもデプロイ先の環境には設定ファイルが生で配置されているわけですから、
あれやこれや考えこんでも漏れるときは漏れるよねー、という諦めの精神からこうしています。

でも、なにかいいやり方があるんじゃないか、他の人はもっといい手を使ってるんじゃないか、と
モヤモヤが残ったままなので、思いの丈を記事にして助けてもらうライフハックと相成りました。
コメントでもブコメでも教えてくれるとありがたいです。