ثمانية إيصالات بين تأسيس هوية عبء العمل والنتيجة الفعلية

الخلاصة

• يصف draft-ietf-wimse-workload-identity-practices-06 بيانات اعتماد تصدرها المنصة، قصيرة العمر ومقيدة بالجمهور، بدلاً من الأسرار الثابتة التي يديرها التطبيق.
• نجاح التحقق لا يثبت وحده هوية المثيل الحي بدقة، أو حصرية المفتاح، أو زوال النسخ القديمة، أو السماح بالعملية المحددة، أو تنفيذ الطلب، أو تحقق النتيجة المقصودة.

تحسن أمني لا يختصر سلسلة الواقع

ينطلق مشروع ممارسات هوية أعباء العمل من عبء تشغيلي واضح. يجب توزيع كلمات المرور ومفاتيح API وأسرار OAuth المضمنة في التطبيق ثم تدويرها، ويمكن للسارق استخدامها حتى إبطالها. البديل هو أن تلاحظ المنصة بيئة عبء العمل، وتصدر له بيان اعتماد، ثم تسمح باستبداله لدى موفر هوية أو STS برمز وصول مناسب للمورد الخارجي.

تستخدم Kubernetes وSPIFFE وخدمات بيانات السحابة الوصفية وأنظمة CI/CD وشبكات الخدمات وسائل مختلفة. القاسم المشترك هو تقليل السر طويل العمر، لا تحويل رمز واحد إلى وصف كامل لكل حالة تشغيلية.

وتفرض حالة الوثيقة نفسها حداً مهماً. تسجل صفحة Datatracker النسخة 06 كمشروع إنترنت نشط، يستهدف صفة Informational، وقد أرسل إلى IESG وحالته «AD Evaluation::Revised I-D Needed». فهو ليس RFC، ولا شهادة امتثال، ولا إثبات نشر فعلي.

الدليل الأول: ما الذي شاهدته المنصة

قبل التوقيع تختار المنصة الهوية بالاعتماد على host أو IP أو UID أو process أو kernel metadata أو cgroup أو تسميات المنسق. يتجنب SPIFFE طلب سر سابق؛ إذ تتعرف Workload API إلى المتصل من سياقه. يحل ذلك حلقة الحاجة إلى اعتماد للحصول على اعتماد، لكنه لا يجعل selector معصوماً. الخاصية المشتركة على مستوى الجهاز أوسع من رابطة دقيقة بالعملية والمثيل.

ينبغي لإيصال التأسيس أن يحفظ issuer، والخصائص الملحوظة، ونسخة attestor والسياسة، والوقت والقرار. لا يستطيع التوقيع اللاحق إعادة مدخلات لم تسجل أصلاً.

الدليل الثاني: أي مثيل ما زال حياً

تميز وثائق حسابات الخدمة في Kubernetes بين TokenRequest والرموز المرتبطة وTokenReview. قد يطلب kubelet الرموز بحسب إعداد Pod ويسلمها إلى الحاويات، وقد تحمل claims للـnamespace وservice account وPod وnode.

لكن هذه لقطة موقعة وليست حالة مستمرة. قد ينتهي Pod ويحل محله replica بالحساب نفسه، أو تتغير السياسة. التحقق offline يثبت التوقيع وclaims ولا يسأل إن كان object لا يزال موجوداً. ويذكر المشروع صراحة أن الإبطال الناتج من الحذف لا يكتشف إلا عند استخدام TokenReview. يلزم إيصال جديد يحدد المثيل ودورة حياته وepoch الجدولة والسياسة ووقت الفحص.

الدليل الثالث: الإصدار والتسليم

إصدار bytes صحيحة لا يعني أن المستهلك الصحيح حملها. في الملفات يوصي المشروع بالتجديد قبل إبطال القديم، والاستبدال الذري وflush. وتتيح API محلية عبر Unix socket أو loopback أو عنوان link-local التسليم والتحديث عند الطلب. أما environment variables فثابتة وسهلة التسرب إلى المراقبة والتشخيص، ولذلك لا ينبغي استخدامها حين يتاح بديل.

يمنع atomic rename قراءة ملف ناقص، لكنه لا يجبر كل process على إعادة فتح المسار ولا يمحو نسخة الذاكرة. واستجابة API لا تثبت غياب SSRF أو تنصت مكون ذي صلاحية. يجب أن يربط إيصال التسليم القناة والمثيل وhash الاعتماد وإقرار المستهلك.

