シェフとの秘密の管理

Question

シェフと秘密をどのようにして管理するのが信頼性が高く予測可能なのか不明です。

私が試みたのは、秘密を管理しているすべての料理本に依存する別の料理本にすべての秘密の論理を置くことでした。

私はそう思っていました。秘密は一箇所で一貫性のある方法で処理できました。もう一つの利点は、私は既存の料理本を変更する必要がないということです。

この秘密の料理本は、暗号化されたデータバッグから秘密を取り出し、それを使ってパスワード/秘密属性を設定しています。秘密がChefサーバーにアップロードされないように、アップロードしたくないすべての属性をブラックリストに載せます。

いくつかの料理本では、これには効果がありますが、他の結果では実際には予測できなくなります。私は今、それはそれについて行く方法ではないと確信している点に。これを行うための推奨される方法は何ですか？私は既存の料理本を変更したくありません。例えばので

秘密に属性['mariadb']['server_root_password']を回し、それが暗号化されたデータバッグから値です取得するための最良の方法は何

execute 'change first install root password' do 
    # Add sensitive true when foodcritiC#233 fixed 
    command '/usr/bin/mysqladmin -u root password \'' + \ 
    node['mariadb']['server_root_password'] + '\'' 
    action :nothing 
    not_if { node['mariadb']['server_root_password_2'].empty? } 
end 

のようなものを持つ料理がある場合は？私は料理本を変更したくないので、パスワードをサーバーにアップロードしたくない。

更新

私は問題がブラックリストに属性がシェフの実行中に使用できなくさせるblacklist_node_attrsのバグの結果であると思います。

しかし、秘密と組み合わせて属性のアプローチ全体がシェフではほとんど開発されていないようです。それは素晴らしいです。

秘密を管理したい場合は、既存の料理本を変更する必要があります。アトリビュートファイルとレシピファイルでcookbookアトリビュートを試すと、結果がランダムであることがわかります。状況によってはうまくいくこともあれば、そうでないものもあります。

Answer 1

ノード属性に秘密を置くことは、非常に賢明ではありません。あなたが指摘したように、彼らは明確にシェフサーバーに保存されます。あなたが非常に壊れやすい解決策になりたくない場合は、その料理本を更新する必要があります。私はおそらく1〜2ヶ月後にリリースされる予定ですが、一般的な解決策はありません。私はあなたが（この質問のタイトルは私のブログ記事のタイトルでもあるので）私があなたに行ってきたと推測しているcoderanger.net上でこれについて多くの言葉を持っています。スラックやIRCにPingしてください（私はUTC + 11に数日いますが、UTC-7に戻ってきます）、あなたのユースケースに合わせたものを提供しようとしています。全体的に短いバージョンは、これはすべてひどいものであり、現在は良い答えはありません。

Answer 2

暗号化されたデータバッグを調べて実験したところ、必然的にシェフは秘密を管理するための解決策を持っていないという結論に達しました。

データバッグ、ボールトなどはもちろん暗号化されていますが、秘密を安全に管理するためにコミュニティ/既存/サードパーティの料理本を変更しないという慣行とは矛盾しています。

暗号化されたデータバッグなどは、私たちが料理本を変更する必要があるということです。料理本が自分のものであれば問題ありませんが、コミュニティの料理本を使用する場合は、これを変更することはお勧めしません。