الذكاء الاصطناعي

OpenShell: تأمين وكلاء الذكاء الاصطناعي (AI Agents) داخل بيئات Kubernetes

تحليل تقني لمشروع OpenShell، الذي يوفر بيئة تشغيل معزولة (Sandbox) تتيح لمهندسي المنصات تشغيل وكلاء الذكاء الاصطناعي بأمان عبر التحكم الدقيق في صلاحيات الشبكة والملفات والبيانات الحساسة.

04 نوفمبر 2026
3 دقائق قراءة
0 قراءة
certi.news Editorial Team
OpenShell: تأمين وكلاء الذكاء الاصطناعي (AI Agents) داخل بيئات Kubernetes

مع تحول تطبيقات الذكاء الاصطناعي من مجرد نماذج لغوية تجيب على الأسئلة إلى "وكلاء" (Agents) قادرين على تنفيذ مهام فعلية مثل تشغيل الأوامر، وتثبيت الحزم، وقراءة الملفات، برز تحدٍ أمني جديد. هذه الوكلاء، التي تعمل غالباً بناءً على بيانات تم جلبها من الإنترنت، تُعد بمثابة "أكواد غير موثوقة" (Untrusted Code) تمتلك صلاحيات الوصول إلى بيانات حساسة، مما يجعل تشغيلها في بيئات الإنتاج مخاطرة كبيرة ما لم يتم عزلها بدقة.

ما هو مشروع OpenShell؟

يعد OpenShell، وهو مشروع Sandbox تابع لمؤسسة CNCF بدأته شركة NVIDIA، حلاً لتوفير بيئة تشغيل معزولة (Runtime) لهذه الوكلاء. يعتمد المشروع على فكرة وجود "مشرف" (Supervisor) موثوق يعمل خارج بيئة العزل، حيث يتخذ القرارات بشأن ما يمكن للوكيل الوصول إليه بناءً على سياسات محددة مسبقاً عبر ملفات YAML. يوفر OpenShell أربعة مستويات أساسية من التحكم:

  • نظام الملفات (Filesystem): باستخدام تقنية Landlock، يتم تحديد المسارات التي يمكن للوكيل قراءتها أو الكتابة فيها، مما يمنع الوصول إلى ملفات النظام الحساسة.
  • العمليات (Process): يتم تشغيل الوكيل كمستخدم غير جذر (Non-root) مع تطبيق بروتوكول seccomp لتقييد استدعاءات النظام.
  • الشبكة (Network): يتم حظر حركة المرور الخارجية افتراضياً، مع إمكانية السماح بها بناءً على قواعد دقيقة تشمل اسم الملف التنفيذي، المضيف، المنفذ، وحتى طريقة طلب HTTP.
  • البيانات الحساسة (Credentials): لا يرى الوكيل مفاتيح API الحقيقية، بل يرى "عناصر نائبة" (Placeholders)، حيث يقوم المشرف باستبدالها بالمفاتيح الفعلية فقط عند الحاجة وللجهات المصرح لها.

التكامل مع Kubernetes والقدرات المتقدمة

على عكس الحلول التي تحاول تجاوز بنية Kubernetes، يعتمد OpenShell على مشروع Agent Sandbox من SIG Apps. تظهر الوكلاء في النظام ككائنات Kubernetes مألوفة مثل Pods وServices وSecrets. الميزة الجوهرية هنا هي قدرة OpenShell على توفير رؤية على مستوى الطبقة السابعة (L7)؛ فبينما يمكن لسياسات الشبكة التقليدية (NetworkPolicy) السماح لـ Pod بالوصول إلى موقع معين، يمكن لـ OpenShell تحديد ما إذا كان أمر curl مسموحاً له بقراءة البيانات من GitHub ولكن يُمنع من إنشاء (POST) أي مشكلات (Issues) جديدة.

المقارنة التقنية: OpenShell مقابل Agent Substrate

يبرز في المشهد مشروع آخر من CNCF وهو Agent Substrate، ويكمن الفرق الجوهري بينهما في فلسفة التصميم:

  • OpenShell: يركز على الأمان والتحكم الدقيق. هو الخيار الأمثل للوكلاء الذين يحتاجون للوصول إلى أنظمة الإنتاج ويتطلبون سياسات صارمة لكل طلب (Per-request policy).
  • Agent Substrate: يركز على التوسع وخفض التكلفة. يعتمد على تعليق (Suspending) الوكلاء الخاملين بدلاً من تخصيص Pod كامل لكل وكيل، مما يجعله مناسباً للنماذج التي تتطلب كثافة عالية وتكلفة منخفضة.

تشير التوقعات التقنية إلى إمكانية دمج المشروعين مستقبلاً، بحيث يوفر OpenShell سياسات التحكم، بينما يوفر Substrate كفاءة العزل والتوسع.

لماذا يهم هذا التطور لمهندسي المنصات؟

يمثل OpenShell جسراً ضرورياً بين مرونة الذكاء الاصطناعي وصرامة أمن الحوسبة السحابية. بالنسبة لمديري Kubernetes، لم يعد كافياً عزل الحاويات (Containers) التقليدية؛ بل أصبح من الضروري التحكم في سلوك "الوكيل الذكي" داخل الحاوية. من خلال التكامل مع أدوات مثل Kyverno، يمكن للمهندسين فرض سياسات قبول (Admission Control) تضمن أن الوكلاء يعملون فقط بصور (Images) محددة وموثوقة، مع وضع حدود لموارد المعالجة والذاكرة، مما يضمن عدم تحول وكيل ذكاء اصطناعي إلى مصدر لتهديد أمني أو استهلاك مفرط لموارد العنقود (Cluster).

مصدر الخبر
كيف أعددنا هذا الخبر؟

اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة، لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة. اقرأ سياستنا التحريرية.

c
كاتب المقال

certi.news Editorial Team

certi.news Editorial Team

The certi.news editorial team monitors technical sources and reconstructs news, verifying facts and context prior to publication.

من نفس التصنيف

مقالات قد تهمك

عرض كل الأخبار