ناقلات الوصول الأولي لـ Kubernetes الجزء 2: مستوى البيانات

هذا هو الجزء الثاني من سلسلتنا المكونة من مدونتين، حيث نستكشف مختلف ناقلات الوصول الأولية إلى بيئات Kubernetes، ونحلل زوايا الهجوم المرتبطة بها، ونوضح المخاطر ذات الصلة.

في المدونة الأولى، قدمنا ​​تصنيف متجهات الوصول الأولية وناقشنا الوصول إلى مستوى التحكم. في هذا الجزء، نركز على الوصول إلى مستوى البيانات. سنستعرض متجهات الوصول الأولية المحتملة التي تنشأ من التطبيقات التي تعمل على المجموعة، ونناقش المخاوف المتعلقة بصور الحاوية (أصلها وسيناريوهات الهروب المحتملة)، ونختتم بأنواع أحمال عمل التنفيذ كخدمة.

تم تصميم مجموعات Kubernetes لتشغيل أعباء العمل. وبطبيعة الحال، تنفذ أحمال العمل هذه إجراءات معينة من خلال تنفيذ منطق الأعمال. يمكن أن يحتوي كل عبء عمل على ثغرة أمنية خطيرة تؤدي إلى تنفيذ التعليمات البرمجية عن بعد (RCE). لكي تكون الثغرة الأمنية قابلة للاستغلال، يجب أن يتم الكشف عنها ويمكن الوصول إليها بواسطة مستخدم خارجي – إما بشكل مباشر (على سبيل المثال، RCE في حاوية الواجهة الأمامية) أو بشكل غير مباشر (على سبيل المثال، التكوين الخاطئ الذي يؤدي إلى RCE في حاوية قاعدة بيانات SQL، والتي يمكن الوصول إليها عبر حاوية الواجهة الأمامية). وبما أن أمان التطبيق يقع خارج نطاق هذه المقالة، فإننا نركز هنا على كيفية احتواء المهاجم بعد الوصول الأولي. في مثل هذا السيناريو، سيجد الممثل الخبيث نفسه في سياق تنفيذ حجرة ضعيفة، كما هو موضح في هذا الرسم البياني:

من هذه النقطة، يتوفر ناقلان رئيسيان للمهاجمين: (1) إساءة استخدام امتيازات Kubernetes RBAC المرتبطة بحساب خدمة (SA) الخاص بهذه الحاوية و/أو (2) إساءة استخدام امتيازات النظام داخل الحاوية الحالية أو حاويات الحاوية المجاورة للهروب إلى المضيف والتحرك أفقيًا. تم تصميم العديد من الحدود الأمنية لمنع هذه الحركة الجانبية وسيناريوهات تصعيد الامتيازات، مثل مساحات أسماء Kubernetes (فصل RBAC)، ومعايير أمان Pod (تقييد قدرات نظام Pod)، وسياسات الشبكة وجدولة عقدة Kubernetes المخصصة. ويعتمد نجاح المهاجم على فعالية الضوابط الأمنية هذه. في لدينا تقرير أمان Kubernetes لعام 2023، شددنا على وفرة فرص الحركة الجانبية بمجرد حصول المهاجم على الوصول الأولي. مجموعة من الأمن نقاط الضعف إن البنية التحتية لـ Kubernetes، التي عثر عليها فريق Wiz Vulnerability Research، تشهد على ذلك.

نوصي بشدة باستخدام مزيج من الحدود الأمنية داخل المجموعة، وعلى وجه الخصوص:

• فصل الحاضنات الأمامية والواجهات الخارجية في مساحة اسم مميزة، مع تعيين الحد الأدنى من الامتيازات لحسابات الخدمة الخاصة بها.

• قم بتطبيق مستويات Pod Security Standards (PSS) المناسبة على عبء العمل الخاص بك على مستوى مساحة الاسم. قم بتقسيم مساحات الأسماء إذا لزم الأمر بناءً على مستويات الحساسية.

• عند إدارة الثغرات الأمنية في القرون، قم بإعطاء الأولوية لتلك القرون المكشوفة علنًا وتلك التي تتمتع بامتيازات قوية.

لمزيد من القيود الصارمة على الإيجارات المتعددة، فكر في استخدام مجموعات K8s المنفصلة. تحقق من عزل سحابة PEACH نطاق للحصول على التفاصيل.

يوفر Kubernetes طرقًا متعددة لكشف أعباء العمل للمستخدمين الخارجيين، مع كون خدمات موازن التحميل وبوابات التطبيقات هي الأكثر شيوعًا. هناك طريقة أخرى أقل شيوعًا لكشف البودات وهي عبر خدمة NodePort. عندما أ يقوم مشغل الكتلة بإنشاء خدمة NodePort، ويفتح Kubernetes منفذًا ثابتًا في النطاق الافتراضي من 30000 إلى 32767 على العقدة العاملة.

