回答:
残念ながら、キーはプレーンテキストでChefノードのどこかにある必要があるため、実際にできることは多くありません。誰かがボックスへのシェルまたはローカルアクセス権を持っている場合、そのキーを読み取ることができる可能性があります。
少し緩和するために、次のコードをベースノードに追加します(つまり、すべてのノードに共通のレシピまたはロール)。
directory "/etc/chef/keys" do
mode 0700
owner "root"
group "root"
end
そして、あなたが持っているどんな鍵配布メカニズムもその場所に鍵を置きます。権限と所有権により、誰かがキーファイルに正しい権限を付与するのを忘れた場合、キーを読み取ることができなくなります。
暗号化されたデータバッグは、キーコントロールをソースコントロールシステムで読み取れないようにするためのものであり、Chefノード自体のセキュリティ機能としてはそうではありません。
私のEDBは次のように区切られています。
ブートストラップするときに、すべての新しいEC2インスタンスに特別なサフィックスを持つすべてのキーをアップロードし、最初のchef-clientの実行の最後に、run_list内のレシピで使用されていないすべてのキーを削除します(これはインスタンスが起動するとすぐです。)
すべてのファイルは、所有者およびグループ「root」としてアップロードされ、読み取り権限のみが付与されます。
EDBを使用するすべてのレシピは、「edb_」+ノード環境+レシピ/アイテム固有の名前+「.key」を連結することにより、レシピの実行時にEDB名とキーファイル名を生成し、この名前でキーを検索します。(存在しない場合、デフォルトで例外がスローされます。)
したがって、「couch」というロールを実行しているcouchdbサーバーの場合、開発環境の管理者ユーザーに使用している資格情報を取得するために、レシピは「edb_dev_couch.key」という名前のキーを探します。
次に、「edb_dev」という名前のデータバッグで「couch_credentials」という名前のアイテムを検索します。
キーを管理するために、私は現在、次の簡単なアプローチを使用しています。
うまくいけば、これにより、マシンがブートストラップされてchef_clientが最初に実行されるまで、単一ノードの範囲外のキーが影響を受けやすい時間が制限されます。
これは、キーを保護する方法の最初のテストですが、これまでのところ、1つのルート化された開発サーバーがEDBに保存されている他のサーバー資格情報にすぐにアクセスできないため、現在のニーズを満たしています。
すべての実行リストの最後に1つのレシピを保持するために、このdelete_keysレシピがすべてのノードの最後のレシピになるように、knife execジョブを使用します。
私のキーは、使用するAMIまたは使用するイメージに焼き付けられます。そのデータは安全ではないので、ブートストラップの一部としては行いません。注意しないと、通常、ログなどでデータを確認できます。