يوضح لماذا تظل وثائق SVIDs قصيرة العمر في SPIFFE/SPIRE معتمدة على سلامة العقدة، وما كشفه اختبار مخبري لتزييف معلومات cgroup، وأي ضوابط في Kubernetes يمكن أن تحدّ من الأثر.
يوفر SPIFFE للخدمات وثائق هوية تشفيرية قصيرة العمر تُسمّى SVIDs. ويمكن لأحمال العمل استخدامها لإنشاء اتصالات TLS أو لتوقيع رموز JWTs والتحقق منها. وتعرّف النظرة العامة الرسمية على SPIFFE هذا النموذج.
أين يُتخذ قرار الهوية
يتحقق SPIRE من هوية العقد وأحمال العمل قبل إصدار وثائق SVIDs. وأثناء التحقق من هوية حمل العمل، يحدد وكيل SPIRE خصائص العملية من مصادر محلية، مثل نواة نظام التشغيل أو kubelet على العقدة نفسها. ثم يقارن هذه الخصائص بشروط المحدِّدات في مدخلة تسجيل؛ وعند نجاح المطابقة، تتحدد هوية SPIFFE ID التي تحصل عليها العملية. وتشرح وثائق مفاهيم SPIRE هذه الآلية.
نطاق النتيجة المخبرية
في هذا النموذج، تُعدّ صلاحية وثيقة SVID من الناحية التشفيرية مسألة منفصلة عن إصدارها للعملية المقصودة. وقد أظهرت أبحاث Unit 42 المخبرية أن مهاجمًا يتمتع مسبقًا بصلاحيات root على عقدة Kubernetes يمكنه تزييف معلومات cgroup في Linux، وخداع وكيل SPIRE، والحصول على وثيقة SVID صالحة تخص حمل عمل آخر على العقدة نفسها. وتوثّق أبحاث Unit 42 التسلسل التقني لهذه العملية.
تذكر Unit 42 صراحةً أنها لم ترصد استخدام هذه التقنية في هجمات فعلية. لذا لا تُعدّ هذه النتيجة دليلًا على استغلال جارٍ؛ بل تصف خطرًا في مرحلة ما بعد الاستغلال، ينشأ بعد أن يؤدي الوصول بصلاحيات root إلى تقويض الثقة بالعقدة.
نموذج دفاعي لمخاطر العقد
عند التخطيط للدفاع، ينبغي التعامل مع اختراق عقدة على أنه اختراق لكل هوية حمل عمل يقع ضمن نطاق تلك العقدة. وتشمل إرشادات Unit 42 تقييد الحاويات ذات الامتيازات المرتفعة والوصول المباشر إلى النظام المضيف، مع تقليل الاعتماد على المحدِّدات الضعيفة أو التي يسهل تزييفها. والنطاق المعني هنا هو العقدة المخترقة، وليس العنقود بأكمله تلقائيًا.
تقليل امتيازات وحدات pod والعقد
ينص ملف Restricted ضمن معايير Kubernetes Pod Security Standards على منع وحدات pod ذات الامتيازات المرتفعة، وحظر تصعيد الامتيازات، وتشغيل الحاويات بحسابات مستخدمين لا تملك صلاحيات root. وتذكر قائمة التحقق الأمنية الرسمية أيضًا أن seccomp يمكن أن يقلّص نطاق استدعاءات نظام نواة Linux المتاحة داخل الحاويات. وترد التفاصيل في معايير Pod Security Standards وقائمة التحقق الأمنية لـ Kubernetes.
التعامل مع المحدِّدات بوصفها جزءًا من حدود الثقة
ليست المحدِّدات مجرد تفاصيل للمطابقة؛ فهي تحدد الخصائص المحلية التي يُعتدّ بها عند اتخاذ قرار التحقق من الهوية. لذلك ينبغي أن تتناول المراجعة بيانات نظام التشغيل أو kubelet التي يستند إليها كل شرط، وما إذا كان الوصول بصلاحيات root قد يجعل تزييف تلك البيانات سهلًا. والهدف هو الاعتماد على محدِّدات تميّز أحمال العمل وفق معايير دقيقة ومحدودة، بدلًا من شروط واسعة أو ضعيفة.
فصل مستويات الحساسية وبيانات الاعتماد الإضافية
يوصي Kubernetes أيضًا بوضع أحمال العمل ذات مستويات الحساسية المختلفة على عقد منفصلة، وعدم تركيب رموز حسابات الخدمة داخل وحدات pod التي لا تحتاج إليها. وتصف قائمة التحقق الأمنية الرسمية كلا الضابطين.
يهدف فصل العقد إلى جعل الانتقال المباشر إلى تطبيقات أكثر حساسية أصعب بعد الخروج من عزل الحاوية. كما أن عدم تركيب رمز حساب خدمة غير ضروري يمنع وجود بيانات اعتماد إضافية داخل وحدة pod، منفصلة عن وثيقة SVID.
تسلسل عملي للمراجعة
يمكن تحويل حدود الثقة هذه إلى تسلسل مراجعة موجز ينظر إلى الإعدادات وتوزيع أحمال العمل معًا:
نطاق الهوية: أي معرّفات SPIFFE IDs تقع ضمن نطاق كل عقدة، وأي مستويات حساسية تتشارك تلك العقدة؟
مدخلات التحقق من الهوية: أي بيانات من نظام التشغيل أو kubelet تغذّي المحدِّدات، وهل يمكن تزييفها باستخدام صلاحيات root؟
امتيازات العقدة: أي وحدات pod تتمتع بامتيازات مرتفعة، أو يمكنها الوصول إلى النظام المضيف، أو تسمح بتصعيد الامتيازات، أو تعمل بصلاحيات root؟
بيانات الاعتماد الإضافية: أي وحدات pod تتلقى رموز حسابات الخدمة رغم أنها لا تحتاج إليها؟
ليست الخلاصة أن وثائق SVIDs عديمة الفائدة. بل يجب تقييم ضمانات الهوية التشفيرية التي توفرها إلى جانب سلامة العقدة التي يجري عليها التحقق من الهوية. ويجمع النموذج القادر على الصمود بين هوية قصيرة العمر لأحمال العمل، وتعزيز أمان وحدات pod، وشروط محدِّدات دقيقة ومحدودة، وفصل العقد بحسب الحساسية، وإزالة بيانات الاعتماد غير الضرورية.
