OWASP Kubernetes Top 10 (2025)، عملي

لعبة التقط العلم مبنية على OWASP Kubernetes Top 10 — 2025. لقد تم تعيينك كفريق اختراق أخلاقي لـ NimbusMart، وهي شركة تجارة إلكترونية خيالية نما كتلة (cluster) الخاصة بها أسرع من أمانها. عشرة تحديات، واحد لكل خطر من OWASP (بالإضافة إلى تحدٍ إضافي) — استغل كل نقطة ضعف، التقط العلم، ثم طبق الإصلاح وأثبت صحته باستخدام المدقق.

الكتاب المقدس (الشركة، الخدمات، مساحات الأسماء، مخطط الأعلام) موجود في labs/NIMBUSMART.md.

كل شيء يعمل محليًا على kind. لا تقم أبدًا بتشغيل الملفات الضعيفة ضد كتلة حقيقية.

بُني بواسطة @hac01.

ما يغطيه هذا

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

• أمان الحاويات والعقد — الحاويات المميزة (privileged pods)، ووصلات hostPath، والاختراق العقدي (K01).
• RBAC والتفويض — أدوار ClusterRole ذات العلامات البدل (wildcard)، وحسابات الخدمة ذات النطاق الواسع (over-scoped ServiceAccounts)، وكيف يمكن لرمز مسروق واحد الوصول إلى جميع الأسرار (K02, K09).
• إدارة الأسرار — مفاتيح API مكتوبة بشكل ثابت في متغيرات البيئة/ConfigMaps والبدائل الأكثر أمانًا (K03).
• التحكم في القبول (Admission control) والسياسات — ما الذي يتسرب عندما لا يوجد ما يفرض القواعد على مستوى الكتلة، وكيف يوقفه أمان قبول الحاوية (Pod Security Admission)/محركات السياسات (K04).
• تقسيم الشبكة — شبكات الحاويات المسطحة مقابل الإغلاق باستخدام NetworkPolicy (K05).
• المكونات المكشوفة — لوحات التحكم الداخلية وواجهات API المنشورة عبر NodePort (K06).
• نظافة مكونات الكتلة — الرموز الافتراضية، والحصص الناقصة، والإصدارات القديمة/الضعيفة (K07).
• الحركة الجانبية من الكتلة إلى السحابة — حاوية تصل إلى نقطة نهاية البيانات الوصفية (IMDS) للعقدة لسرقة بيانات اعتماد سحابية (K08).
• المصادقة — الوصول المجهول (anonymous) إلى API والرموز الافتراضية المثبتة بشكل زائد (K09).
• التسجيل والمراقبة — اكتشاف (أو الفشل في اكتشاف) تسريب البيانات الصامت، ولماذا تعتبر سلسلة التدقيق مهمة (K10).
• سلسلة التوريد — صور :latest غير موثوقة وقابلة للتغيير يتم شحنها إلى الإنتاج (تحدٍ إضافي).

لكل تحدٍ تحصل على:

• إحاطة مهمة — سيناريو NimbusMart، ونقطة انطلاقك، والهدف.
• علم يجب التقاطه — لا يمكن الوصول إليه إلا عن طريق تنفيذ الاستغلال (على العقدة، في مساحة اسم أخرى، عبر الشبكة). أرسله في تطبيق الويب؛ لوحة النتائج تتابع تقدمك ونقاطك (التخزين المحلي للمتصفح).
• تلميحات تدريجية بالإضافة إلى شرح كامل — إشارات أولاً، ثم الحل الكامل عندما تريده.
• نظرة عامة معمقة — ما هي نقطة الضعف، وكيف يسيء المهاجمون استخدامها، والتأثير، والأسباب الجذرية.
• دليل دفاعي — تصحيحات ملموسة وقائمة ممارسات جيدة.
• مدقق آلي — برنامج Go يقوم بمسح كتلتك ويؤكد، لكل خطر، ما إذا كان الإصلاح قائمًا.

المتطلبات الأساسية

قم بتثبيت هذه قبل البدء. يقوم سكريبت الإعداد بالتحقق من الأربعة الأولى ويخرج بسرعة برسالة واضحة إذا كان أي منها مفقودًا.

أوامر brew مخصصة لنظام macOS. على Linux، استخدم مدير الحزم الخاص بك أو التعليمات من المصدر المرتبط.

بداية سريعة (موصى بها) — كل شيء داخل كتلة واحدة

تطبيق الويب، وطرفية المتصفح، والمدقق يمكنهم جميعًا العمل داخل كتلة kind. أمر واحد يشغل كل شيء ويطبع الرابط:

./setup.sh          # أو: make up
#   - ينشئ كتلة kind، ويبني ويحمل الصور، وينشر، وينتظر حتى يصبح جاهزًا
#   - تطبيق الويب:  http://localhost:30090
#   - الطرفية: زر 'Terminal' في تطبيق الويب

./setup.sh (ينشئ) الكتلة من جديد مع تعيينات المنافذ الصحيحة، ويبني الصورتين (nimbusmart-ctf-web, nimbusmart-ctf-terminal)، ويحملها إلى kind، ويطبق deploy/. التشغيل الأول يسحب الصور الأساسية ويستغرق حوالي 1-2 دقيقة.

./setup.sh            # كتلة جديدة + منصة كاملة (يحذف أي كتلة قديمة باسم 'owasp-labs')
./setup.sh --keep     # يعيد استخدام كتلة 'owasp-labs' الموجودة إذا كانت موجودة

