LLM تولّد ملفات manifest لـ Kubernetes تعمل لكنها مليئة بالثغرات: كيف تكتشفها قبل النشر

يبدو الـ manifest الذي أنتجته الشبكة العصبية سليماً تماماً: مسافات بادئة صحيحة، وحقول مألوفة، و`kubectl apply` لا يعترض، والـ pod ينتقل إلى حالة Running. وهنا تحديداً، بحسب إعلان التحليل على Habr، يكمن الفخ. فالمشكلات تظهر لاحقاً، في production. والسبب أن نماذج LLM تعيد إنتاج إعدادات قديمة وغير آمنة، وهي كثيرة في بيانات التدريب. ولتوضيح حجم المشكلة: أُزيل Ingress من `extensions/v1beta1` في Kubernetes 1.22، واختفى PodSecurityPolicy في 1.25. ومع ذلك لا تزال الدروس القديمة التي تستخدم هذه الكائنات متاحة على الإنترنت، والنموذج يستشهد بها بسهولة.

تنبيه: لا يحتوي الإعلان المتاح على تفاصيل، بل على نقاط رئيسية فقط. نعتمد فيما يلي عليها وعلى الخصائص المعروفة عموماً في Kubernetes.

لماذا يشكّل YAML المعقول المظهر خطراً

يُحسّن النموذج احتمال الرمز التالي، لا أمان الكلاستر. فسنوات من الأمثلة العامة وإجابات المنتديات والمستودعات التي تضم إعدادات تجريبية تعلّمه الـ manifest «النموذجي». والـ manifest النموذجي في التوثيق بسيط عمداً: بلا حدود للموارد، وبلا قيود أمنية، وغالباً بوسم `latest`. هذا مقبول لبيئة تعليمية، لكنه غير مقبول لكلاستر إنتاجي.

ولا يرصد التحقق من المخطط هذه المشكلة. فهو يفحص الشكل فقط: هل الحقول موجودة وهل الأنواع متطابقة. أما حاوية تعمل بصلاحيات root مع `privileged: true` فهي صحيحة شكلياً. وكذلك الـ manifest الخالي من فحوص readiness صحيح، لكن الحركة ستصل إلى الـ pod قبل أن يصبح التطبيق جاهزاً لها.

فيما يلي مجموعة العيوب الكلاسيكية التي تُكتشف عند مراجعة YAML من هذا النوع:

• `apiVersion` لواجهات API محذوفة أو معلنة قديمة، ما يعطّل الـ manifest عند ترقية الكلاستر؛
• صور بوسم `latest` بدلاً من إصدار ثابت أو digest؛
• غياب `resources.requests` و`limits`، أي خطر «الجار الصاخب» وإنهاء العمليات بسبب OOM؛
• التشغيل بصلاحيات root، وغياب `runAsNonRoot` و`allowPrivilegeEscalation: false` و`readOnlyRootFilesystem`؛
• غياب فحوص liveness وreadiness؛
• الأسرار مكتوبة مباشرة في `env` بدلاً من Secret أو مخزن خارجي؛
• `hostNetwork` و`hostPath` و`privileged` منقولة من أمثلة التنقيح؛
• خدمات مكشوفة للخارج وغياب NetworkPolicy.

أين تُقام الحواجز

المستوى الأول هو التحقق من المخطط وفق إصدار كلاستر محدد. ولهذا تصلح أداتا kubeconform و`kubectl apply --dry-run=server`: فالـ dry-run من جهة الخادم يمرّر الـ manifest عبر خادم API ومتحكمات admission دون إنشاء أي كائنات. ولاكتشاف واجهات API القديمة تتوفر أداة Pluto.

المستوى الثاني هو التحليل الساكن للأمان وأفضل الممارسات: kube-linter وCheckov وTrivy (وضع config) وKubescape. تكتشف هذه الأدوات حاويات root وغياب الحدود والأوضاع المميزة. وتُشغَّل جميعها في CI مع كل pull request، سواء كتب الملف إنسان أم نموذج.

المستوى الثالث هو السياسات داخل الكلاستر نفسه. فـ Pod Security Admission بالملف الشخصي `restricted` يمنع الـ pods غير الآمنة عند الدخول. وتضيف Kyverno أو OPA Gatekeeper قواعدها الخاصة: حظر `latest`، وإلزامية الحدود، والسجلات المسموح بها. وإذا أغفل كاتب الـ manifest شيئاً، فلن يقبل الكلاستر كائناً كهذا.

كيف تتعامل مع التوليد بالذكاء الاصطناعي عملياً

تعامل مع إجابة النموذج كأنها pull request من متدرّب: سريعة وواثقة، لكن دون فهم لبيئتك. حدّد في الطلب بوضوح إصدار Kubernetes ومتطلبات الأمان وسياسات المؤسسة. اطلب شرح كل معامل غير بديهي، ثم تحقق من الشرح في التوثيق.

لا تسمح للـ manifests المولَّدة بالوصول مباشرة إلى الكلاستر. يجب أن يكون المسار واحداً: المستودع، ثم CI مع أدوات linting، ثم مراجعة بشرية، ثم نشر عبر GitOps، ثم rollout تدريجي مع مراقبة المقاييس. عندها تبقى سرعة التوليد ميزة، لا حادثاً مؤجلاً.

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