هناك العديد من المخاوف الأمنية المتعلقة بـ NodePort، وذلك في المقام الأول لأنه ‘أنالا يتم استخدامه عادةً في أنظمة الإنتاج. وعلى هذا النحو، قد يشير وجودها إلى التعرض غير المقصود للخدمة. نفس المنفذ مفتوح على كافة العقد في المجموعة، حتى لو لم يكن عبء العمل موجودًا، مما يؤدي إلى زيادة التعرض بشكل غير ضروري. تقوم كل عقدة بتوصيل المنفذ إلى الخدمة، مما يجعل الوصول المباشر ممكنًا. تعد عناصر التحكم في الوصول إلى الشبكة الدقيقة أيضًا محدودة أكثر مقارنة بخدمات موازن التحميل. يُظهر تحليلنا الداخلي على عينة عشوائية مكونة من 100 مستأجر من Wiz باستخدام إعدادات Kubernetes أن حوالي 6% منهم لديهم خدمات NodePort مكشوفة خارجيًا.

تمثل صور الحاوية ناقل وصول أقل وضوحًا، ولكنه لا يزال محفوفًا بالمخاطر. إذا كان أحد المهاجمين يتحكم في صورة وتقوم حجرة المجموعة بسحبها، فقد يكون المسار من تنفيذ الحاوية إلى مسؤول العقدة المحلية – وربما إلى مسؤول المجموعة – قصيرًا. واحدة من أكثر الثغرات الأمنية شهرة والتي شددت على مخاطر الصور غير الموثوق بها كانت السفن المتسربة، صدرت في الشتاء الماضي. سمحت الثغرات الأمنية في مكتبة runc بالوصول غير المصرح به على مستوى المضيف بمجرد نشر حجرة تحتوي على صورة ضارة.

للتخفيف من هذه المخاطر:

• قم بتطبيق مستويات PSS المناسبة لأحمال عمل مستوى البيانات لمنع هروب الحاوية.

• استخدم مساحات الأسماء كحدود أمان ضد الحركة الجانبية، مما يحد من أذونات RBAC في نطاق مساحة الاسم.

• فكر في استخدام مساحات أسماء المستخدمين على البودات التي لا تتطلب شروطًا خاصة، وفقًا لما ذكرناه سابقًا بحث. تجعل هذه الميزة المتقدمة أذونات الجذر غير فعالة في سياق مضيف.

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

1. الاحتفاظ بسجل حاوية محلي (مرآة) مع فحص الثغرات الأمنية والمصدر.

2. تنفيذ التحقق من توقيع الصورة عبر منطق وحدة التحكم بالقبول (AC) لضمان نشر الصور الموقعة والموثوقة فقط.

لقد جعلت Wiz مؤخرًا من السهل جدًا ضمان سلسلة توريد برامج آمنة في مجموعات Kubernetes. يتمثل النهج التقليدي للتحقق من الصور في إنشاء الثقة في الصورة عبر التوقيعات الرقمية. وهذا يضمن أن الصور المنشورة جاءت من مصادر موثوقة (باستخدام المفتاح العام للتحقق في وقت النشر من الصور الموقعة).

أخذه Wiz إلى المستوى التالي مع ويز صورة الثقة، مما يسمح لك ليس فقط بتأسيس الثقة، ولكن أيضًا ربط سياسة الأمان بإحكام بكل صورة منشورة، وبالتالي ضمان توافق الصورة مع الامتثال الأمني ​​للمؤسسة: المسح بحثًا عن التهديدات الشائعة والبرامج الضارة والأسرار المضمنة قبل سحب الصورة وفي أي وقت محدد – التنقل بسهولة مرة أخرى إلى سياسة فحص ومسح CI/CD المرتبطة بالصورة المنشورة. ويتم ذلك دون الاضطرار إلى التعامل مع الإدارة الرئيسية، والتي تعد واحدة من الجوانب التشغيلية الأكثر تحديًا المرتبطة عادةً بالتوقيع على الصور والتحقق منها.

إن ناقل الوصول الأولي الذي غالبًا ما يتم الاستهانة به هو التنفيذ كخدمة، حيث يقدم بائع الخدمة التنفيذ لمستخدمي الخدمة. على سبيل المثال، تعادل القدرة على تشغيل نماذج الذكاء الاصطناعي الخارجية تنفيذ تعليمات برمجية عشوائية. نظرًا لأن Kubernetes هي تقنية سهلة الاستخدام، يستخدم بائعو الذكاء الاصطناعي بشكل متزايد كبسولات وحاويات K8s لتشغيل النماذج. ونتيجة لذلك، يجب على البائعين الاعتماد على ضوابط الفصل الأمني ​​الخاصة بـ K8، والتي، كما رأينا من قبل، يصعب الحصول عليها بشكل صحيح.

