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.

原因是覆盖此配置的各个部分(例如集群设置)并不容易。 要么全有,要么全无。
换句话说,如果我想在 _group_vars/wazuh_managers.yml_ 中定义这些变量中的 _most_ 并使用 _host_vars/manager01.yml_ 之类的东西覆盖几个设置,那么不修改任务就不容易。

目前,我的每个主机变量在其主机变量文件中都有这个哈希的完整副本,其中更改了一个或两个设置。 看起来不干。 如果大多数常用设置都在一个组变量文件中,并且特定于主机的一两个设置在一个主机变量文件中,那就太好了。

也许有一种方法可以利用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

最有用的评论

我的两分钱:

最初,目前的配置看起来有点吓人 TBH,需要用户阅读一大堆行,并且可能还必须通过代理配置模板,才能了解真正发生的事情。

我想知道扁平化配置文件是否可能是一种可能的解决方案——至少是一个短期的解决方案? 例如,为什么在wazuh_agent_config repo #$ ? 为什么repo不能处于顶层? 这样的方法不会简化事情吗?

IMO,一般来说,撤消深度嵌套,将配置文件分成多个部分(不一定创建多个文件,因为这可能会在记住每个文件定义的内容时引入额外的认知开销),并为每个部分和/或特定配置选项添加注释可以使配置文件整体更直观。

关于下一步的任何想法?

谢谢。

所有5条评论

你好@paulcalabro

这真是个好主意。

这种变化是微妙的,需要一种以前的方法来将主要的配置与公共条目分开,然后在一个或多个具有更多可定制条目的配置中分开。

将尽快启动针对此更改的测试。

非常感谢您的合作,非常感谢您的贡献。

最好的祝福,

阿方索·鲁伊斯-布拉沃

@SitoRBJ感谢您的反馈,我完全同意,需要进行测试。 说到这,你们使用Test Kitchen或类似的东西进行测试吗? 如果有一些测试贡献,你们会感兴趣吗?

例如使用 InSpec 的一些基本测试
https://www.dropbox.com/s/5zx9fb5ezc1wgj9/Screenshot%202018-12-12%2003.32.44.png?dl=0

测试厨房的相关资料:
https://kitchen.ci

你好@paulcalabro

我们还没有为 Ansible 使用 Test Kitchen。 请,任何贡献表示赞赏。 如果您想测试,他们非常欢迎。

非常感谢您的关注和帮助,这对我们非常有用。

亲切的问候,

阿方索·鲁伊斯-布拉沃

我的两分钱:

最初,目前的配置看起来有点吓人 TBH,需要用户阅读一大堆行,并且可能还必须通过代理配置模板,才能了解真正发生的事情。

我想知道扁平化配置文件是否可能是一种可能的解决方案——至少是一个短期的解决方案? 例如,为什么在wazuh_agent_config repo #$ ? 为什么repo不能处于顶层? 这样的方法不会简化事情吗?

IMO,一般来说,撤消深度嵌套,将配置文件分成多个部分(不一定创建多个文件,因为这可能会在记住每个文件定义的内容时引入额外的认知开销),并为每个部分和/或特定配置选项添加注释可以使配置文件整体更直观。

关于下一步的任何想法?

谢谢。

大家好。 我提交了一个拉取请求以供审查,该提案提供了类似于 OP 建议的内容,同时保持与角色已经建立的工作方式的兼容性。

欢迎任何反馈,谢谢!

此页面是否有帮助?
0 / 5 - 0 等级