يبدو أنه تمت إضافة هذا التفويض هنا:

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

كانت المهمة Linux | Create the agent key via rest-API تفعل الشيء نفسه في السابق. وقد تغير ذلك منذ ذلك الحين أيضًا. أعتقد أن هذا قد فات.

مرحبًا singuliere و paulcalabro ، أنا الشخص المسؤول عن هذا الرمز. :)
إذا قمت بإزالة هذا الخط ، فأنت تفترض أن العميل الذي تحاول تسجيله قادر على الوصول إلى wazuh-api.
IMHO من وجهة نظر أمنية ، من الأفضل السماح لوحدة التحكم غير المرغوبة بالوصول إلى wazuh-api بدلاً من السماح لكل عميل بالاتصال بواجهة برمجة التطبيقات. يجب حماية API وعزله عن المضيفين المُدارين لأنه يمكن استخدامه للعمليات الضارة.
علي سبيل المثال. في شركتي ، لا يمكن لعملاء wazuh الوصول إلى api لأن المدير يعمل على شبكة procteded خلف جدار حماية ؛ في هذه الحالة ، لن يعمل منطق التسجيل الخاص بك مع السيناريو الخاص بنا.

ما يمكننا القيام به هو السماح للمستخدم باختيار نوع منطق التسجيل الذي يريده (ansible-manager -> wazuh-API أو wazuh-client -> wazuh-API).
دعني أفكر في حل مناسب ...: التفكير:

هذه حجة عادلة للاحتفاظ بها. أعتقد أنني توقعت أن يتم التسجيل من الوكيل ب / ج لكيفية وظائف تسجيل authd. لكن نهجك أكثر أمانًا. إذا كان من الممكن جعل هذا قابلاً للتكوين لمعالجة قيود الشبكات ، فسيكون ذلك مثاليًا.

شكرا angystardust على التفسير ، فمن المنطقي تماما. إنه غير متسق حاليًا (لأن 689bb8ff35b38fa8258f82db219a4d2565dc5239 أزال أحد المندوبين وليس الآخر) وافترضت خطأً أن الحل الصحيح هو الحل المطابق لحالة الاستخدام الخاصة بي.

نظرًا لأن paulcalabro يبدو أنه يتفق مع فكرة جعلها قابلة للتكوين ، فسوف أقوم بتعديل طلب السحب وفقًا لذلك.