Parece que esta delegação foi adicionada aqui:

https://github.com/wazuh/wazuh-ansible/commit/6cb6d3bda84c65508881e293e3403dae94ff24cc#diff -f382f2db5d2e651b16fc4b92ec32e988R90

A tarefa Linux | Create the agent key via rest-API anteriormente fazia o mesmo. Desde então, isso também foi alterado. Acho que isso só foi esquecido.

Oi @singuliere e @paulcalabro eu sou o culpado por esse código. :)
Se você for em frente e remover essa linha, estará assumindo que o cliente que está tentando registrar é capaz de acessar o wazuh-api.
IMHO do ponto de vista da segurança, é melhor permitir que o controlador ansible alcance o wazuh-api do que permitir que cada cliente se conecte à api. A API deve ser protegida e isolada de hosts gerenciados porque pode ser usada para operações maliciosas.
Por exemplo. na minha empresa, nossos clientes wazuh não conseguem acessar a api porque o gerenciador está rodando em rede protegida atrás de um firewall; neste caso, sua lógica de registro não funcionará para nosso cenário.

O que podemos fazer é deixar o usuário escolher que tipo de lógica de registro deseja (ansible-manager -> wazuh-API ou wazuh-client -> wazuh-API) .
Deixe-me pensar em uma solução adequada... :thinking:

Esse é um argumento justo para mantê-lo. Acho que esperava que o registro ocorresse do agente b/c de como funciona o registro authd. Mas, sua abordagem é mais segura. Se isso pudesse ser configurado para lidar com as restrições de rede, seria o ideal.

@angystardust obrigado pela explicação, faz todo o sentido. Atualmente, é inconsistente (porque 689bb8ff35b38fa8258f82db219a4d2565dc5239 removeu um delegate_to e não o outro) e eu assumi erroneamente que a solução certa era aquela que correspondia ao meu próprio caso de uso.

Como @paulcalabro parece concordar com a ideia de torná-lo configurável, alterarei o pull request de acordo.