Похоже, эта делегация была добавлена ​​сюда:

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

Задача Linux | Create the agent key via rest-API ранее делала то же самое. С тех пор это также было изменено. Думаю, это просто пропустили.

Привет @singuliere и @paulcalabro Я виноват в этом коде. :)
Если вы удалите эту строку, вы предполагаете, что клиент, которого вы пытаетесь зарегистрировать, может получить доступ к wazuh-api.
ИМХО, с точки зрения безопасности, лучше позволить контроллеру ansible получить доступ к wazuh-api, чем позволить каждому клиенту подключаться к API. API должен быть защищен и изолирован от управляемых хостов, поскольку его можно использовать для вредоносных операций.
Например. в моей компании наши клиенты wazuh не могут получить доступ к API, потому что менеджер работает в защищенной сети за брандмауэром; в этом случае ваша логика регистрации не будет работать для нашего сценария.

Что мы можем сделать, так это позволить пользователю выбирать, какую логику регистрации он хочет (ansible-manager -> wazuh-API или wazuh-client -> wazuh-API).
Позвольте мне подумать о правильном решении... :thinking:

Это веский аргумент в пользу сохранения. Я думаю, что я ожидал, что регистрация будет происходить от агента b/c того, как работает регистрация authd. Но ваш подход более безопасен. Если бы это можно было настроить для устранения сетевых ограничений, это было бы идеально.

@angystardust спасибо за объяснение, оно имеет смысл. В настоящее время это непоследовательно (поскольку 689bb8ff35b38fa8258f82db219a4d2565dc5239 удалил один delegate_to, а не другой), и я ошибочно предположил, что правильным решением было то, которое соответствует моему собственному варианту использования.

Поскольку @paulcalabro , кажется, согласен с идеей сделать его настраиваемым, я соответствующим образом изменю запрос на вытягивание.