Wazuh-ansible: Necesita una forma más fácil de anular partes seleccionadas de los ajustes de configuración

Creado en 12 dic. 2018  ·  5Comentarios  ·  Fuente: wazuh/wazuh-ansible

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)

statuavailable typenhancement

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 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.

Todos 5 comentarios

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!

¿Fue útil esta página
0 / 5 - 0 calificaciones