Wazuh-ansible: Precisa de uma maneira mais fácil de substituir partes selecionadas das definições de configuração

Criado em 12 dez. 2018  ·  5Comentários  ·  Fonte: wazuh/wazuh-ansible

Seria ideal se o hash _wazuh_manager_config_ fosse reestruturado ou o código fosse modificado para permitir a substituição mais fácil de partes menores de configurações:

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.

A razão é que não é fácil substituir partes individuais desta configuração (por exemplo, configurações de cluster). É tudo ou nada.
Em outras palavras, se eu quiser ter _most_ dessas variáveis ​​definidas em _group_vars/wazuh_managers.yml_ e substituir algumas configurações usando algo como _host_vars/manager01.yml_ não é facilmente possível sem modificar as tarefas.

Atualmente, cada uma das minhas variáveis ​​de host tem uma cópia completa desse hash em seu arquivo de variável de host com uma ou duas configurações alteradas. Não parece SECO. Seria bom se a maioria das configurações comuns estivesse em um arquivo de variável de grupo e uma ou duas configurações específicas para o host estivessem em um arquivo de variável de host.

Talvez haja uma maneira de aproveitar o filtro combine para permitir substituições mais fáceis de partes da configuração maior:

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

Saída:
{'a':{'foo':1, 'bar':3, 'baz':4}, 'b':2}

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

statuavailable typenhancement

Comentários muito úteis

Meus dois centavos:

Inicialmente, a configuração, como está atualmente, parece um pouco intimidante TBH, exigindo que o usuário leia um monte de linhas e possivelmente tenha que passar pelo modelo de configuração do agente também, para entender o que realmente está acontecendo.

Eu queria saber se achatar o arquivo de configuração poderia ser uma solução possível - pelo menos uma de curto prazo? Por exemplo, por que ter repo abaixo wazuh_agent_config ? Por que repo não pode estar no nível mais alto? Essa abordagem não simplificaria as coisas?

IMO, em geral, desfazendo o aninhamento profundo, dividindo o arquivo de configuração em seções (não necessariamente criando vários arquivos, pois isso poderia introduzir sobrecarga cognitiva extra ao lembrar o que está definido por arquivo) e adicionar comentários por seção e/ou opção de configuração específica poderia tornar o arquivo de configuração mais intuitivo em geral.

Alguma ideia sobre os próximos passos?

Obrigado.

Todos 5 comentários

Olá @paulcalabro ,

Isto é mesmo uma ótima ideia.

Essa mudança é delicada e requer uma abordagem prévia para poder separar as configurações em uma principal com as entradas comuns e depois em uma ou várias com entradas mais personalizáveis.

Os testes para essa alteração serão iniciados assim que possível.

Muito obrigado por sua colaboração, contribuições como a sua são muito apreciadas.

Atenciosamente,

Alfonso Ruiz Bravo

@SitoRBJ Obrigado pelo feedback e concordo totalmente, é necessário testar. Falando nisso, vocês usam Test Kitchen ou algo similar para testar? Vocês estariam interessados ​​se algumas contribuições de teste?

por exemplo, alguns testes básicos usando InSpec
https://www.dropbox.com/s/5zx9fb5ezc1wgj9/Screenshot%202018-12-12%2003.32.44.png?dl=0

Informações sobre a Cozinha de Teste:
https://cozinha.ci

Olá @paulcalabro ,

Ainda não estamos usando o Test Kitchen para Ansible. Por favor, qualquer contribuição é apreciada. Se você quiser testar, eles são mais que bem-vindos.

Muito obrigado pelo seu interesse e pela sua ajuda, é muito útil para nós.

Atenciosamente,

Alfonso Ruiz Bravo

Meus dois centavos:

Inicialmente, a configuração, como está atualmente, parece um pouco intimidante TBH, exigindo que o usuário leia um monte de linhas e possivelmente tenha que passar pelo modelo de configuração do agente também, para entender o que realmente está acontecendo.

Eu queria saber se achatar o arquivo de configuração poderia ser uma solução possível - pelo menos uma de curto prazo? Por exemplo, por que ter repo abaixo wazuh_agent_config ? Por que repo não pode estar no nível mais alto? Essa abordagem não simplificaria as coisas?

IMO, em geral, desfazendo o aninhamento profundo, dividindo o arquivo de configuração em seções (não necessariamente criando vários arquivos, pois isso poderia introduzir sobrecarga cognitiva extra ao lembrar o que está definido por arquivo) e adicionar comentários por seção e/ou opção de configuração específica poderia tornar o arquivo de configuração mais intuitivo em geral.

Alguma ideia sobre os próximos passos?

Obrigado.

Olá a todos. Enviei para revisão um pull request com uma proposta que fornece algo semelhante ao que o OP sugeriu, mantendo a compatibilidade com as formas de trabalho já estabelecidas da função.

Qualquer feedback é bem-vindo, obrigado!

Esta página foi útil?
0 / 5 - 0 avaliações