Sería ideal si el hash _wazuh_manager_config_ se reestructurara o se modificara el código para permitir una anulación más fácil de fragmentos más pequeños de configuración:
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 razón es que no es fácil anular partes individuales de esta configuración (por ejemplo, la configuración del clúster). Es todo o nada.
En otras palabras, si quiero tener _la mayoría_ de estas variables definidas en _group_vars/wazuh_managers.yml_ y anular un par de configuraciones usando algo como _host_vars/manager01.yml_ no es posible fácilmente sin modificar las tareas.
Actualmente, cada una de mis variables de host tiene una copia completa de este hash en su archivo de variables de host con una o dos configuraciones modificadas. No parece SECO. Sería bueno si la mayoría de las configuraciones comunes estuvieran en un archivo de variables de grupo y una o dos configuraciones específicas para el host estuvieran en un archivo de variables de host.
Tal vez haya una manera de aprovechar el filtro combine
para permitir anulaciones más fáciles de partes de la configuración más grande:
p.ej
{{ {'a':{'foo':1, 'bar':2}, 'b':2} | combine({'a':{'bar':3, 'baz':4}}, recursive=True) }}
Producción:
{'a':{'foo':1, 'bar':3, 'baz':4}, 'b':2}
(Fuente: https://docs.ansible.com/ansible/latest/user_guide/playbooks_filters.html#combining-hashes-dictionaries)
Hola @paulcalabro ,
Esta es una muy buena idea.
Este cambio es delicado y requiere un planteamiento previo para poder separar las configuraciones en una principal con las entradas comunes y luego en una o varias con entradas más personalizables.
Las pruebas para este cambio se iniciarán lo antes posible.
Muchas gracias por su colaboración, se agradecen mucho aportes como el suyo.
Atentamente,
Alfonso Ruiz-Bravo
@SitoRBJ Gracias por los comentarios y estoy totalmente de acuerdo, se necesitan pruebas. Hablando de eso, ¿ustedes usan Test Kitchen o algo similar para probar? ¿Les interesarían algunas contribuciones de prueba?
por ejemplo, algunas pruebas básicas usando InSpec
https://www.dropbox.com/s/5zx9fb5ezc1wgj9/Screenshot%202018-12-12%2003.32.44.png?dl=0
Información sobre Test Kitchen:
https://cocina.ci
Hola @paulcalabro ,
Todavía no estamos usando Test Kitchen para Ansible. Por favor, se agradece cualquier aporte. Si desea probar, son más que bienvenidos.
Muchas gracias por tu interés y por tu ayuda, nos es de mucha utilidad.
Saludos cordiales,
Alfonso Ruiz-Bravo
Mis dos centavos:
Inicialmente, la configuración, tal como está actualmente, parece un poco intimidante TBH, lo que requiere que el usuario lea un montón de líneas y posiblemente también tenga que pasar por la plantilla de configuración del agente para comprender lo que realmente está sucediendo.
Me preguntaba si aplanar el archivo de configuración podría ser una posible solución, ¿al menos a corto plazo? Por ejemplo, ¿por qué tener repo
debajo wazuh_agent_config
? ¿Por qué repo
puede estar en el nivel superior? ¿Este enfoque no simplificaría las cosas?
En mi opinión, en general, deshacer el anidamiento profundo, dividir el archivo de configuración en secciones (no necesariamente crear varios archivos, ya que eso podría generar una sobrecarga cognitiva adicional al recordar lo que se define por archivo), y agregar comentarios por sección y/o opción de configuración específica podría hacer que el archivo de configuración sea más intuitivo en general.
¿Alguna idea sobre los próximos pasos?
Gracias.
Hola, todos. Envié para revisión una solicitud de incorporación de cambios con una propuesta que proporciona algo similar a lo que sugirió OP, manteniendo la compatibilidad con las formas de trabajo ya establecidas del rol.
Cualquier comentario es bienvenido, gracias!
Comentario más útil
Mis dos centavos:
Inicialmente, la configuración, tal como está actualmente, parece un poco intimidante TBH, lo que requiere que el usuario lea un montón de líneas y posiblemente también tenga que pasar por la plantilla de configuración del agente para comprender lo que realmente está sucediendo.
Me preguntaba si aplanar el archivo de configuración podría ser una posible solución, ¿al menos a corto plazo? Por ejemplo, ¿por qué tener
repo
debajowazuh_agent_config
? ¿Por quérepo
puede estar en el nivel superior? ¿Este enfoque no simplificaría las cosas?En mi opinión, en general, deshacer el anidamiento profundo, dividir el archivo de configuración en secciones (no necesariamente crear varios archivos, ya que eso podría generar una sobrecarga cognitiva adicional al recordar lo que se define por archivo), y agregar comentarios por sección y/o opción de configuración específica podría hacer que el archivo de configuración sea más intuitivo en general.
¿Alguna idea sobre los próximos pasos?
Gracias.