Security+ Academy · درس

أمان Kubernetes: RBAC وسياسات الشبكة وأمان Pod

اضبطوا أدوار RBAC في Kubernetes، وفرضوا سياسات شبكة تقيّد حركة المرور بين Pods، وطبّقوا معايير أمان Pods للحد من تصعيد الامتيازات.

أمان Kubernetes: RBAC وسياسات الشبكة وأمان Pod درس مجاني في Security+ Academy على CoddyKit. هذا هو الدرس 2 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في Security+ Academy، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة Security+ Academy 4 دروس في المجموع.

نظرة عامة على سطح هجوم Kubernetes

ينسّق Kubernetes أحمال العمل التي تعمل داخل الحاويات على نطاق واسع، لكن تعقيده ينشئ سطح هجوم واسعًا. وتشمل المكونات الرئيسية التي يجب تأمينها: API Server (وهو مركز مستوى التحكم؛ ويمنح اختراقه السيطرة على المجموعة بأكملها)، وetcd (قاعدة بيانات حالة المجموعة؛ تخزّن الأسرار بترميز base64، ولذلك يجب تشفيرها أثناء السكون)، وkubelet (وكيل العقدة؛ إذ تتيح واجهة برمجة تطبيقات kubelet غير الموثّقة تنفيذ أي Pod)، ووقت تشغيل الحاويات (Docker/containerd)، والبنية الشبكية التي تصل بين جميع الـ Pods. وينبغي للمتقدمين لشهادة Security+ فهم أن أخطاء تهيئة Kubernetes تُعد من أكثر نتائج فحص أمان السحابة شيوعًا.

RBAC: التحكم في الوصول المستند إلى الأدوار في Kubernetes

يتحكم RBAC (Role-Based Access Control) في Kubernetes في المستخدمين وحسابات الخدمة والعمليات التي يمكنها تنفيذ إجراءات معينة على موارد API معينة. ويتكون النموذج من أربعة كائنات: Role (صلاحيات ضمن مساحة أسماء)، وClusterRole (صلاحيات على مستوى المجموعة)، وRoleBinding (يمنح Role لموضوع داخل مساحة أسماء)، وClusterRoleBinding (يمنح ClusterRole لموضوع على مستوى المجموعة). ويترجم كل أمر kubectl إلى استدعاء API يجري التحقق منه مقابل قواعد RBAC. وإذا لم تتم تهيئة RBAC، فقد يمتلك أي مستخدم موثّق (أو حساب خدمة) صلاحية إدارية.

# Create a role allowing only pod reads in 'default' namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: default
rules:
- apiGroups: [''] 
  resources: ['pods']
  verbs: ['get', 'list', 'watch']

حسابات الخدمة وأقل قدر من الامتيازات

يعمل كل Pod في Kubernetes ضمن حساب خدمة، وهو هوية تُستخدم للمصادقة على API. وتستخدم الـ Pods افتراضيًا حساب الخدمة default في مساحة أسمائها، وقد يمتلك هذا الحساب صلاحيات واسعة. ويتطلب مبدأ أقل قدر من الامتيازات إنشاء حسابات خدمة مخصصة لكل تطبيق، بحيث لا تمتلك إلا الصلاحيات التي يحتاج إليها. بالإضافة إلى ذلك، فإن ضبط automountServiceAccountToken: false في الـ Pods التي لا تحتاج إلى الوصول إلى API يمنع تركيب رمز حساب الخدمة في نظام ملفات الـ Pod، حيث يمكن لتطبيق مخترق استخدامه لإجراء استدعاءات API.

# Pod spec: disable service account token auto-mount
apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  serviceAccountName: myapp-sa
  automountServiceAccountToken: false
  containers:
  - name: myapp
    image: myapp:v1.0

سياسات الشبكة: المنع الافتراضي

افتراضيًا في Kubernetes، يمكن لجميع الـ Pods الاتصال بجميع الـ Pods الأخرى في أي مساحة أسماء. ويمكن لـ Pod مخترق أن يحاول فورًا الوصول إلى قواعد البيانات وواجهات API الداخلية والخدمات المصغرة الأخرى. وتحدد موارد Kubernetes NetworkPolicy قواعد تقيّد حركة المرور بين الـ Pods استنادًا إلى التصنيفات ومساحات الأسماء والمنافذ. ويتمثل النهج الموصى به في تطبيق سياسة شبكة «المنع الافتراضي للجميع» في كل مساحة أسماء، ثم إضافة قواعد سماح صريحة لمسارات الاتصال المطلوبة. وتجدر الإشارة إلى أن NetworkPolicy تتطلب إضافة CNI تدعمها (مثل Calico وCilium وWeave)، إذ يتجاهل Kubernetes القياسي NetworkPolicy من دون إضافة CNI متوافقة.

