Wazuh-ansible: 構成設定の選択した部分をオーバーライドするためのより簡単な方法が必要

作成日 2018年12月12日  ·  5コメント  ·  ソース: wazuh/wazuh-ansible

_wazuh_manager_config_ハッシュを再構築するか、設定の小さなチャンクを簡単にオーバーライドできるようにコードを変更すると、理想的です。

wazuh_manager_config:
  active_responses:
    - command: host-deny
      level: 6
      location: local
      timeout: 600
    - command: restart-ossec
      location: local
      rules_id: '100002'
    - command: win_restart-ossec
      location: local
      rules_id: '100003'
  alerts_log: 'yes'
  api:
    basic_auth: 'yes'
    behind_proxy_server: 'no'
    bind_addr: 0.0.0.0
    ciphers: ''
    drop_privileges: 'true'
    experimental_features: 'false'
    honor_cipher_order: 'true'
    https: 'no'
    https_ca: ''
    https_cert: /var/ossec/etc/sslmanager.cert
    https_key: /var/ossec/etc/sslmanager.key
    https_use_ca: 'no'
    port: 55000
    secure_protocol: TLSv1_2_method
    use_only_authd: 'false'
  authd:
    enable: true
    force_insert: 'yes'
    force_time: 0
    port: 1515
    purge: 'no'
    ssl_agent_ca: null
    ssl_auto_negotiate: 'no'
    ssl_manager_cert: /var/ossec/etc/sslmanager.cert
    ssl_manager_key: /var/ossec/etc/sslmanager.key
    ssl_verify_host: 'no'
    use_password: 'no'
    use_source_ip: 'yes'

...etc. etc. etc.

その理由は、この構成の個々の部分(クラスター設定など)をオーバーライドするのは簡単ではないためです。 それはすべてか無かです。
言い換えると、これらの変数の_most_を_group_vars / wazuh_managers.yml_で定義し、_host_vars / manager01.yml_のようなものを使用していくつかの設定をオーバーライドしたい場合、タスクを変更しないと簡単にできません。

現在、私の各ホスト変数には、1つまたは2つの設定が変更された、ホスト変数ファイルにこのハッシュの完全なコピーがあります。 乾燥していないようです。 一般的な設定のほとんどがグループ変数ファイルにあり、ホストに固有の1つまたは2つの設定がホスト変数ファイルにあると便利です。

combineフィルターを活用して、より大きな構成の一部を簡単にオーバーライドできるようにする方法があるかもしれません。

例えば
{{ {'a':{'foo':1, 'bar':2}, 'b':2} | combine({'a':{'bar':3, 'baz':4}}, recursive=True) }}

出力:
{'a':{'foo':1, 'bar':3, 'baz':4}, 'b':2}

(出典:https://docs.ansible.com/ansible/latest/user_guide/playbooks_filters.html#combining-hashes-dictionaries)

statuavailable typenhancement

最も参考になるコメント

私の2セント:

当初、構成は現在のところ、少し威圧的なTBHに見えます。ユーザーは、実際に何が起こっているのかを理解するために、一連の行全体を読み通す必要があり、エージェント構成テンプレートも確認する必要があります。

構成ファイルをフラット化することが可能な解決策になるかどうか疑問に思っていました-少なくとも短期的な解決策ですか? たとえば、なぜrepowazuh_agent_configの下にあるのですか? repoがトップレベルになれないのはなぜですか? そのようなアプローチは物事を単純化しませんか?

IMOは、一般に、深いネストを元に戻し、構成ファイルをセクションに分割し(ファイルごとに定義されたものを記憶する際に余分な認識オーバーヘッドが発生する可能性があるため、必ずしも複数のファイルを作成する必要はありません)、セクションごとのコメントや特定の構成オプションを追加できます。構成ファイルを全体的に直感的にします。

次のステップに関するアイデアはありますか?

ありがとう。

全てのコメント5件

こんにちは@paulcalabro

これは本当に良い考えです。

この変更は微妙であり、共通のエントリを使用してメインの構成を分離し、さらにカスタマイズ可能なエントリを使用して1つまたは複数の構成を分離できるようにするには、以前のアプローチが必要です。

この変更のテストは、できるだけ早く開始されます。

コラボレーションありがとうございました。あなたのような貢献に感謝します。

よろしくお願いします、

Alfonso Ruiz-Bravo

@SitoRBJフィードバックをありがとう、そして私は完全に同意します、テストが必要です。 そういえば、テストキッチンなどを使ってテストしていますか? いくつかのテストの貢献があれば、皆さんは興味がありますか?

たとえば、InSpecを使用したいくつかの基本的なテスト
https://www.dropbox.com/s/5zx9fb5ezc1wgj9/Screenshot%202018-12-12%2003.32.44.png?dl=0

テストキッチンに関する情報:
https://kitchen.ci

こんにちは@paulcalabro

まだAnsible用のTestKitchenを使用していません。 どうぞ、どんな貢献でも大歓迎です。 テストをご希望の場合は、大歓迎です。

ご関心をお寄せいただき、誠にありがとうございます。大変参考にさせていただきます。

敬具、

Alfonso Ruiz-Bravo

私の2セント:

当初、構成は現在のところ、少し威圧的なTBHに見えます。ユーザーは、実際に何が起こっているのかを理解するために、一連の行全体を読み通す必要があり、エージェント構成テンプレートも確認する必要があります。

構成ファイルをフラット化することが可能な解決策になるかどうか疑問に思っていました-少なくとも短期的な解決策ですか? たとえば、なぜrepowazuh_agent_configの下にあるのですか? repoがトップレベルになれないのはなぜですか? そのようなアプローチは物事を単純化しませんか?

IMOは、一般に、深いネストを元に戻し、構成ファイルをセクションに分割し(ファイルごとに定義されたものを記憶する際に余分な認識オーバーヘッドが発生する可能性があるため、必ずしも複数のファイルを作成する必要はありません)、セクションごとのコメントや特定の構成オプションを追加できます。構成ファイルを全体的に直感的にします。

次のステップに関するアイデアはありますか?

ありがとう。

こんにちは、みんな。 私は、役割のすでに確立された作業方法との互換性を維持しながら、OPが提案したものと同様の何かを提供する提案を含むプルリクエストをレビューのために提出しました。

フィードバックは大歓迎です、ありがとう!

このページは役に立ちましたか?
0 / 5 - 0 評価