دقائق فقط تفصل عنقودك الجديد عن أول هجوم
لم يعد السؤال «هل سيُستهدف عنقودك؟» بل «متى؟». فبحسب تقرير Wiz لأمن Kubernetes لعام 2025، يتلقى عنقود AKS المُنشأ حديثًا أول محاولة هجوم خلال نحو 18 دقيقة فقط من إنشائه، بينما يتلقى عنقود EKS أول محاولة خلال نحو 28 دقيقة. وتزداد أهمية هذه الأرقام مع اتساع الانتشار؛ إذ يشير مسح CNCF لعام 2026 إلى أن 82% من مستخدمي الحاويات يشغّلون Kubernetes في بيئات الإنتاج، مقارنة بـ66% فقط في 2023.
الأهم أن المشكلة ليست في ثغرات «يوم الصفر»؛ فأكثر من 60% من اختراقات Kubernetes ترتبط بأخطاء الإعداد (Misconfigurations) مثل صلاحيات RBAC المتساهلة وواجهات API المكشوفة على الإنترنت. وقد أبلغت 89% من المؤسسات عن حادثة أمنية واحدة على الأقل متعلقة بالحاويات أو Kubernetes خلال الاثني عشر شهرًا الماضية، وخسر نحو 46% منها إيرادات أو عملاء نتيجة لذلك.
المسؤولية المشتركة في EKS وAKS وGKE: أين ينتهي دور المزوّد ويبدأ دورك؟
توفر الخدمات المُدارة مثل Amazon EKS وAzure AKS وGoogle GKE مستوى عاليًا من الحماية لمستوى التحكم (Control Plane)؛ فالمزوّد يتولى تأمين الخوادم الرئيسية وتحديثها وضمان توافرها. لكن هذا لا يعني أن العنقود «آمن افتراضيًا». فوفق نموذج المسؤولية المشتركة، يبقى العميل مسؤولًا عن كل ما يعمل فوق مستوى التحكم: صور الحاويات، وصلاحيات RBAC وIAM، وإعدادات الـPods، وسياسات الشبكة، وإدارة الأسرار (Secrets).
وهنا تحديدًا تقع معظم الحوادث: واجهة API متاحة للإنترنت العام دون داعٍ، أو حساب خدمة يحمل صلاحيات أوسع من حاجته، أو غياب سياسات الشبكة بين الـPods بحيث يتحرك المهاجم بحرية داخل العنقود بعد أول اختراق. إن فهم الحدود الدقيقة بين ما يؤمّنه المزوّد وما يقع على عاتقك هو الخطوة الأولى لأي استراتيجية أمن سحابي ناضجة.
خمس ممارسات عملية لتحصين عناقيدك في 2026
أولًا: طبّق مبدأ الحد الأدنى من الصلاحيات في RBAC وIAM، وتجنّب منح دور cluster-admin إلا للضرورة القصوى، وراجع الأدوار وحسابات الخدمة دوريًا. ثانيًا: أغلق واجهة API عن الإنترنت العام واجعلها نقطة وصول خاصة (Private Endpoint)، وفعّل سياسات الشبكة (Network Policies) لتقييد الحركة الجانبية بين الـPods.
ثالثًا: أمّن سلسلة التوريد البرمجية: افحص صور الحاويات تلقائيًا في خط CI/CD، واعتمد التوقيع الرقمي للصور، وامنع تشغيل الصور غير الموثوقة في الإنتاج. رابعًا: فعّل المراقبة أثناء التشغيل (Runtime Security) لاكتشاف السلوك الشاذ في الحاويات لحظيًا؛ فالاكتشاف المبكر هو الفارق بين محاولة فاشلة وحادثة مكلفة.
خامسًا: اعتمد «السياسات ككود» (Policy as Code) بأدوات مثل OPA Gatekeeper أو Kyverno، وافحص قوالب البنية التحتية ككود (IaC) قبل النشر، بحيث تُكتشف أخطاء الإعداد قبل وصولها إلى الإنتاج لا بعده. بهذه الممارسات الخمس تتحول حماية Kubernetes من ردّ فعل بعد الحوادث إلى انضباط وقائي مستمر.