Kubernetes Security Assessment

يقيّم عنقود Kubernetes بحثاً عن نقاط الضعف الأمنية: سوء إعداد RBAC وتصعيد الامتياز، والـ workloads غير الآمنة وغياب ضبط الـ admission، وسياسات الشبكة المفتوحة، وانكشاف الأسرار، ومستوى تحكم غير مُحصَّن بما يكفي؛ مقيساً على CIS Kubernetes Benchmark وإرشادات التحصين من NSA/CISA وOWASP Kubernetes Top 10، مع إثبات كل اكتشاف وتصنيفه.

في المقام الأول CIS Kubernetes Benchmark لتحصين الإعدادات، وإرشادات تحصين Kubernetes من NSA/CISA لمستوى التحكم والـ workloads، وOWASP Kubernetes Top 10 لفئات المخاطر الشائعة. كما نعتمد Pod Security Standards أساساً لإعدادات الـ workload.

عادةً حساب خدمة محدود النطاق للقراءة فقط مع kubeconfig الخاص به، كي نتمكّن من الجرد والمراجعة دون تغيير أي شيء. ولاختبار الحركة الجانبية والهروب ضمن افتراض الاختراق، يكون Pod موطئ قدمٍ في العنقود مثالياً. ونتفق على النطاق وعلى الـ namespaces المعنيّة وعلى كل ما يجب تجنّبه قبل أن نبدأ.

كلاهما. في العنقود المُدار يحصّن المزوّد مستوى التحكم ضمن نموذج المسؤولية المشتركة، فنركّز على ما يبقى على عاتقكم: RBAC، والـ workloads، وسياسات الشبكة، والأسرار، وإعدادات العُقدة (node)؛ وفي العنقود ذاتي الإدارة نراجع أيضاً API server وetcd وkubelet مباشرةً.

يقرّر RBAC أي هوية يحق لها تنفيذ أي إجراء على أي مورد. وتصعيد الامتياز هو أن يتيح دورٌ أو binding مفرط الاتساع — حساب خدمة يستطيع إنشاء Pods أو قراءة الأسرار أو انتحال هويات أخرى — لموطئ قدمٍ محدود الصلاحيات أن يصل إلى cluster-admin. ويهمّ لأنه يحوّل Pod واحداً مُخترَقاً إلى سيطرة على العنقود بأكمله، وهو خفيّ عن فحصٍ لا ينظر إلا إلى الإعدادات كلٍّ على حدة.

من Pod موطئ قدمٍ نفحص ما إذا كانت سياسات الشبكة تقيّد فعلاً حركة المرور بين الـ Pods وبين الـ namespaces — فـ Kubernetes يسمح بها كلها افتراضياً — وما إذا كانت الخدمات التي يمكن الوصول إليها، أو رموز حسابات الخدمة، أو نقطة metadata السحابية تتيح لنا التقدّم أكثر أو التصعيد. والنتيجة هي نطاق التأثير الفعلي لـ Pod واحد مُخترَق.

المراجعة ورسم الخريطة عمليتان للقراءة فقط وآمنتان. أما الاختبارات الفعّالة — محاولات الهروب والحركة الجانبية — فيُتفَّق عليها مسبقاً وتُنفَّذ بحذر؛ ونفضّل عنقود staging يحاكي الإنتاج، وعندما يلزم الاختبار على الإنتاج نضع حدوداً ونبقي على جهة اتصال لديكم كي نتوقف فوراً إذا بدا أي شيء خاطئاً.

يحصل كل اكتشاف على درجة CVSS كأساس مشترك، تُعدَّل بحسب الأثر الفعلي في عنقودكم: إلى أين يصل المهاجم، وبأي سهولة، وهل يؤدي ذلك إلى cluster-admin أو إلى البيانات. ولهذا قد تُرتَّب مشكلتان لهما درجة CVSS نفسها بأولوية مختلفة.

نعم. بعد المعالجة نعيد اختبار الاكتشافات المُبلَّغ عنها للتأكد من ثبات كل إصلاح وأنه لم يفتح ثغرة جديدة، ونحدّث حالتها في التقرير.

يعتمد على عدد العناقيد والـ namespaces والـ workloads وعلى مقدار ما يقع تحصينه من المنظومة على عاتقكم؛ ويستغرق التقييم المعتاد نحو أسبوعين إلى أربعة أسابيع. ونقدّم تقديراً دقيقاً بعد تحديد النطاق.