صندوق عزل الوكيل مسألة قدرات قبل أن يكون مسألة حاويات

الحاويات تحدّ نطاق الضرر، لا السلوك

عندما تبدأ الفرق في عزل وكيل داخل صندوق، تبدأ المحادثة عادةً بتقنية العزل. Firecracker microVMs، وgVisor، وملفات seccomp، وحدود cgroup، وأنظمة ملفات جذرية للقراءة فقط. هذه أمور حقيقية ومفيدة، لكنها تجيب عن سؤال أضيق مما يفترضه معظم الناس. فهي تحدّ أين يمكن أن يقع الضرر. لكنها لا تحدّ ما يُسمح للوكيل بمحاولته.

صندوق عزل يتشارك مساحة أسماء شبكة المضيف قد تنازل بالفعل عن الجزء المثير من المشكلة. يظل الوكيل قادراً على الوصول إلى خدمة البيانات الوصفية الداخلية، وسجل الحزم، ومزوّد النموذج، وويكي الشركة، وأي خدمة تثق بعنوان IP الخاص بالمضيف. عزل نظام الملفات لا يقيّد وكيلاً سطح قدراته الحقيقي هو HTTP الصادر بالإضافة إلى مجموعة من بيانات اعتماد API. يمكنك تركيب نظام الملفات الجذري للقراءة فقط وتراقب الوكيل وهو يسرّب قاعدة بيانات عبر مسار خروج مسموح، لأن القدرة المهمة لم تكن أبداً واصف الملف. كانت الرمز.

لهذا السبب tends تأطير الحاويات أولاً إلى إنتاج صناديق عزل تبدو صارمة وتتصرف بتسامح. وحدة التحليل خاطئة. الوحدة المفيدة هي مجموعة القدرات لكل خطوة، وهذه المجموعة تتغير مع تقدم التشغيل.

ميزانية القدرات كأساس التصميم

الأساس التصميمي الجدير بالبناء عليه هو ميزانية قدرات مرتبطة بكل خطوة من التشغيل. الخطوة وحدة عمل محدودة: استدعاء أداة واحد، أو دور نموذج واحد، أو تنقل متصفح واحد، أو أمر مشغّل واحد. تعلن كل خطوة القدرات التي تحتاجها. يمنح وقت التشغيل تلك القدرات بالضبط لمدة الخطوة ولا بعدها.

آلية ملموسة تبدو هكذا. يحتفظ المنسّق بمحرك سياسات ووسيط بيانات اعتماد قصير الأجل. قبل تنفيذ خطوة، يقدّم الوكيل طلب قدرة: مستند منظّم يسمّي المورد، والعملية، والنطاق المقصود.

{
  "step": "fetch_invoice_pdf",
  "capabilities": [
    {"type": "http", "host": "billing.internal", "methods": ["GET"], "paths": ["/invoices/*/pdf"]},
    {"type": "fs", "mount": "/tmp/run-7f3a", "mode": "write"}
  ],
  "ttl_seconds": 30
}

يقيّم محرك السياسات الطلب مقابل الميزانية المتراكمة للتشغيل والنطاق المعلن للمهمة. إذا اجتاز الطلب، يصدر الوسيط بيانات اعتماد محدودة بذلك المضيف والطريقة والمسار، مع TTL بالثواني. تُنفّذ الخطوة. تنتهي صلاحية بيانات الاعتماد. تبدأ الخطوة التالية من الصفر ويجب أن تطلب مجدداً.

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

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

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

وكلاء المتصفح وسطح المكتب

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

عملياً، هذا يعني أن السائق يعترض التنقل، وإرسال النماذج، وتنزيل الملفات، والوصول إلى الحافظة، وأي استدعاء يعبر حدود الثقة، ويفحص كل منها مقابل القدرات المعلنة للخطوة الحالية. خطوة تعلن "اقرأ صفحة الأسعار" يجب ألا تكون قادرة على إرسال نموذج، حتى لو قدّم DOM واحداً. هذه سياسة على مستوى السائق، وهي الطبقة الوحيدة التي يكون فيها الفحص ذا معنى، لأنها الطبقة التي تنفّذ الفعل فعلاً.

الوكلاء الفيزيائيون والروبوتات

يضيف الوكلاء الفيزيائيون بُعداً ثانياً للميزانية لا تمتلكه صناديق العزل البرمجية: غلاف الحركة وحدود القوة. تتضمن مجموعة قدرات الذراع الروبوتية ليس فقط أي API يمكنه استدعاؤه بل إلى أين يمكنه التحرك، وبأي سرعة، وبأي قوة. تُفرض هذه الحدود بواسطة المتحكم، ويجب تحديد نطاقها لكل خطوة بالطريقة نفسها. خطوة تعلن "التقط الجسم من الصندوق A" يجب أن تحمل غلاف حركة يستبعد الصندوق B وسقف قوة مناسباً لفئة الجسم. التصعيد إلى غلاف أوسع هو قرار سياسة مسجّل، تماماً كما هو الحال مع قدرات الشبكة.

سبب أهمية هذا هو أن أنماط الفشل غير قابلة للعكس. رمز HTTP مُبطل يوقف تسريب بيانات. غلاف حركة مُبطل يوقف ذراعاً في منتصف المسار، وهي مشكلة هندسية مختلفة تتضمن ملفات تباطؤ وحالات آمنة. نموذج القدرات هو نفسه؛ دلالات الإبطال ليست كذلك.

أُطر التقييم

يجب أن تشغّل أُطر التقييم نفس فرض القدرات الذي يعمل في الإنتاج، وإلا فنتيجة الاختبار ليست دليلاً. هذه هي الخطوة الأكثر إغفالاً والأكثر تقويضاً لقيمة التقييم. إذا منح الإطار الوكيل مجموعة شاملة من قدرات الإنتاج، فإن معدل نجاحه المقاس يعكس نظاماً غير موجود. وإذا فرض الإطار مجموعة فرعية، سيبدو الوكيل فاشلاً في مهام كان سينجح فيها في الإنتاج.

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

ما الذي يغيّره هذا

سؤال الحاوية لا يختفي. لا تزال تقنية العزل تحدد ما يحدث عندما يفشل فحص قدرة ويقوم الوكيل بشيء غير متوقع رغم ذلك. الدفاع في العمق هو المقصود. لكن الحاوية هي الخط الثاني، لا الأول. الخط الأول هو ميزانية قدرات تُعلن لكل خطوة، وتُمنح لمدة تلك الخطوة، ولا تُصعّد إلا عبر قرارات سياسة مسجّلة، وقابلة للإبطال بينما التشغيل لا يزال جارياً.

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