# Default deny all ingress and egress in a namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

معايير أمان الـ Pods: استبدال PSP

تحل Pod Security Standards (PSS)، التي قُدّمت في Kubernetes 1.23 وأصبحت مستقرة في 1.25، محل Pod Security Policy (PSP) المهملة، وذلك من خلال ثلاثة ملفات تعريف مدمجة تُفرض على مستوى مساحة الأسماء: Privileged (غير مقيّد، لمكونات النظام)، وBaseline (يمنع تصعيدات الامتيازات المعروفة مثل الحاويات ذات الامتيازات والوصول إلى شبكة المضيف)، وRestricted (مقوّى، ويتطلب مستخدمين غير جذر، ويسقط جميع الإمكانات، ويفرض أنظمة ملفات جذر للقراءة فقط). وتُوسم مساحات الأسماء لفرض مستوى من السياسات، وتُرفض الـ Pods التي تنتهكه عند القبول.

# Label namespace to enforce 'restricted' pod security
kubectl label namespace production \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted

إدارة الأسرار في Kubernetes

تخزّن Secrets في Kubernetes البيانات الحساسة مثل كلمات المرور والرموز المميّزة وشهادات TLS. وتُخزّن Secrets افتراضيًا في etcd كقيم مرمّزة بترميز base64، لا كقيم مشفّرة. ويمكن لأي شخص يستطيع قراءة etcd أو يمتلك صلاحيات RBAC كافية فك ترميزها بسهولة. وتشمل أفضل الممارسات: تفعيل التشفير أثناء السكون لـ etcd باستخدام AES-GCM، مع تخزين المفتاح في KMS (مثل AWS KMS أو GCP KMS)، والتكامل مع مدير أسرار خارجي مثل HashiCorp Vault أو AWS Secrets Manager عبر Secrets Store CSI Driver، وتقييد الوصول إلى Secret باستخدام RBAC بحيث لا يستطيع قراءتها إلا حسابات الخدمة التي تحتاج إليها.

# Enable etcd encryption at rest (encryption configuration)
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
  - secrets
  providers:
  - aescbc:
      keys:
      - name: key1
        secret: <base64-encoded-32-byte-key>

وحدات التحكم في القبول: بوابات الأمان

وحدات التحكم في القبول هي إضافات في خادم API الخاص بـ Kubernetes تعترض طلبات API بعد المصادقة والتفويض، ولكن قبل حفظ الكائنات، مما يتيح لها التحقق من الطلبات أو تعديلها أو رفضها. وتشمل وحدات التحكم المرتبطة بالأمان: PodSecurity (يفرض معايير أمان الـ Pods)، وImagePolicyWebhook (يتيح التحقق الخارجي من توقيع الصور)، وAlwaysPullImages (يفرض سحب الصور حديثًا لمنع استخدام الصور الخبيثة المخزنة مؤقتًا محليًا)، وOPA/Gatekeeper (Open Policy Agent، وهو الأكثر مرونة، إذ يتيح سياسات مخصصة مكتوبة بلغة Rego لفرض أي قاعدة أمنية مؤسسية).

تقوية مكونات المجموعة

تُعد تقوية مكونات مستوى التحكم في Kubernetes أمرًا بالغ الأهمية: إذ ينبغي أن يتضمن خادم API الإعداد --anonymous-auth=false لتعطيل الوصول غير الموثّق، وأن تتم تهيئة --audit-log-path لتسجيل جميع أنشطة API، وأن يُستخدم TLS لجميع الاتصالات. وينبغي أن يضبط kubelet الخيار --authorization-mode=Webhook (وليس AlwaysAllow) مع تعطيل المصادقة المجهولة. كما ينبغي أن يستخدم etcd تشفير TLS بين النظراء والعملاء، وأن يكون الوصول إليه عبر الشبكة مقيّدًا (بحيث لا يمكن الوصول إليه إلا من خادم API)، وأن تُشفّر البيانات أثناء السكون. ويوفر CIS Kubernetes Benchmark قائمة تحقق شاملة لجميع إعدادات المكونات.

# Check kubelet configuration for security issues
kubectl get --raw /api/v1/nodes/nodename/proxy/configz | jq '.kubeletconfig | {anonymousAuth: .authentication.anonymous.enabled, authorization: .authorization.mode}'

عزل مساحات الأسماء وتعدد المستأجرين

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

التسجيل التدقيقي ومراقبة وقت التشغيل