الدليل الرابع: حيازة لا تعني انفراداً

يمكن إعادة استخدام bearer token المسروق حتى انتهاء صلاحيته. لذلك يفضل المشروع proof of possession. يثبت X.509 التحكم بالمفتاح أثناء handshake، ويمكن ربط JWT بمفتاح. يحدد RFC 8705 رموز وصول OAuth المرتبطة بشهادة mTLS.

هذا يثبت واقعة ضيقة في exchange محدد. لا يثبت أن المفتاح لم ينسخ قط، أو أن process واحداً فقط يستطيع استخدامه، أو أن العملية ما زالت عبء العمل السليم الذي شوهد عند التأسيس. قد يستخدم sidecar أو node agent أو HSM interface المفتاح دون تصديره. تتطلب الحيازة الحصرية أدلة منفصلة على التوليد والتخزين ومسارات الاستعمال والإتلاف.

الدليل الخامس: الجمهور ليس الإذن

يوصي المشروع باعتماد مستقل لكل resource أو Identity Provider وبجمهور واحد لكل JWT. ولا ينبغي إعادة استخدام token مخصص لـKubernetes API في federation خارجية. هذا يقلص نطاق الضرر.

لكن aud يحدد من يجوز له قبول token، ولا يحدد العملية المسموح بها. يقدم RFC 7521 إطار OAuth assertions، ويقدم RFC 7523 ملف JWT bearer. قبول assertion لا يلغي ضرورة فحص الفعل والهدف والمعاملات والحالة الحالية وفق السياسة.

تناول مقال BTW السابق عن Agentic OAuth سلطة اعتماد معاملات نهائية أنشأها model عند أول نقطة تأثير. أما هذا المقال فيفصل سلسلة أخرى: bootstrap وربط runtime والتسليم والحيازة والتدوير والإبطال.

الدليل السادس: هل انتهى التدوير في كل مكان

تقصر الصلاحية القصيرة نافذة الإساءة، لكنها لا تلغي الرمز فوراً. إصدار الجديد قبل إبطال القديم ينشئ فترة overlap مقصودة. وقد يحتفظ التطبيق أو connection pool أو proxy أو retry queue بالقيمة القديمة. كما قد تحفظ backup وsnapshot وimage نسخاً؛ يقلل memory-backed mount الخطر ولا يثبت تنظيفاً شاملاً.

ينبغي للمصدر إبطال اعتماد كل مثيل متوقف أو محذوف، وتقديم status query، إلا أن الآلية الفعلية خارج نطاق المشروع. تحتاج عبارة «تم التدوير» إلى أربعة إيصالات: إصدار الجديد، واعتماد المستهلكين له، ورفض القديم أو انتهاء صلاحيته، وتفريغ caches والمثيلات المعروفة.

الدليلان السابع والثامن: التنفيذ والنتيجة

تقوي مشاريع WIMSE بشأن البنية وبيانات الاعتماد وتوقيعات HTTP وTLS المتبادل أجزاء من المصادقة، لكن أياً منها لا يثبت الأثر التطبيقي.

قد يتحقق المورد من issuer والوقت والجمهور والنوع والمفتاح وclaims ثم يرفض العملية. وقد يقبلها ويفشل قبل commit. وقد يمثل proxy مشترك عدة أعباء عمل. لذلك يجب أن يصدر effecting service إيصال الطلب canonical وقرار authorization والمعاملة وcommit، ثم يصدر مراقب الحالة النهائية إيصال result مستقلاً.

يكشف تمييز Heng Lu بين طبقة الواقع والطبقة الرمزية الخطأ: للرمز ورسالة النجاح معنى، لكن الواقع هو الحالة التي نفذت وشوهدت. وتدعو المواصفات الدنيا والتحقق المحلي وأولوية الشيفرة العاملة إلى إبقاء كل دليل قريباً من النظام القادر على فحصه.

تجيب السلسلة الموثوقة عن ثمانية أسئلة منفصلة: ما الذي شاهدته المنصة؛ أي مثيل ربط؛ ما الذي صدر وسلم؛ أي مفتاح ثبت؛ أي جمهور وعملية سمح بهما؛ أين توقف الاعتماد القديم؛ هل نفذ الطلب؛ وهل ظهرت النتيجة. المطلوب ليس رمزاً شاملاً، بل إيصالات ضيقة يمكن تحديد موضع الفشل بها.