Wazuh-ansible: Need Easier Way to Override Select Portions of the Configuration Settings

Created on 12 Dec 2018  ·  5Comments  ·  Source: wazuh/wazuh-ansible

It would be ideal if the _wazuh_manager_config_ hash was either restructured or the code was modified to allow for easier overriding of smaller chunks of settings:

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.

The reason being is that it's not easy to override individual portions of this config (e.g. cluster settings). It's all or nothing.
In other words, if I want to have _most_ of these variables defined in _group_vars/wazuh_managers.yml_ and override a couple settings using something like _host_vars/manager01.yml_ it's not easily possible w/o modifying the tasks.

Currently, each of my host variables, has a complete copy of this hash in their host variable file with one or two settings changed. Doesn't seem DRY. It would be nice if most of the common settings were in a group variable file and the one or two settings specific to the host were in a host variable file.

Maybe there's a way to leverage the combine filter to allow for easier overrides of portions of the bigger config:

e.g.
{{ {'a':{'foo':1, 'bar':2}, 'b':2} | combine({'a':{'bar':3, 'baz':4}}, recursive=True) }}

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

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

statuavailable typenhancement

Most helpful comment

My two cents:

Initially, the configuration, as it currently stands, looks a bit intimidating TBH, requiring the user to read through a whole bunch of lines and possibly having to go through the agent configuration template, as well, in order to understand what's really happening.

I was wondering whether flattening the configuration file could be a possible solution - a short-term one at least? For instance, why have repo under wazuh_agent_config? Why can't repo be at the top level? Wouldn't such an approach simplify things?

IMO, in general, undoing the deep nesting, splitting the configuration file in sections (not necessarily creating multiple files, since that could introduce extra cognitive overhead in remembering what's defined per file), and adding comments per section and/or specific configuration option could make the configuration file more intuitive overall.

Any ideas regarding next steps?

Thanks.

All 5 comments

Hello @paulcalabro,

This is a really good idea.

This change is delicate and requires a previous approach to be able to separate the configurations in a main one with the common entries and then in one or several with more customizable entries.

Tests for this change will be initiated as soon as possible.

Thank you very much for your collaboration, contributions like yours are much appreciated.

Best regards,

Alfonso Ruiz-Bravo

@SitoRBJ Thanks for the feedback and I totally agree, testing is needed. Speaking of which, do you guys use Test Kitchen or anything similar for testing? Would you guys be interested if some test contributions?

e.g. some basic tests using InSpec
https://www.dropbox.com/s/5zx9fb5ezc1wgj9/Screenshot%202018-12-12%2003.32.44.png?dl=0

Information regarding Test Kitchen:
https://kitchen.ci

Hello @paulcalabro,

We are not using Test Kitchen for Ansible yet. Please, any contribution is appreciated. If you would like to test, they are more than welcome.

Thank you very much for your interest and for your help, it is very useful to us.

Kind regards,

Alfonso Ruiz-Bravo

My two cents:

Initially, the configuration, as it currently stands, looks a bit intimidating TBH, requiring the user to read through a whole bunch of lines and possibly having to go through the agent configuration template, as well, in order to understand what's really happening.

I was wondering whether flattening the configuration file could be a possible solution - a short-term one at least? For instance, why have repo under wazuh_agent_config? Why can't repo be at the top level? Wouldn't such an approach simplify things?

IMO, in general, undoing the deep nesting, splitting the configuration file in sections (not necessarily creating multiple files, since that could introduce extra cognitive overhead in remembering what's defined per file), and adding comments per section and/or specific configuration option could make the configuration file more intuitive overall.

Any ideas regarding next steps?

Thanks.

Hello everyone. I submitted for review a pull request with a proposal that provides something similar to what OP suggested, while keeping compatibility with the role's already established ways of working.

Any feedback is welcome, thanks!

Was this page helpful?
0 / 5 - 0 ratings