يعد Kubernetes (K8s) نظامًا موزعًا معقدًا مصممًا لتشغيل أعباء العمل المضمنة في حاويات بطريقة قابلة للتطوير والإدارة. إنها الآن الطريقة الافتراضية لنشر أعباء العمل في البيئات السحابية الأصلية. بفضل مرونته وقابليته للتوسعة، أثبت Kubernetes فعاليته في التعامل مع مجموعة متنوعة من أعباء العمل (على سبيل المثال، Batch، HPC، المستندة إلى GPU)، مما ساهم في اعتماده على نطاق واسع.
يتسابق أمان Kubernetes لمواكبة التطور السريع للنظام البيئي. تشمل أنواع التهديدات الشائعة لـ Kubernetes التعدين التشفير، سرقة الموارد، سرقة البيانات، المحاور السحابية، سرقة الملكية الفكريةوأكثر من ذلك. ومع ذلك، تعتمد كل هذه الهجمات على شيء واحد: الوصول الأولي الناجح.
هناك عامل محفز آخر أقل وضوحًا: لدينا 2023 أمن كوبيرنتس تقرير أظهر أنه بمجرد حصول المهاجمين على وصول أولي، تكون هناك فرصة كبيرة للتحرك الجانبي والتحرك الجانبي تصعيد الامتياز داخل كتلة. وهذا يجعل تأمين الوصول الأولي أكثر أهمية.
يعد فهم متجهات الوصول المحتملة إلى مجموعاتك ومعرفة كيفية اكتشاف الهجوم الأولي أمرًا بالغ الأهمية. مهتم؟ استمر في القراءة.
هناك فجوة في الممارسات المنهجية للوصول الأولي إلى Kubernetes. أطر مثل حاويات MITRE مصفوفة وMicrosoft Threat Matrix for Kubernetes يسردان بعض تقنيات الوصول الأولي، لكن لا تتعمق في التحليل الأعمق أو تحديد أولويات المخاطر. في سلسلة المدونات هذه، نقدم تصنيفًا لمتجهات الوصول الأولية.
تمثل الركائز الأساسية أربعة مجالات وصول رئيسية: مستوى التحكم، ومستوى البيانات، والوصول إلى السحابة، وCI/CD. الوصول إلى السحابة وCI/CD يقعان خارج نطاق هذه المقالة؛ سنركز هنا على Kubernetes نفسه. وتنقسم هذه المجالات أيضًا إلى نواقل أصغر، والتي تعلوها أبرز المخاطر المرتبطة بكل منها. على سبيل المثال، يعد التكوين الخاطئ هو الخطر الرئيسي المرتبط بكشف إمكانية الوصول إلى Kubelet API. أدناه، سنركز على الوصول إلى مستوى التحكم، وتقسيم متجهات الوصول الأولية، والمخاطر المرتبطة بها، وتقنيات الحماية والكشف المقترحة. في المقالة التالية، سنتعمق في الوصول إلى مستوى البيانات.
خادم K8s API ليس مجرد مركز اتصال بين مكونات مستوى التحكم؛ إنها أيضًا الواجهة الأمامية لتفاعل المستخدم الخارجي مع المجموعة. وهذا يجعلها الطريقة الأساسية للوصول إلى مجموعات K8 وإدارتها.
الوصول غير المصادق عليه
تتم إدارة الوصول إلى واجهة برمجة تطبيقات K8s من خلال التحكم في الوصول المستند إلى الدور (RBAC). المفهوم الأساسي هنا هو أدوار المستخدم. افتراضيًا، يقوم K8s بتعيين كل مستخدم غير مصادق عليه إلى النظام: دور مجهول، والذي ينتمي إلى النظام: مجموعة غير مصادق عليها. عند تعطيل هذا (كما هو الحال في AKS)، يتلقى المستخدمون غير المصادقين خطأ 401 عند محاولة الوصول إلى نقاط نهاية API. عند تمكينه (كما هو الحال في EKS وGKE)، يتم منح المستخدمين غير المصادقين الأذونات الأساسية للدور المجهول، مثل استرداد الإصدار والمعلومات الصحية:
ومع ذلك، فإن هذا يفتح الباب أمام تكوينات خاطئة محتملة لـ RBAC. على سبيل المثال، قد يقوم مسؤول المجموعة البطيء بتعيين أذونات زائدة مؤقتًا للنظام: مجموعة غير مصادق عليها لأن فريق التطوير يحتاج إلى الوصول ولكن ليس لديه بيانات الاعتماد المناسبة. لقد كان الوصول غير المصادق سببًا لتعدد الحوادث.
Kubeconfig
ال Kubeconfig يحدد الملف كيفية مصادقة kubectl مقابل خادم API. يحتوي على ثلاثة أقسام رئيسية: المجموعات (مجموعة IP وسلطة الشهادة)، والمستخدمين (بيانات المصادقة)، والسياقات (أزواج المجموعة/المستخدمين). نوصي بمعاملة ملف Kubeconfig كملف يحتوي على أسرار، وخاصة المستخدمين القسم، لأنه يحتوي على بيانات المصادقة.
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: LS0tL...
server: IP
name: cluster1
- cluster:
...
contexts:
- context:
cluster: cluster1
user: user1
name: context1
- context:
...
kind: Config
preferences: {}
users:
- name: user1
user:
- name: user2
user:
- name: user3في EKS وGKE، هذه هي الإرشادات لتشغيل المكونات الإضافية المحلية لـ kubectl exec (أوس CLI، aws-iam-authenticator، gke-gcloud-auth-plugin.exe) الذي سيجلب بيانات الاعتماد السحابية الضرورية بحيث لا يتم تخزين بيانات الاعتماد في ملف kubeconfig. وهذا له ميزتان: (1) أنه يقلل من خطر التعرض للملفات و(2) ينقل المصادقة/الترخيص إلى مجال الهويات، وهو ما يسهل تدقيقه واكتشاف التهديدات وما إلى ذلك. ومع ذلك، في AKS، تعتمد مادة المصادقة على طريقة المصادقة/التفويض العنقودية. عند إنشاء مجموعة AKS الجديدة، يجب على المستخدم اختيار الطريقة، والخيار الافتراضي هو “الحسابات المحلية مع Kubernetes RBAC”:
افتراضيًا، يتضمن ملف Kubeconfig في AKS رمزًا مميزًا للمستخدم وبيانات شهادة العميل التي يمكن استخدامها للمصادقة الناجحة. مع شهادة صالحة لمدة عامين، يمكن أن يكون لدى ممثل خبيث الوصول على المدى الطويل إلى المجموعة إذا لم يتم تدوير الشهادة.
ملحوظة: بالطبع، تشكل بيانات الاعتماد السحابية المتسربة بحد ذاتها خطرًا جسيمًا على بيئات K8 بغض النظر عن نوع السحابة. ومع ذلك، فإن هذا خارج نطاق هذه المقالة ويتم وضع علامة عليه بشكل عام على أنه “الوصول إلى السحابة” في المصفوفة أعلاه.
وينطبق هذا الخطر أيضًا على المجموعات ذاتية الاستضافة، والتي تقدم نطاقًا أوسع من خيارات المصادقة (على سبيل المثال، ملف الرمز المميز، وبيانات اعتماد SSH، والأوامر الخاصة، وما إلى ذلك). بغض النظر عن الإعداد، تعامل مع ملف Kubeconfig الخاص بك كمستند حساس. أبداً وفحصها في المستودعات العامة، والتي تظل واحدة من أكثر الطرق شيوعًا لتسريب بيانات الاعتماد. يمكن أن يكشف بحث GitHub البسيط عن بيانات اعتماد الوصول بنص عادي:
وكيل كوبيكتل
كوبيكتل الوكيل هي طريقة أقل شهرة للوصول إلى خادم K8s API، وتُستخدم عادةً للتشخيص المؤقت أو تصحيح الأخطاء. يؤدي تشغيل kubectl proxy –port=8080 إلى إنشاء خادم وكيل مؤقت بين المضيف المحلي وخادم K8s API. سيتم تنفيذ أي استدعاءات API إلى localhost:8080 كطلبات HTTP معتمدة من قبل المستخدم الذي قام بتشغيل الأمر. يمكن للمهاجمين الاستفادة من هذا الاتصال غير المصادق إذا كان لديهم وصول محلي أو وصول إلى الشبكة (حتى SSRF سيفعل ذلك) إلى المحطة الأصلية – كمبيوتر محمول للمطور أو جهاز افتراضي للوصل:
لحسن الحظ، هذا ليس خطأً شائعًا في التكوين. يُبلغ Shodan عن أقل من 100 نقطة نهاية تُرجع الحالة 200 مع رأس Kubernetes ذي الصلة:
Kubelet هو وكيل مستوى التحكم العنقودي الذي يعمل على كل عقدة عاملة، وبشكل افتراضي، لا يمكن الوصول إليه إلا من خلال المكونات الداخلية الموجودة على نفس العقدة. ومع ذلك، من الممكن كشف واجهة برمجة تطبيقات Kubelet خارجيًا لأغراض تصحيح الأخطاء. يتم التحكم في هذا الإعداد باستخدام –anonymous-auth و –وضع التفويض المعلمات في ملف .conf الذي يخزن تكوين kubelet. أحد أسوأ عمليات التكوين الخاطئة هو وجود مجموعة –-anonymous-auth=True / –authorization-mode=AlwaysAllow على العقدة مما يترك واجهة برمجة تطبيقات Kubelet مفتوحة للوصول المجهول. لن يكون الوصول الأولي عبر Kubelet API مرئيًا في سجل تدقيق K8s ويتطلب أجهزة استشعار أو سجلات تدفق VPC لاكتشاف مثل هذا النشاط. هذا هو أحد التكوينات الخاطئة التي يستهدفها تيم تي ان تي، ولكنه نادر الآن في أنظمة الإنتاج ويرتبط عادةً بمجموعات مصيدة الجذب.
توفر واجهات الإدارة مثل K8s Dashboard وKubeflow وArgo Workflows وغيرها إمكانية وصول إضافية إلى المجموعة. من الأخطاء النموذجية في التكوين ترك لوحة المعلومات دون مصادقة ومعرضة للإنترنت العام. تعتمد المخاطرة هنا على إمكانيات لوحة المعلومات وأذوناتها.
كانت هذه التكوينات الخاطئة أكثر شيوعًا منذ عدة سنوات عندما لم تكن الإعدادات الافتراضية آمنة (يظل مثال التسوية الأكثر شهرة هو لوحة تحكم Tesla التعرض من 2017). في الوقت الحاضر، يجب تثبيت لوحات المعلومات بشكل صريح، مع تمكين المصادقة افتراضيًا. على سبيل المثال، أبلغت Shodan عن وجود حوالي 4000 لوحة تحكم Kubernetes مكشوفة. ومع ذلك، التثبيت الافتراضي وضع يتطلب المصادقة، وبالتالي فإن المهاجمين الذين يتوقعون فوزًا سهلاً سيواجهون شاشة تسجيل الدخول:
Kubernetes هو نظام معقد وموزع مع نواقل وصول متعددة. كل واحد، إذا ترك دون تأمين، يمكن أن يؤدي إلى تسوية المجموعة الكاملة. في هذا المنشور، شاركنا تصنيفًا لمتجهات الوصول الأولي لمستوى التحكم في Kubernetes، بهدف مساعدة المشغلين ومحترفي الأمن على تأمين مجموعاتهم بشكل أفضل. لقد حددنا أيضًا استراتيجيات الكشف والوقاية لكل ناقل.
لقد حاولنا تحقيق التوازن بين العمق والاتساع في تغطيتنا. في المقالة التالية، سنفعل الشيء نفسه بالنسبة لمتجهات الوصول إلى مستوى البيانات.
