نظرة عامة
يوضّح لك هذا الدليل كيفية التحقق من أن السر المُدوَّر في مزود السحابة لديك يُلتقط في أول إطلاق أتمتة لاحق — بدون إعادة نشر ولا إعادة تشغيل عامل. هذا ذو صلة فقط عندما تكون قد كوّنت بيانات اعتماد مدعومة بـ Workload Identity (AWS، GCP، Azure). تتطلب عمليات نشر بيانات الاعتماد الثابتة إعادة نشر بعد التدوير؛ ليس هناك ما يجب التحقق منه هنا. تستخدم الوصفة أدناه طاقماً صغيراً مستقلاً بأداة واحدة ووكيل واحد ومهمة واحدة. لا يُشير موجه الطاقم أبداً إلى قيمة السر — بدلاً من ذلك، تقرأ أداة القيمة منos.environ وتُفيد ببصمة SHA-256 لما تراه. دوّر السر في مزود السحابة، أطلق مرة أخرى، وتتغير البصمة.
لماذا بصمة وليس القيمة الخام؟ وضع الأسرار الخام في إخراج LLM وسجلات التتبع هو متجه تسرب. البصمة كافية لتأكيد “أن القيمة تغيّرت” دون كتابة القيمة الفعلية في أي مكان يمكن رصده.
المتطلبات المسبقة
قبل تشغيل هذا التحقق:- بيانات اعتماد مزود أسرار مدعومة بـ WI مكوَّنة (AWS، GCP، Azure).
- متغير بيئة على عملية النشر بـ
Secret = true، المفتاحAPI_KEY(أو أي اسم تفضّله — اضبط الأداة أدناه لتطابقه)، يُشير إلى سر في مزود السحابة. - طريقة لتحديث قيمة السر في مزود السحابة (وصول CLI أو وحدة تحكم السحابة).
- طريقة لإطلاق عملية النشر عبر HTTP (curl أو Postman أو علامة التبويب Run في CrewAI Platform).
الخطوة 1 — هيكلة طاقم التحقق
أنشئ مشروع crew كلاسيكيًا لأن هذا المثال يربط أداة Python عبرcrew.py:
الخطوة 2 — إضافة أداة صدى بيانات الاعتماد
استبدلsrc/rotation_verifier/tools/custom_tool.py بأداة تقرأ متغير البيئة المدعوم بسر وتُعيد بصمة:
src/rotation_verifier/tools/credential_echo_tool.py
الخطوة 3 — استبدال تكوينات الوكيل والمهمة الافتراضية
يضم الطاقم وكيلاً واحداً ومهمة واحدة — كلاهما بأوصاف لا تذكر أبداً قيمة السر، لذا تبقى مفاتيح المهام مستقرة عبر عمليات التدوير.src/rotation_verifier/config/agents.yaml
src/rotation_verifier/config/tasks.yaml
الخطوة 4 — توصيل فئة الطاقم
src/rotation_verifier/crew.py
الخطوة 5 — نشر الطاقم وتكوين متغير بيئة السر
انشر هذا الطاقم على CrewAI Platform تماماً كما تنشر أي طاقم آخر. ثم على صفحة Environment Variables الخاصة بعملية النشر:- Key:
API_KEY(يجب أن يطابقENV_VAR_NAMEفي الأداة) - Value Source: بيانات الاعتماد المدعومة بـ WI التي أعدّتها في AWS WI أو GCP WI
- Secret Name: اسم السر في Secret Manager الخاص بمزود السحابة لديك
الخطوة 6 — تشغيل الإطلاق الأول
استبدل<DEPLOYMENT_AUTH_TOKEN> و <DEPLOYMENT_HOST> بالقيم من علامة التبويب Run الخاصة بعملية النشر.
الخطوة 7 — تدوير السر في مزود السحابة
- AWS
- GCP
- Azure
الخطوة 8 — تشغيل إطلاق ثانٍ والمقارنة
ما يتحقق منه هذا — وما لا يتحقق منه
يتحقق من:- يعمل إصدار رمز OIDC الخاص بـ WI من CrewAI Platform.
- تقبل الثقة من جانب السحابة (مزود IAM OIDC لـ AWS، Workload Identity Pool لـ GCP، Federated Identity Credential لـ Azure) الرمز.
- تمتلك الهوية من جانب السحابة (IAM Role / حساب خدمة GCP / Entra App Registration) وصولاً لقراءة السر.
- تصل قيمة السر إلى
os.environلعملية العامل وقت الإطلاق. - تنتشر عمليات التدوير اللاحقة إلى الإطلاق التالي.
- أن طواقم الإنتاج الفعلية لديك تتعامل مع التدوير بسلاسة — مثلاً، المهام طويلة الأمد التي تقرأ متغير البيئة مرة واحدة عند البدء ستستمر في استخدام القيمة القديمة حتى تنتهي المهمة. خطّط وفقاً لذلك: اقرأ الأسرار عند نقطة الاستخدام، وليس عند استيراد الوحدة.
لماذا لا نُشير إلى السر مباشرةً في الموجه؟
سيضع عرض توضيحي يبدو أبسط قيمة السر مباشرةً في وصف مهمة (مثلاً، “البحث عن{api_key}”) ويتفحص الموجه. لا تفعل ذلك. لسببين:
- يُسرّب السر إلى تتبعات استدعاء LLM والسجلات من جانب المزود. يمكن لأي شخص لديه وصول للتتبعات قراءته.
- يُغيّر وصف المهمة في كل إطلاق. تُحدّد CrewAI Platform المهام بتجزئة MD5 للوصف؛ القيمة المُدوَّرة تعني أن التجزئة تتغير لكل إطلاق، مما يكسر ربط المهمة من وقت النشر إلى وقت التشغيل. العَرَض: تُسجَّل سجلات المهام كـ
pending_runإلى الأبد، أو تُسجَّل بعض مهام طاقم متعدد المهام فقط.
الخطوات التالية
- العودة إلى نظرة عامة على مدير الأسرار
- بمجرد التحقق، أَسقط طاقم التحقق. يجب أن تتبع الطواقم الفعلية النمط نفسه: الوصول إلى الأسرار عبر
os.environداخل أداة، وعدم استبدالها أبداً في الموجهات.
