Wazuh-ansible: Benötigen Sie eine einfachere Möglichkeit, ausgewählte Teile der Konfigurationseinstellungen zu überschreiben

Erstellt am 12. Dez. 2018  ·  5Kommentare  ·  Quelle: wazuh/wazuh-ansible

Es wäre ideal, wenn der _wazuh_manager_config_-Hash entweder neu strukturiert oder der Code geändert würde, um ein einfacheres Überschreiben kleinerer Einstellungen zu ermöglichen:

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.

Der Grund dafür ist, dass es nicht einfach ist, einzelne Teile dieser Konfiguration (z. B. Cluster-Einstellungen) zu überschreiben. Alles oder Nichts.
Mit anderen Worten, wenn ich _die meisten_ dieser Variablen in _group_vars/wazuh_managers.yml_ definiert haben möchte und einige Einstellungen mit etwas wie _host_vars/manager01.yml_ überschreiben möchte, ist dies nicht ohne weiteres möglich, ohne die Aufgaben zu ändern.

Derzeit hat jede meiner Host-Variablen eine vollständige Kopie dieses Hashs in ihrer Host-Variablendatei mit einer oder zwei geänderten Einstellungen. Scheint nicht TROCKEN zu sein. Es wäre schön, wenn sich die meisten allgemeinen Einstellungen in einer Gruppenvariablendatei und die ein oder zwei hostspezifischen Einstellungen in einer Hostvariablendatei befinden würden.

Vielleicht gibt es eine Möglichkeit, den combine -Filter zu nutzen, um Teile der größeren Konfiguration einfacher zu überschreiben:

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

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

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

statuavailable typenhancement

Hilfreichster Kommentar

Meine zwei Cent:

Anfangs sieht die Konfiguration, so wie sie derzeit ist, ein wenig einschüchternd aus, TBH, erfordert, dass der Benutzer eine ganze Reihe von Zeilen durchliest und möglicherweise auch die Konfigurationsvorlage des Agenten durchgehen muss, um zu verstehen, was wirklich passiert.

Ich habe mich gefragt, ob das Abflachen der Konfigurationsdatei eine mögliche Lösung sein könnte - zumindest eine kurzfristige? Warum haben Sie zum Beispiel repo unter wazuh_agent_config ? Warum kann repo nicht auf der obersten Ebene sein? Würde ein solcher Ansatz die Dinge nicht vereinfachen?

IMO im Allgemeinen das tiefe Verschachteln rückgängig machen, die Konfigurationsdatei in Abschnitte aufteilen (nicht unbedingt mehrere Dateien erstellen, da dies zu zusätzlichem kognitiven Overhead führen könnte, wenn Sie sich merken, was pro Datei definiert ist) und Kommentare pro Abschnitt und / oder spezifische Konfigurationsoption hinzufügen könnten machen die Konfigurationsdatei insgesamt intuitiver.

Irgendwelche Ideen bezüglich der nächsten Schritte?

Danke.

Alle 5 Kommentare

Hallo @paulcalabro ,

Das ist eine wirklich gute Idee.

Diese Änderung ist heikel und erfordert einen vorherigen Ansatz, um die Konfigurationen in eine Hauptkonfiguration mit den gemeinsamen Einträgen und dann in eine oder mehrere mit anpassbareren Einträgen trennen zu können.

Tests für diese Änderung werden so bald wie möglich eingeleitet.

Vielen Dank für Ihre Mitarbeit, Beiträge wie Ihrer sind sehr willkommen.

Mit freundlichen Grüßen,

Alfonso Ruiz-Bravo

@SitoRBJ Danke für das Feedback und ich stimme voll und ganz zu, Tests sind erforderlich. Apropos, benutzt ihr Test Kitchen oder ähnliches zum Testen? Hättet ihr Interesse an ein paar Testbeiträgen?

zB einige grundlegende Tests mit InSpec
https://www.dropbox.com/s/5zx9fb5ezc1wgj9/Screenshot%202018-12-12%2003.32.44.png?dl=0

Informationen zur Testküche:
https://kitchen.ci

Hallo @paulcalabro ,

Wir verwenden Test Kitchen noch nicht für Ansible. Bitte, jeder Beitrag wird geschätzt. Wenn Sie testen möchten, sind sie herzlich willkommen.

Vielen Dank für Ihr Interesse und Ihre Hilfe, sie ist sehr nützlich für uns.

Mit freundlichen Grüßen,

Alfonso Ruiz-Bravo

Meine zwei Cent:

Anfangs sieht die Konfiguration, so wie sie derzeit ist, ein wenig einschüchternd aus, TBH, erfordert, dass der Benutzer eine ganze Reihe von Zeilen durchliest und möglicherweise auch die Konfigurationsvorlage des Agenten durchgehen muss, um zu verstehen, was wirklich passiert.

Ich habe mich gefragt, ob das Abflachen der Konfigurationsdatei eine mögliche Lösung sein könnte - zumindest eine kurzfristige? Warum haben Sie zum Beispiel repo unter wazuh_agent_config ? Warum kann repo nicht auf der obersten Ebene sein? Würde ein solcher Ansatz die Dinge nicht vereinfachen?

IMO im Allgemeinen das tiefe Verschachteln rückgängig machen, die Konfigurationsdatei in Abschnitte aufteilen (nicht unbedingt mehrere Dateien erstellen, da dies zu zusätzlichem kognitiven Overhead führen könnte, wenn Sie sich merken, was pro Datei definiert ist) und Kommentare pro Abschnitt und / oder spezifische Konfigurationsoption hinzufügen könnten machen die Konfigurationsdatei insgesamt intuitiver.

Irgendwelche Ideen bezüglich der nächsten Schritte?

Danke.

Hallo, alle miteinander. Ich habe eine Pull-Anforderung mit einem Vorschlag zur Überprüfung eingereicht, der etwas Ähnliches wie das bietet, was OP vorgeschlagen hat, und gleichzeitig die Kompatibilität mit den bereits etablierten Arbeitsweisen der Rolle gewahrt bleibt.

Jedes Feedback ist willkommen, danke!

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen