この委任がここに追加されたようです：

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

Linux | Create the agent key via rest-APIタスクは以前は同じことをしていました。 それ以来、それも変更されました。 これは見逃されたと思います。

こんにちは@singuliereと@paulcalabro私はそのコードのせいです。 :)
先に進んでその行を削除すると、登録しようとしているクライアントがwazuh-apiに到達できると想定していることになります。
セキュリティの観点から、私見では、すべてのクライアントをAPIに接続させるよりも、ansibleコントローラーがwazuh-apiに到達できるようにする方が適切です。 APIは悪意のある操作に使用される可能性があるため、管理対象ホストから保護および分離する必要があります。
例えば。 私の会社では、マネージャーがファイアウォールの背後にある保護されたネットワークで実行されているため、wazuhクライアントはAPIに到達できません。 この場合、登録ロジックはこのシナリオでは機能しません。

私たちにできることは、ユーザーが必要な登録ロジックの種類を選択できるようにすることです（ansible-manager-> wazuh-APIまたはwazuh-client-> wazuh-API）。
適切な解決策について考えさせてください...：thinking：

それを維持するための公正な議論です。 authd登録がどのように機能するかというエージェントb / cから登録が行われることを期待していたと思います。 しかし、あなたのアプローチはより安全です。 これをネットワークの制約に対処するように構成できるのであれば、理想的です。

@angystardust説明してくれてありがとう、それは完全に理にかなっています。 現在は一貫性がなく（689bb8ff35b38fa8258f82db219a4d2565dc5239が一方のdelegate_toを削除し、もう一方は削除しなかったため）、正しい解決策は自分のユースケースに一致するものであると誤って想定しました。

@paulcalabroは構成可能にするという考えに同意しているようですので、それに応じてプルリクエストを修正します。