ثم افتح **http://localhost:30090**، اختر تحدٍ، واستخدم زر Terminal في المتصفح لقيادة الكتلة.

تعمل حاوية الطرفية كحساب خدمة cluster-admin، لذا فإن الطرفية في المتصفح تقود هذه الكتلة نفسها — قم بتشغيل kubectl apply -f labs/... و owasp-k8s-checker --check kNN هناك.

تحذير: الطرفية داخل المتصفح تعادل cluster-admin عبر WebSocket. إنها آمنة فقط لأنها مقيدة بكتلة kind المحلية المؤقتة على localhost. لا تقم أبدًا بتعريض المنافذ 30080/30090/30091 لشبكة غير موثوقة.

إزالة الإعداد

kind delete cluster --name owasp-labs      # أو: make cluster-down

هيكل المستودع

.
├── setup.sh         سكريبت بدء التشغيل أحادي الأمر (كتلة + صور + نشر)
├── Makefile         أهداف مساعدة — قم بتشغيل `make help` لعرضها
├── web/             تطبيق Next.js + React (سمة بيضاء/بنفسجية) — واجهة المستخدم
├── labs/            ملفات Kubernetes الفعلية لكل خطر (vulnerable.yaml + fixed.yaml + README)
│   ├── NIMBUSMART.md        الكتاب المقدس: الشركة، مساحات الأسماء، مخطط الأعلام
│   └── kind-cluster.yaml    إعداد الكتلة المحلية المشتركة (تعيينات المنافذ)
├── deploy/          ملفات المنصة داخل الكتلة (ويب + طرفية + RBAC) + build.sh
├── terminal-server/ النهاية الخلفية WebSocket للطرفية داخل المتصفح
└── checker/         برنامج Go للتحقق من صحة الكتلة مقابل قائمة Top 10

أهداف make المفيدة (make help يعرض الكل):

OWASP Kubernetes Top 10 — 2025

كل تحدٍ هو نقطة ضعف حقيقية في كتلة NimbusMart — اختر هدفًا، استغله، التقط العلم، ثم صححه وأثبت الإصلاح باستخدام المدقق.

ما تغير عن 2022: تم توسيع التفويض (كان RBAC)؛ إعادة ترتيب الأسرار، الشبكة، المصادقة والتسجيل؛ إضافة المكونات المكشوفة بشكل زائد (K06) و الحركة الجانبية من الكتلة إلى السحابة (K08)؛ دمج المكونات غير المهيأة والقديمة في K07؛ نقل سلسلة التوريد إلى تحدٍ إضافي. انظر labs/NIMBUSMART.md للحصول على خريطة كاملة من التحدي إلى الخدمة إلى نقطة الضعف، الصعوبة، والنقاط (2000 عبر 10 تحديات، +300 للتحدي الإضافي).

سير العمل اليدوي/التطويري (بدون المنصة داخل الكتلة)

تفضل تشغيل واجهة المستخدم محليًا وقيادة المختبرات من شاشتك الخاصة؟ يمكنك ربط القطع يدويًا.

1. تشغيل تطبيق الويب محليًا

cd web
npm install
npm run dev
# افتح http://localhost:3000       (أو: make web)

تعمل النهاية الخلفية للطرفية بشكل منفصل على :30091 باستخدام ~/.kube/config الخاص بك:

make terminal-local

2. إنشاء كتلة مختبر

kind create cluster --config labs/kind-cluster.yaml    # أو: make cluster
kubectl config use-context kind-owasp-labs

3. لعب تحدٍ

كل تحدٍ له ملف README خاص به، لكن النمط هو نفسه:

# بعض التحديات تزرع هدفًا أولاً (ملف عقدة، سر عمليات، ...)
kubectl apply -f labs/k01-insecure-workload/setup.yaml       # فقط إذا كان موجودًا

# نشر المورد الضعيف واستغلاله لالتقاط العلم
kubectl apply -f labs/k01-insecure-workload/vulnerable.yaml
# ... اتبع إحاطة المهمة / التلميحات في تطبيق الويب، احصل على FLAG{...}، قدمها...

# طبق النسخة المحصنة وأكد أن مسار العلم قد أغلق
kubectl delete -f labs/k01-insecure-workload/vulnerable.yaml
kubectl apply  -f labs/k01-insecure-workload/fixed.yaml

أعد تعيين كل شيء بين التحديات باستخدام make clean-labs.

4. التحقق باستخدام المدقق

cd checker
go run . --list            # عرض جميع الفحوصات
go run . --check k01       # تشغيل فحص واحد
go run . --all             # مسح الكتلة بأكملها
go run . --all --json      # قابل للقراءة آليًا (لـ CI)
go run . --all -n apps     # قصر النطاق على مساحة اسم

يخرج المدقق بقيمة غير صفرية إذا فشل أي فحص، لذا يمكنه التحكم في CI.

بناء ملف ثنائي مستقل:

cd checker
go build -o owasp-k8s-checker .    # أو: make checker
./owasp-k8s-checker --all

كيف يرتبط المدقق بالمختبرات

كل checker/checks/kNN.go يتحقق من نفس عنصر التحكم الذي يعلمه المختبر المطابق. انشر fixed.yaml، وقم بتشغيل go run . --check kNN، ويجب أن ترى PASS. انشر vulnerable.yaml ونفس الفحص يبلغ عن النتائج المحددة.

السلامة: ملفات الضعف قابلة للاستغلال عن قصد. استخدم فقط كتلة kind/minikube محلية ومؤقتة. احذفها عندما تنتهي: kind delete cluster --name owasp-labs.