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)
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 !
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
souswazuh_agent_config
? Pourquoirepo
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.