Chef でパスワードと API キーを保存するためのベスト プラクティスは何ですか? レシピで使用するためにデータベースのパスワード、AWS api キー、およびその他の機密性の高い認証情報を Chef サーバー属性として保存するのは非常に魅力的ですが、セキュリティに関する考慮事項はどうでしょうか? これのベストプラクティスは何ですか?
9 に答える
#chef IRC チャンネルから、多くの人がこの種のデータをchefサーバーのデータバッグに保存しています。
たとえば、データ バッグは「aws」で、アイテムは「main」で、プライマリ AWS アカウントを指します。アイテム内の個別のキーは、特定の値ごとになります。例えば:
{
"id": "main",
"aws_secret_key": "The secret access key",
"aws_access_key": "The access key"
}
暗号化されたデータ バッグにも興味があるかもしれません。postfix SASL authenticationを管理するために、それらについてより詳細に書きました。
更新:ブログとsysadventでChef Vaultに関するブログ記事を書きました。
Hashicorp の Vault は、暗号化された情報を動的に取得し、この分野での Chef ワークフローの奇妙な部分を残す方法として、非常に有望だと思います。
これは、主題に触れ始める興味深い投稿です。 https://www.hashicorp.com/blog/using-hashicorp-vault-with-chef.html
ベスト プラクティスは、キーとパスワードをchef data_bagsに保管することです。データバッグには、データバッグ項目が含まれています。個々の data_bag アイテムは json 形式です。
例:
{
/* This is a supported comment style */
// This style is also supported
"id": "ITEM_NAME",
"key": "value"
}
データ バッグ アイテムの暗号化: データ バッグ アイテムは、共有シークレット暗号化を使用して暗号化できます。これにより、各データ バッグ アイテムに機密情報 (データベース パスワードや ssh キーなど) を保存したり、ソース コントロール システムで管理したりできます (リビジョン履歴にプレーンテキスト データが表示されることはありません)。これは次のように実行できます。
クレタ島の秘密鍵: たとえば、encrypted_data_bag_secret という名前の秘密鍵を作成します。
$ openssl rand -base64 512 | tr -d '\r\n' > encrypted_data_bag_secret
encrypted_data_bag_secret は、秘密鍵を含むファイルの名前です
data_bag の暗号化: データ バッグ アイテムは、次のようなナイフ コマンドを使用して暗号化されます。
$ knife data bag create passwords mysql --secret-file /tmp/my_data_bag_key
ここで、「passwords」はデータ バッグの名前、「mysql」はデータ バッグ アイテムの名前、「/tmp/my_data_bag_key」は秘密鍵を含むファイルがある場所へのパスです。
暗号化の検証: データ バッグ アイテムの内容が暗号化されている場合、復号化されるまで読み取ることができません。暗号化は、次のようなナイフ コマンドで確認できます。
$ knife data bag show passwords mysql
データ バッグの復号化: 暗号化されたデータ バッグ アイテムは、次のようなナイフ コマンドで復号化されます。
$ knife data bag show --secret-file /tmp/my_data_bag_key passwords mysql
Chef Vaultは良い選択です。暗号化されたデータをシェフサーバーに保存するためのシンプルなインターフェース、アクセス管理を提供します。コマンドでデータをアップロード、編集、更新しknife vault ...
ます。
レシピ使用ChefVault::Item.load
コマンドからデータを取得するには
chef_gem "chef-vault"
require 'chef-vault'
item = ChefVault::Item.load("passwords", "root")
item["password"]
データを更新できるユーザーを設定するには、knifevault_admins
プロパティを使用します。
knife[:vault_admins] = [ 'example-alice', 'example-bob', 'example-carol' ]
データバッグを試したことはありませんが、それはおそらく、chef-solo 以外のすべてが少し複雑すぎるためです。そのため、私は Scalarium というサービスでシェフのレシピを使用しています。
したがって、パスワード、または秘密鍵やその他のあらゆる種類の資格情報などの問題は、かなり難しいものです。私も、パスワードを作成する必要がある、または正しく設定する必要があるレシピをたくさん持っています。
通常、私が行うことは、scalarium の人々がcustom jsonと呼ぶものを指定することです。node.json
この json は、一部の人々が を使用してchef-solo に与えるものに似ていchef-solo -j node.json
ます。
たとえば、 Scalarium Web インターフェイスのカスタム jsonには、次のものがあります。
{"super_secure_password":"foobar"}
これにより、シェフの実行中に非常に安全なパスワードnode[:super_secure_password]
が利用可能になり、レシピやテンプレートで使用できるようになります。
Scalarium を使用してサーバーをデプロイする限り、これは問題なく機能しますが、開発環境と簡単なテストのために、ローカルの vagrant ボックスでもレシピを使用します。また、vagrant (またはchef-solo自体) を使用すると、 Scalariumのカスタム jsonにアクセスできません。
これを修正するために私が行うことは次のmy_recipe/attributes/default
とおりです。
set_unless[:super_secure_password] = "test123"
これは、私のレシピが scalarium の外で実行された場合でも、パスワードは引き続き利用可能でnode[:super_secure_password]
あり、私のレシピは機能することなどを意味します。レシピが scalarium コンテキストで実行される場合、レシピが提供するものをオーバーライドしません。
現在最も広く使用されているアプローチであり、ほとんどの場合十分に安全なのは、chef-vault を使用することです。
共有シークレットを使用してデータを暗号化します (シェフが暗号化したデータバッグに似ています)。この共有シークレットは、それを使用するすべてのクライアントおよび/またはユーザーに対して暗号化されます (使用を許可した場合)。
利点:
- テスト環境では、暗号化されていないデータを使用できます
- 共有シークレットをプレーンテキストとして保存しない
- いくつかのデータバッグを読み書きするために、少数のサーバーにのみアクセスを許可する場合があります
例
export EDITOR=vi #sets your favourite text editor
knife vault create secret_data john_doe --admins "admin" --search "*:*" --mode client
上記のコマンドは、すべてのクライアントが変更および使用できるsecret_data
databag item:を作成します。その後、コマンドが開くので、秘密のデータを貼り付けます( json )。john_doe
admin
EDITOR
検索クエリは次のとおりです。"role:basic"
- これは、ロールを持つサーバーのみbasic
がこのデータを読み取ることができること
を意味しknife vault
、追加のインストールが必要です。
あなたのクックブックで
chef_gem 'chef-vault' do
compile_time true if respond_to?(:compile_time)
end
require 'chef-vault'
item = ChefVault::Item.load("secret_data", "john_doe")
item["password"]
とでmetadata.rb
:
depends 'chef-vault', '1.3.0'
詳細はこちら: https://blog.chef.io/2016/01/21/chef-vault-what-is-it-and-what-can-it-do-for-you/