이 위임이 여기에 추가된 것 같습니다.

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

Linux | Create the agent key via rest-API 작업은 이전에 동일한 작업을 수행했습니다. 그 이후로도 변경되었습니다. 나는 이것이 단지 놓쳤다고 생각한다.

안녕하세요 @singuliere 와 @paulcalabro 저는 그 코드에 대해 책임이 있습니다. :)
계속해서 해당 줄을 제거하면 등록하려는 클라이언트가 wazuh-api에 연결할 수 있다고 가정합니다.
보안 관점에서 IMHO는 모든 단일 클라이언트가 API에 연결하도록 하는 것보다 가능한 컨트롤러가 wazuh-api에 도달하도록 허용하는 것이 좋습니다. API는 악의적인 작업에 사용될 수 있으므로 관리 호스트로부터 보호되고 격리되어야 합니다.
예를 들어. 우리 회사에서는 관리자가 방화벽 뒤의 보호된 네트워크에서 실행 중이기 때문에 wazuh 클라이언트가 API에 연결할 수 없습니다. 이 경우 등록 논리가 이 시나리오에서 작동하지 않습니다.

우리가 할 수 있는 일은 사용자가 원하는 종류의 등록 로직(ansible-manager -> wazuh-API 또는 wazuh-client -> wazuh-API)을 선택하게 하는 것입니다.
적절한 해결책을 생각해 보겠습니다... :생각:

유지해야 하는 정당한 주장입니다. authd 등록이 작동하는 방식에 대해 에이전트 b/c에서 등록이 발생할 것으로 예상했습니다. 그러나 접근 방식이 더 안전합니다. 네트워킹 제약 조건을 해결하도록 구성할 수 있다면 이상적일 것입니다.

@angystardust 설명 감사합니다. 완벽합니다. 현재 일관성이 없으며(689bb8ff35b38fa8258f82db219a4d2565dc5239가 하나의 delegate_to를 제거하고 다른 하나는 제거하지 않았기 때문에) 올바른 솔루션이 내 사용 사례와 일치하는 것이라고 잘못 가정했습니다.

@paulcalabro 가 구성 가능하게 만드는 아이디어에 동의하는 것 같으므로 그에 따라 pull 요청을 수정하겠습니다.