يسجل التسجيل التدقيقي في Kubernetes كل طلب من طلبات API: الجهة التي أرسلته، ومصدره، والإجراء المطلوب، والمورد المستهدف. وتُعد سجلات التدقيق ضرورية للتحقيق الجنائي بعد وقوع حادث أمني، ولاكتشاف السلوكيات الشاذة مثل عمليات ربط الأدوار غير المعتادة، أو الوصول إلى الأسرار، أو تنفيذ أوامر exec داخل حاويات الإنتاج. ينبغي بث سجلات التدقيق إلى نظام SIEM مركزي. يوفر Falco مراقبة لسلوك الحاويات أثناء التشغيل، بينما توفر خدمات Kubernetes المُدارة سحابيًا (EKS وGKE وAKS) تكاملًا أصليًا لسجلات التدقيق مع منصات التسجيل الخاصة بها.

# Check recent kubectl exec events in audit log
grep '"verb":"create".*"resource":"pods".*"subresource":"exec"' /var/log/kubernetes/audit.log | tail -20

أمان سلسلة التوريد: مصدر الصورة

يضمن أمان سلسلة التوريد في Kubernetes وصول الصور الموثوقة والمتحقق منها فقط إلى بيئة الإنتاج. وتتضمن توصيات CNCF الخاصة بـأمان سلسلة التوريد ما يلي: التحقق من توقيعات الصور باستخدام Cosign قبل النشر (مع فرض ذلك عبر وحدات التحكم في القبول)، وإنشاء SBOMs (قوائم مواد البرمجيات) لكل صور الحاويات والتحقق منها لتتبع مصدر المكونات، وتثبيت الصور باستخدام المُلخّصات (myimage@sha256:abc123) بدلًا من الوسوم القابلة للتغيير، وفحص جميع مخططات Helm التابعة لجهات خارجية بحثًا عن أخطاء الإعداد والثغرات قبل النشر.

# Pin image to digest for immutability
# Instead of:
image: nginx:latest
# Use:
image: nginx@sha256:a3e2a7a3d7f94e...  # immutable digest

تحقق سريع

اختبر مدى فهمك لمفاهيم CompTIA Security+ (SY0-701) الواردة في هذا الدرس.

مراجعة الدرس

تعلمت في هذا الدرس أن: Kubernetes RBAC يتحكم في الوصول إلى API من خلال Roles وClusterRoles وBindings، ولذلك يجب دائمًا تطبيق مبدأ أقل قدر من الصلاحيات على حسابات الخدمة؛ وأن إعدادات NetworkPolicy بالمنع الافتراضي تمنع الحركة الجانبية بين الحاويات ومساحات الأسماء؛ وأن معايير أمان Pod تفرض تحصين الحاويات على مستوى مساحة الاسم، فتحظر الحاويات ذات الصلاحيات المرتفعة، والوصول إلى شبكة المضيف، والتنفيذ بصلاحيات المستخدم الجذر. بعد ذلك سنستكشف أمان الحوسبة عديمة الخوادم وأسطح الهجوم على مستوى الوظائف.

الأسئلة الشائعة

هل درس «أمان Kubernetes: RBAC وسياسات الشبكة وأمان Pod» مجاني؟

نعم — نص درس «أمان Kubernetes: RBAC وسياسات الشبكة وأمان Pod» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة Security+ Academy، انتقل إلى CoddyKit PRO. تتضمن دورة Security+ Academy 4 دروس في المجموع.

ماذا ستتعلم في «أمان Kubernetes: RBAC وسياسات الشبكة وأمان Pod»؟

اضبطوا أدوار RBAC في Kubernetes، وفرضوا سياسات شبكة تقيّد حركة المرور بين Pods، وطبّقوا معايير أمان Pods للحد من تصعيد الامتيازات. تتمرن على Security+ Academy مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.

هل أحتاج إلى خبرة سابقة لأبدأ Security+ Academy؟

لا تُشترط خبرة سابقة. Security+ Academy على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 2 من أصل 4.

كم من الوقت يستغرق درس «أمان Kubernetes: RBAC وسياسات الشبكة وأمان Pod»؟

معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.

هل يمكنني كتابة وتشغيل أكواد في درس Security+ Academy هذا؟

نعم. كل درس في Security+ Academy يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.

جميع الدروس في هذه الدورة

أمان الحاويات: تقوية الصور والحماية أثناء التشغيل
أمان Kubernetes: RBAC وسياسات الشبكة وأمان Pod
أمان الحوسبة عديمة الخوادم والدوال
فحص أمان البنية التحتية باعتبارها شيفرة

← العودة إلى Security+ Academy