Wazuh-ansible: Besoin d'un moyen plus simple de remplacer certaines parties des paramètres de configuration

Créé le 12 déc. 2018  ·  5Commentaires  ·  Source: wazuh/wazuh-ansible

Ce serait idéal si le hachage _wazuh_manager_config_ était restructuré ou si le code était modifié pour permettre un remplacement plus facile de petits morceaux de paramètres :

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.

La raison en est qu'il n'est pas facile de remplacer des parties individuelles de cette configuration (par exemple, les paramètres de cluster). C'est tout ou rien.
En d'autres termes, si je veux avoir _la plupart_ de ces variables définies dans _group_vars/wazuh_managers.yml_ et remplacer quelques paramètres en utilisant quelque chose comme _host_vars/manager01.yml_, ce n'est pas facilement possible sans modifier les tâches.

Actuellement, chacune de mes variables hôtes a une copie complète de ce hachage dans son fichier de variable hôte avec un ou deux paramètres modifiés. Ne semble pas SEC. Ce serait bien si la plupart des paramètres communs se trouvaient dans un fichier de variable de groupe et que le ou les deux paramètres spécifiques à l'hôte se trouvaient dans un fichier de variable hôte.

Peut-être existe-t-il un moyen de tirer parti du filtre combine pour permettre des remplacements plus faciles de parties de la plus grande configuration :

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

Sortir:
{'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

Commentaire le plus utile

Mes deux centimes:

Au départ, la configuration, telle qu'elle se présente actuellement, semble un peu intimidante TBH, obligeant l'utilisateur à lire tout un tas de lignes et éventuellement à passer par le modèle de configuration de l'agent, afin de comprendre ce qui se passe réellement.

Je me demandais si l'aplatissement du fichier de configuration pouvait être une solution possible - du moins à court terme ? Par exemple, pourquoi avoir repo sous wazuh_agent_config ? Pourquoi repo ne peut-il pas être au plus haut niveau ? Une telle approche ne simplifierait-elle pas les choses ?

IMO, en général, annuler l'imbrication profonde, diviser le fichier de configuration en sections (sans nécessairement créer plusieurs fichiers, car cela pourrait introduire une surcharge cognitive supplémentaire en se souvenant de ce qui est défini par fichier), et ajouter des commentaires par section et/ou option de configuration spécifique pourrait rendre le fichier de configuration globalement plus intuitif.

Des idées concernant les prochaines étapes ?

Merci.

Tous les 5 commentaires

Bonjour @paulcalabro ,

C'est une très bonne idée.

Ce changement est délicat et nécessite une approche préalable pour pouvoir séparer les configurations en une principale avec les entrées communes puis en une ou plusieurs avec des entrées plus personnalisables.

Les tests pour ce changement seront lancés dès que possible.

Merci beaucoup pour votre collaboration, des contributions comme la vôtre sont très appréciées.

Cordialement,

Alfonso Ruiz-Bravo

@SitoRBJ Merci pour les commentaires et je suis totalement d'accord, des tests sont nécessaires. En parlant de cela, utilisez-vous Test Kitchen ou quelque chose de similaire pour les tests ? Seriez-vous intéressés si certaines contributions de test ?

par exemple quelques tests de base utilisant InSpec
https://www.dropbox.com/s/5zx9fb5ezc1wgj9/Screenshot%202018-12-12%2003.32.44.png?dl=0

Informations concernant Test Kitchen :
https://cuisine.ci

Bonjour @paulcalabro ,

Nous n'utilisons pas encore Test Kitchen for Ansible. S'il vous plaît, toute contribution est appréciée. Si vous souhaitez tester, ils sont plus que bienvenus.

Merci beaucoup pour votre intérêt et pour votre aide, cela nous est très utile.

Sincères amitiés,

Alfonso Ruiz-Bravo

Mes deux centimes:

Au départ, la configuration, telle qu'elle se présente actuellement, semble un peu intimidante TBH, obligeant l'utilisateur à lire tout un tas de lignes et éventuellement à passer par le modèle de configuration de l'agent, afin de comprendre ce qui se passe réellement.

Je me demandais si l'aplatissement du fichier de configuration pouvait être une solution possible - du moins à court terme ? Par exemple, pourquoi avoir repo sous wazuh_agent_config ? Pourquoi repo ne peut-il pas être au plus haut niveau ? Une telle approche ne simplifierait-elle pas les choses ?

IMO, en général, annuler l'imbrication profonde, diviser le fichier de configuration en sections (sans nécessairement créer plusieurs fichiers, car cela pourrait introduire une surcharge cognitive supplémentaire en se souvenant de ce qui est défini par fichier), et ajouter des commentaires par section et/ou option de configuration spécifique pourrait rendre le fichier de configuration globalement plus intuitif.

Des idées concernant les prochaines étapes ?

Merci.

Bonjour à tous. J'ai soumis pour examen une demande d'extraction avec une proposition qui fournit quelque chose de similaire à ce que OP a suggéré, tout en gardant la compatibilité avec les méthodes de travail déjà établies du rôle.

Tout commentaire est le bienvenu, merci !

Cette page vous a été utile?
0 / 5 - 0 notes