DevOps Bootcamp · درس

سياسات الشبكة للعزل

تحكّم في تدفق حركة الشبكة بين الوحدات ومساحات الأسماء باستخدام Kubernetes Network Policies

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

سياسات الشبكة: شرطة المرور

يمكن للـ Pods في Kubernetes التحدث إلى بعضها بحرية افتراضيًا. وهذا أمر رائع من ناحية المرونة، لكنه ليس مثاليًا دائمًا من ناحية الأمان.

تعمل سياسات الشبكة كجدران حماية للـ Pods، إذ تتحكم في حركة مرور الشبكة المسموح بها إلى الداخل (ingress) وإلى الخارج (egress).

افتراضيًا: يمكن لجميع الـ Pods التواصل

افتراضيًا، بعد نشر Pod، يمكنه التواصل مع أي Pod آخر في الكتلة، بغض النظر عن الـ namespace. ويسهّل نموذج «الشبكة المسطحة» هذا الإعداد، لكنه يفتقر إلى العزل.

في بيئات الإنتاج، تحتاج غالبًا إلى تقييد الاتصالات لتعزيز الأمان ومنع الوصول غير المصرح به بين مكونات التطبيق.

قواعد Ingress وEgress

تحدد سياسات الشبكة القواعد التي توضّح كيفية السماح للـ Pods بالتواصل. وتركز أساسًا على نوعين من حركة المرور:

Ingress: حركة المرور الواردة إلى Pod.
Egress: حركة المرور الصادرة من Pod.

تُطبَّق هذه القواعد على Pods محددة باستخدام التسميات، ويمكنها استهداف Pods أو namespaces أو نطاقات IP أخرى.

متطلب إضافة CNI

سياسات الشبكة ليست سحرًا! لكي تعمل، يجب أن تحتوي كتلة Kubernetes على إضافة واجهة شبكة الحاويات (CNI) تدعمها.

توفر إضافات CNI الشائعة مثل Calico وCilium وWeave Net هذه الوظيفة. ومن دون إضافة CNI داعمة، لن يكون لسياسات الشبكة أي تأثير.

بنية السياسة

تُعرَّف سياسات الشبكة باستخدام YAML. وتتضمن الحقول الأساسية ما يلي:

metadata.name: اسم فريد للسياسة.
spec.podSelector: يحدد الـ Pods التي تنطبق عليها هذه السياسة.
spec.policyTypes: يحدد ما إذا كانت السياسة تنطبق على Ingress أو Egress أو كليهما.
spec.ingress/spec.egress: يسرد قواعد حركة المرور المسموح بها.

حظر جميع حركة المرور الواردة

لننشئ سياسة لمنع جميع حركة المرور الواردة إلى الـ Pods التي تحمل التسمية app: backend في الـ namespace الحالي. وهذه نقطة بداية شائعة لوضع أمني يعتمد مبدأ «المنع افتراضيًا».

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-backend-ingress
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress: [] # An empty ingress list denies all incoming traffic

السماح بـ Ingress من الواجهة الأمامية

لنعدّل سياستنا الآن للسماح بحركة المرور الواردة من الـ Pods التي تحمل التسمية app: frontend في الـ namespace نفسه فقط، إلى الـ Pods التي تحمل التسمية app: backend.

لاحظ قسم from الذي يحدد الـ Pods المصدر.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

التحكم في حركة المرور الصادرة

كما هو الحال مع ingress، يمكنك التحكم في حركة المرور الصادرة (egress). سننشئ هنا سياسة تسمح للـ Pods التي تحمل التسمية app: backend بإرسال طلبات صادرة إلى الـ Pods التي تحمل التسمية app: database فقط.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-egress-to-db
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Egress
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database

استهداف Namespaces أخرى

ماذا لو كانت الواجهة الأمامية في namespace مختلف، مثل web-apps؟ يمكنك استخدام namespaceSelector لاستهداف الـ Pods عبر namespaces مختلفة.

تسمح هذه السياسة بحركة ingress إلى الـ Pods التي تحمل التسمية app: backend من أي Pod في namespace‏ web-apps.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-apps-ingress
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: web-apps
      podSelector: {} # All pods in the selected namespace

تحدي السياسات

لنفترض وجود Pod يحمل التسميتين app: web وenv: prod. أي سياسة شبكة ستسمح فقط بحركة المرور الواردة من الـ Pods الموجودة في namespace‏ monitoring؟

مراجعة: تأمين شبكتك

أحسنت! لقد تعلمت كيف توفر سياسات الشبكة في Kubernetes عزلًا مهمًا للشبكة من أجل تطبيقاتك.

تعمل كجدران حماية للـ Pods.
تتحكم في حركة المرور الواردة (in) والصادرة (out).
تتطلب إضافة CNI تدعمها.
تُعرَّف باستخدام YAML مع podSelector وpolicyTypes وتعريفات القواعد.
يمكنها استهداف الـ Pods حسب التسميات، وحتى استهداف namespaces بأكملها.

استخدمها لفرض نموذج شبكة يعتمد مبدأ «أقل قدر من الامتيازات»!

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

هل درس «سياسات الشبكة للعزل» مجاني؟

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

ماذا ستتعلم في «سياسات الشبكة للعزل»؟

تحكّم في تدفق حركة الشبكة بين الوحدات ومساحات الأسماء باستخدام Kubernetes Network Policies تتمرن على DevOps Bootcamp مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.

هل أحتاج إلى خبرة سابقة لأبدأ DevOps Bootcamp؟

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

كم من الوقت يستغرق درس «سياسات الشبكة للعزل»؟

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

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

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

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

التحكم في الوصول المستند إلى الأدوار (RBAC)
سياسات الشبكة للعزل
معايير أمان الوحدات
حسابات الخدمة وهوية أحمال العمل

← العودة إلى DevOps Bootcamp