اكتشف فريق أبحاث الثغرات الأمنية في Wiz ثغرات أمنية بين المستأجرين في العديد من خدمات الذكاء الاصطناعي، مثل HuggingFace واجهة برمجة تطبيقات الاستدلال, تكرار، و ساب منظمة العفو الدولية الأساسية. توضح هذه الأجزاء البحثية المخاطر الرئيسية المرتبطة بهذه الخدمة – الوصول عبر المستأجرين. يوضح الرسم البياني أدناه التدفق النموذجي للتسوية:

علاوة على ذلك، يمكن تعميم تدفق الهجوم هذا للتأثير على أي بنية تحتية للتنفيذ كخدمة تعتمد على مجموعات Kubernetes في الواجهة الخلفية. يجب على البائعين الذين يقدمون مثل هذه الخدمات فرض ضوابط أمنية صارمة حول بيئة التنفيذ. فيما يلي التدابير الرئيسية التي يجب مراعاتها:

• مساحة الاسم لكل حجرة تنفيذ (حيثما أمكن): يساعد عزل كل حجرة في مساحة الاسم الخاصة بها على احتواء الانتهاكات المحتملة ويحد من سطح الهجوم.

• مساحات أسماء المستخدمين لوحدات التنفيذ: تمنع هذه الميزة المتقدمة امتيازات جذر الحاوية من الترجمة إلى الوصول إلى الجذر على مستوى المضيف، مما يضيف طبقة إضافية من الأمان.

• سياسات أمان الشبكة: يؤدي تنفيذ سياسات الشبكة الدقيقة إلى تقييد الاتصال من حجرة إلى حجرة، مما يقلل من احتمالية الحركة الجانبية بين أحمال العمل.

• جدولة العقدة لكل مستأجر: يؤدي تعيين العقد العاملة الفردية لمستأجرين مختلفين إلى ضمان العزل ومنع التهديدات عبر المستأجرين في بيئات البنية التحتية المشتركة.

• عزل النواة ووضع الحماية (على سبيل المثال، حاويات Kata، وgVisor، وseccomp، وAppArmor): يؤدي استخدام تقنيات عزل إضافية ووضع الحماية على مستوى kernel إلى تقليل مخاطر هروب الحاويات بشكل كبير وتعزيز الأمان على مستوى النظام.

أخيرًا، اعتمادًا على مدى فعالية تنفيذ عناصر التحكم هذه، فكر في التبديل إلى أجهزة افتراضية منفصلة بدلاً من الاعتماد على مجموعات Kubernetes لتحقيق عزلة أقوى.

نظرًا لضيق المساحة، لا يمكننا تغطية الموضوعات الشاملة المتعلقة بالوصول إلى السحابة وخطوط أنابيب CI/CD في هذا المنشور، ولكنها مجالات مهمة في أمان Kubernetes. يسلط تقرير Kubernetes Security لعام 2023 الضوء على أن الغالبية العظمى من المجموعات (أكثر من 80%) تتم إدارتها وتشغيلها في السحابة، مما يجعلها جزءًا لا يتجزأ من البنية التحتية السحابية الأوسع. وهذا يعني أنه يجب أن يكون لدى مشغلي المجموعة إمكانية رؤية السحابة IAM (إدارة الهوية والوصول) لإدارة الوصول إلى المجموعات على نطاق واسع بشكل فعال.

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

تعد خطوط أنابيب CI/CD، التي تقع في قلب عملية تطوير البرمجيات الحديثة، ناقلًا أساسيًا آخر لأمن Kubernetes. يتم دمج Kubernetes في سلاسل أدوات CI/CD، مع مشغلين مثل ArgoCD وFlux الذين يقومون بأتمتة عمليات نشر موارد K8s عبر المجموعات الجديدة والحالية. تعمل هذه الأدوات على تبسيط العمليات، ولكنها تمثل أيضًا مصدر قلق أمني كبير، نظرًا لأن سير عمل CI/CD غالبًا ما يتمتع بإمكانية الوصول على مستوى المسؤول إلى بيئات Kubernetes، مما قد يمنح المهاجمين طريقًا للحصول على موطئ قدم أولي في المجموعات.

بهذا نختتم سلسلة مدونتينا حول الوصول الأولي لـ Kubernetes (اقرأ الجزء الأول). كما هو موضح، يعد Kubernetes نظامًا معقدًا وموزعًا به نواقل وصول متعددة، يمكن لأي منها – إذا تركت غير آمنة – أن يؤدي إلى تسوية كاملة للمجموعة. نأمل أن يساعد هذا التصنيف في تنظيم المخاطر المرتبطة بها وتحديد أولوياتها.