يُعد اختبار أخصائي أمان Kubernetes المعتمد (CKS) تقييماً قائماً على الأداء ومحايداً تجاه الموردين (غير مرتبط بشركة محددة)، حيث يختبر مهارات أمان Kubernetes التي يتم تنفيذها عبر سطر الأوامر (CLI) على مجموعات (clusters) Kubernetes. يستخدم الاختبار حالياً الإصدار Kubernetes v1.35، إلا أن مؤسسة Linux Foundation تقوم بمواءمة بيئة الاختبار مع إصدارات Kubernetes الفرعية الحديثة؛ لذا يُنصح بالتحقق من الإصدار الحالي والمحتوى الدراسي قبل الاعتماد على أمر معين أو ميزة محددة أو وزن نسبي لأحد المجالات. تشمل المجالات الستة: إعداد المجموعة (Cluster Setup) بنسبة 15%، وتعزيز أمان المجموعة (Cluster Hardening) بنسبة 15%، وتعزيز أمان النظام (System Hardening) بنسبة 10%، وتقليل ثغرات الخدمات المصغرة (Microservices) بنسبة 20%، وأمان سلسلة التوريد (Supply Chain Security) بنسبة 20%، والمراقبة وتسجيل الأحداث وأمان وقت التشغيل (Monitoring, Logging and Runtime Security) بنسبة 20%. يعتمد الاختبار على الأداء ويتم إجراؤه عبر الإنترنت تحت إشراف مراقب؛ حيث يتعين عليك حل مهام متعددة باستخدام سطر الأوامر خلال ساعتين، ويُشترط اجتياز اختبار “مسؤول Kubernetes المعتمد” (CKA) أولاً.
يمكننا بعد ذلك استعراض تسلسل المهام وتوزيع المجالات الحالي.
تُعتبر مهمة CKS مكتملة عندما تتحقق حالة الأمان المطلوبة وتتوفر لديك أدلة تثبت أن عنصر التحكم (control) المعني في Kubernetes يفرض هذه الحالة. قد يؤدي حفظ أمر ما إلى إنشاء كائن (object) بسرعة، لكنه لا يضمن أن حمل العمل (workload) يقع ضمن نطاق سياسة معينة، أو أن الهوية (identity) تمتلك فقط أذونات API المقصودة، أو أن قاعدة الكشف تراقب سلوك وقت التشغيل المتوقع. لذا، اقرأ المتطلبات المتعلقة بالموارد المستهدفة، وحدود الأمان، ومؤشرات التحقق المطلوبة قبل إجراء أي تغيير في الإعدادات.
في ظل ضيق الوقت، قم بإنشاء مخرجات (artifacts) صغيرة وقابلة للفحص. تشمل هذه عادةً ملف تعريف (manifest) يحدد الحالة المقصودة، وأمراً محدود النطاق لتطبيق هذه الحالة أو فحصها، ومخرجات توضح حالة الكائن أو سلوكه بعد التغيير. يثبت ملف التعريف الإعدادات التي تم إرسالها إلى Kubernetes API، بينما تثبت مخرجات الأمر فقط حالة المورد أو الاستجابة المرصودة في تلك اللحظة، وضمن العنقود (cluster) ونطاق الأسماء (namespace) المحددين. ولا يثبت أي منهما بمفرده أن جميع المسارات آمنة.
اتبع دورة عمل قابلة للتكرار. أولاً، حدد سياق العنقود النشط ونطاق الأسماء المستهدف. بعد ذلك، افحص الكائنات والتسميات (labels) الموجودة التي تحدد اختيار السياسة أو نطاق التفويض. طبّق أصغر تغيير يعالج الشرط المحدد، ثم تحقق من النتيجة من خلال ملاحظة تتوافق مع ذلك الشرط. وأخيراً، احتفظ بسياق كافٍ للتراجع عن أي تغيير غير صحيح، لا سيما عند تعديل إعدادات العنقود بالكامل، أو ملفات العقدة (node files)، أو إعدادات خادم API.
قاعدة تشغيلية فضّل الأدلة المرتبطة بالنطاق المطلوب على استخدام أمر مألوف قد يغير موارد غير ذات صلة.
سنقوم خلال هذه الدورة بتأمين حمل عمل افتراضي خاص بقطاع التجزئة داخل نطاق الأسماء shop. يُعد نطاق الأسماء (namespace) نطاقاً في Kubernetes يجمع الموارد المرتبطة به، ويمكن أن يشكل حدوداً للتفويض والسياسات. يحتوي حمل العمل على مسار دخول (ingress) يمكن الوصول إليه من الخارج يؤدي إلى orders-api:1.0 عبر المنفذ 8080؛ ويقوم هذا التطبيق باستدعاء payments-api:1.0 عبر المنفذ 8443؛ ثم يستخدم payments-api قاعدة البيانات orders-db. في هذا النموذج، لا يمكن الوصول إلى أي حمل عمل من خارج العنقود باستثناء مسار الدخول (ingress).
يستخدم كل تطبيق ServiceAccount خاصاً به، وهي هوية في Kubernetes يمكن أن تستخدمها وحدة التشغيل (Pod) عند استدعاء Kubernetes API. يستخدم التطبيق orders-api الحساب orders-sa، بينما يستخدم التطبيق payments-api الحساب payments-sa. يتيح لنا الحفاظ على استقلالية هذه الهويات اختبار تفويض “الحد الأدنى من الصلاحيات” (least-privilege) بشكل منفصل عن إمكانية الوصول عبر الشبكة، ومصدر الصورة، وقيود الـ Pod، ومؤشرات وقت التشغيل. وتتمثل القاعدة القابلة لإعادة الاستخدام في تحديد مسار عبء العمل (workload path) وحدود الهوية قبل اختيار إجراء أمني.
يمكننا الآن تتبع حدود عبء العمل التي يتعين على آليات الدفاع اللاحقة الحفاظ عليها.