ملاحظة perev. : هذه ليست المقالة الأولى مع توصيات الأمان العامة على Kubernetes التي نترجمها على مدونتنا. ومع ذلك ، فإن أهميتها - على الأقل للتذكير بالأشياء البسيطة والهامة التي يجب ألا تغض الطرف نظرًا لضيق الوقت - تؤكدها الأحداث الأخيرة التي ذكرها المؤلف في بداية المادة فقط. بالمناسبة ، المؤلف هو كونور جيلبرت ، مدير المنتج في StackRox ، وهي منصة جاهزة لتأمين التطبيقات التي يتم نشرها داخل مجموعات Kubernetes. لذلك ، هنا هو ما ينصح القراء بلوق CNCF ...
ملاحظة : لجعل المقالة أكثر إفادة ، بالنسبة لبعض المصطلحات / الأساليب التي ذكرها المؤلف ، أضفنا روابط إلى الوثائق ذات الصلة.
في الشهر الماضي ، اكتشفت Kubernetes ، أشهر نظام لتنسيق الحاويات في العالم ، أول ثغرة أمنية كبيرة تصيب النظام البيئي للمشروع. تسمح
مشكلة عدم الحصانة
CVE-2018-1002105 للمهاجمين بخرق المجموعات من خلال خادم Kubernetes API ، والذي يسمح بتنفيذ تعليمات برمجية ضارة لتثبيت البرامج الضارة ، إلخ.
في وقت سابق من العام ، أدى التكوين غير الصحيح للوحة تحكم Kubernetes إلى حقيقة أن موارد Tesla
لديها برنامج التعدين cryptocurrency
المثبت . ثم استفاد المهاجمون من حقيقة أن إحدى لوحات Kubernetes لم تكن محمية بكلمة مرور ، مما سمح لهم بالوصول إلى أحد الحواجب من خلال حساب للوصول إلى البنية التحتية الأكبر لتيسلا في AWS.
تحتاج المنظمات التي تسرع تنفيذ الحاويات وتنسيقها أيضًا إلى اتخاذ خطوات إلزامية لحماية هذا الجزء المهم من بنيتها التحتية. فيما يلي تسع من أفضل ممارسات الأمان في Kubernetes بناءً على بيانات العميل: اتبعها لحماية البنية الأساسية لديك بشكل أفضل.
1. التحديث إلى أحدث إصدار
في كل إصدار ربع سنوي من [Kubernetes] ، لا توجد إصلاحات للأخطاء فقط ، ولكن أيضًا ميزات أمان جديدة: للاستفادة منها ، نوصي بالعمل مع أحدث إصدار ثابت.
سيكون استخدام الإصدار الأخير مع أحدث التصحيحات ذا صلة خاصة في ضوء الاكتشاف الأخير لـ CVE-2018-1002105. قد تكون التحديثات والدعم أكثر صعوبة من الميزات الجديدة المقدمة في الإصدارات ، لذلك خطط تحديثاتك مرة واحدة على الأقل كل ثلاثة أشهر.
يمكن لتبسيط التحديثات بشكل كبير استخدام موفري حلول Kubernetes المدارة.
2. تمكين التحكم في الوصول القائم على الدور (RBAC)
استخدم
RBAC (التحكم في الوصول استنادًا إلى الدور) للتحكم في من يمكنه الوصول إلى Kubernetes API والحقوق التي يتمتعون بها. عادة ، يتم تمكين RBAC بشكل افتراضي في الإصدار 1.6 من Kubernetes والإصدارات الأحدث (أو الأحدث بالنسبة لبعض الموفرين) ، ولكن إذا كنت قد تم تحديثها منذ ذلك الحين ولم تقم بتغيير التكوين ، فيجب عليك التحقق من إعداداتك. نظرًا للآلية التي يتم من خلالها دمج عمل وحدات التحكم في التخويل في Kubernetes
(للتسلسل العام للعمليات ، اقرأ المقال " ماذا يحدث في Kubernetes عندما يبدأ تشغيل kubectl؟ الجزء 1 " - الترجمة تقريبًا ) ، يجب أن يكون لديك RBAC وتمكين ABAC القديم (التحكم في الوصول إلى السمة).
ومع ذلك ، فإن تمكين RBAC ليس كافيًا - لا يزال يتعين استخدامه بفعالية. في الحالة العامة ، يجب تجنب حقوق المجموعة بالكامل
(على مستوى المجموعة) ، مع إعطاء الأفضلية للحقوق في مساحات أسماء معينة. تجنب منح امتيازات مسؤول نظام المجموعة لشخص ما حتى من أجل تصحيح الأخطاء - يكون منح الحقوق أكثر أمانًا فقط عند الضرورة ومن وقت لآخر.
يمكنك رؤية أدوار نظام المجموعة والأدوار ببساطة باستخدام
kubectl get clusterrolebinding أو
kubectl get rolebinding --all-namespaces . وبذلك يمكنك التحقق سريعًا
cluster-admin دور
cluster-admin الذي تم
cluster-admin (في هذا المثال ، إنه مخصص فقط لمجموعة
masters ):
$ kubectl describe clusterrolebinding cluster-admin Name: cluster-admin Labels: kubernetes.io/boostrapping=rbac-defaults Annotations: rbac.authorization.kubernetes.io/autoupdate=true Role: Kind: ClusterRole Name: cluster-admin Subjects: Kind Name ---- ---- Group system:masters Namespace ---------
إذا كان التطبيق يتطلب الوصول إلى Kubernetes API ، فقم بإنشاء حسابات خدمة منفصلة
(اقرأ المزيد عنها في هذه المادة - الترجمة تقريبًا ) ومنحهم مجموعة الحد الأدنى من الحقوق المطلوبة لكل حالة استخدام. هذا النهج أفضل بكثير من منح امتياز كبير للحساب الافتراضي في مساحة الاسم.
معظم التطبيقات لا تحتاج إلى الوصول إلى واجهة برمجة التطبيقات على الإطلاق:
يمكنك ضبط automountServiceAccountToken على
false بالنسبة لهم.
3. استخدم مساحات الأسماء لتعيين حدود الأمان
من المهم إنشاء مساحات أسماء منفصلة كالمستوى الأول لعزل المكون. من الأسهل بكثير ضبط إعدادات الأمان - على سبيل المثال ، سياسات الشبكة - عند نشر أنواع مختلفة من أحمال العمل في مساحات أسماء منفصلة.
هل يستخدم فريقك مساحات الأسماء بكفاءة؟ تحقق من قائمتهم للتأكد من أنها غير قياسية (لا يتم إنشاؤها افتراضيًا):
$ kubectl get ns NAME STATUS AGE default Active 16m kube-public Active 16m kube-system Active 16m
4. افصل أعباء العمل الحساسة.
من الممارسات الجيدة للحد من العواقب المحتملة للتسوية تشغيل أعباء العمل مع البيانات الحساسة على مجموعة مخصصة من الآلات. يقلل هذا النهج من خطر وصول تطبيق أقل أمانًا إلى التطبيق من خلال بيانات حساسة تعمل في نفس البيئة القابلة للتنفيذ للحاوية أو على نفس المضيف. على سبيل المثال ، عادةً ما يكون kubelet لعقدة مهددة الوصول إلى محتويات الأسرار فقط إذا كانت محمولة على القرون التي من المقرر تنفيذها على العقدة نفسها. إذا كان من الممكن العثور على أسرار مهمة على عقد عنقودية متعددة ، فستتاح للمهاجم المزيد من الفرص للحصول عليها.
يمكن إجراء الفصل باستخدام
تجمعات العقدة -
تجمعات العقدة (في السحابة أو في أماكن العمل) - بالإضافة إلى آليات التحكم في Kubernetes ، مثل مساحات الأسماء ،
والدرجات ، والتحمل ، وغيرها.
5. حماية الوصول إلى البيانات السحابية الخدمة
يمكن سرقة بيانات التعريف الحساسة - على سبيل المثال ، بيانات اعتماد kubelet الإدارية - أو استخدامها بقصد ضار لتصعيد الامتيازات في كتلة. على سبيل المثال ، أظهر
اكتشاف حديث داخل مكافأة الشوائب في Shopify بالتفصيل كيف يمكن للمستخدم تجاوز السلطة من خلال تلقي البيانات الوصفية من موفر خدمة السحاب باستخدام بيانات تم إنشاؤها خصيصًا لأحد خدمات microservices.
في GKE ، تقوم وظيفة
إخفاء بيانات التعريف ، وهي
إخفاء بيانات التعريف ، بتغيير آلية نشر الكتلة بطريقة تتجنب مثل هذه المشكلة ، ونحن نوصي باستخدامها حتى يتم تنفيذ حل دائم.
قد تكون هناك حاجة إلى تدابير مضادة مماثلة في بيئات أخرى.
6. إنشاء وتحديد سياسات شبكة الكتلة
سياسات الشبكة - سياسات
الشبكة - تتيح لك التحكم في الوصول إلى الشبكة من وإلى التطبيقات التي يتم تخزينها في حاويات. لاستخدامها ، يجب أن يكون لديك مزود شبكة يدعم هذا المورد ؛ بالنسبة لموفري حلول Kubernetes المدارة مثل Google Kubernetes Engine (GKE) ، سيلزم تمكين الدعم. (يتطلب تمكين سياسات الشبكة للمجموعات الموجودة في GKE تحديثًا قصيرًا.)
بمجرد أن يصبح كل شيء جاهزًا ، ابدأ بسياسات الشبكة الافتراضية البسيطة - مثل حظر حركة المرور (افتراضيًا) من مساحات الأسماء الأخرى.
إذا كنت تستخدم Google Container Engine ، فيمكنك التحقق من تمكين دعم السياسة في مجموعات العمل:
$ gcloud container clusters list \ --format='table[box] (name,addonsConfig.networkPolicyConfig)'
7. عيّن سياسة أمان Pod for الكتلة.
سياسة أمان Pod -
سياسة أمان Pod - تعيّن القيم الافتراضية المستخدمة لبدء أحمال العمل في الكتلة. ضع في اعتبارك تحديد سياسة وتمكين
وحدة التحكم في قبول Pod Security Policy: تختلف التعليمات الخاصة بهذه الخطوات وفقًا لموفر السحابة أو نموذج النشر المستخدم.
بالنسبة للمبتدئين ، قد
NET_RAW قدرة NET_RAW في حاويات لحماية نفسك من أنواع معينة من هجمات الخداع.
8. العمل على الأمن العقدة
لتحسين أمان المضيف ، يمكنك اتباع الخطوات التالية:
- تأكد من تكوين المضيف بشكل آمن وصحيح . طريقة واحدة هي معايير رابطة الدول المستقلة . تحتوي العديد من المنتجات على أداة فحص تلقائي تقوم بفحص النظام تلقائيًا للتأكد من توافقه مع هذه المعايير.
- مراقبة توافر شبكة من المنافذ الهامة . تأكد من أن شبكتك تحظر الوصول إلى المنافذ المستخدمة بواسطة kubelet ، بما في ذلك 10250 و 10255. فكّر في تقييد الوصول إلى خادم Kubernetes API - باستثناء الشبكات الموثوقة. في المجموعات التي لا تتطلب المصادقة والتخويل في واجهة برمجة تطبيقات kubelet ، استخدم المهاجمون الوصول إلى هذه المنافذ لإطلاق عمال المناجم المشفرة.
- تقليل الوصول الإداري إلى مضيفي Kubernetes . يجب أن يكون الوصول إلى عقد نظام المجموعة محدودًا من حيث المبدأ: لتصحيح الأخطاء وحل المشكلات الأخرى ، كقاعدة عامة ، يمكنك الاستغناء عن الوصول المباشر إلى العقدة.
9. تمكين تسجيل التدقيق
تأكد من تمكين
سجلات التدقيق وأنك تراقب حدوث مكالمات API غير عادية أو غير مرغوب فيها فيها ، لا سيما في سياق أي فشل تخويل - سيكون لهذه الإدخالات رسالة بها حالة "محظور". قد يعني فشل التخويل أن المهاجم يحاول الاستفادة من بيانات الاعتماد التي تم الحصول عليها.
يوفر موفرو الحلول المدارة (بما في ذلك GKE) الوصول إلى هذه البيانات في واجهاتهم ويمكنهم مساعدتك في إعداد الإشعارات في حالة فشل التخويل.
التطلع الى المستقبل
اتبع هذه الإرشادات لمجموعة Kubernetes الأكثر أمانًا. تذكر أنه حتى بعد تكوين الكتلة بشكل آمن ، يجب عليك ضمان الأمن في الجوانب الأخرى لتكوين وتشغيل الحاويات. لتحسين أمان مكدس التكنولوجيا ، استكشف الأدوات التي توفر نظامًا مركزيًا لإدارة الحاويات المنشورة ، ومراقبة وحماية الحاويات والتطبيقات الأصلية السحابية باستمرار.
PS من المترجم
اقرأ أيضًا في مدونتنا: