مستوى المقال: متوسط — يفترض إنك شغّلت Cluster Kubernetes قبل كده، وتعرف YAML و kubectl apply، ومحتاج تضيف طبقة عزل شبكي بين الـ pods.

افتراض Kubernetes الافتراضي إن أي pod في الـ cluster يقدر يكلّم أي pod تاني في أي namespace. لو حد اخترق pod بسيط زي الـ frontend، يقدر يطبع مباشرة سؤال على pod الـ database. Network Policy بتقفل الباب ده بسطر podSelector واحد، وبتمنع نسبة كبيرة من lateral movement في حادث أمني فعلي.

المشكلة باختصار

كل pod في Kubernetes بياخد IP من شبكة الـ cluster، والافتراض: الشبكة دي flat. ركّز هنا — الـ kube-proxy بيوصّل الـ TCP بين أي اتنين pods بدون ما يسأل. لو عندك microservice للـ users واتنين للتقارير وواحد للدفع، الأربعة بيكلموا بعض من غير قاعدة. Verizon Data Breach Investigations Report 2024 بيقول إن lateral movement بيظهر في حوالي 70% من الـ incidents بعد الـ initial access. يعني المشكلة مش الاختراق الأول، المشكلة المسافة اللي المهاجم يقدر يقطعها بعده.

Network Policy ببساطة قبل ما ندخل في التفاصيل

تخيّل عمارة سكنية فيها 30 شقة ومفيش أبواب بين الشقق ولا قفل على المدخل. أي حد دخل العمارة يقدر يدخل أي شقة. ده شكل الـ cluster بدون Network Policy. لما تطبّق الـ Policy ده، بتحوّل الموقف لعمارة عادية: كل شقة ليها قفل، وبتحدد بنفسها مين يدخل من خلال intercom بسيط. الفرق إن القفل مش بيتقفل تلقائي — إنت اللي بتقول للعمارة "من اليوم اقفلوا كل شقة افتراضياً، وعدّلوا قائمة المسموح لهم مع الوقت".

التعريف العلمي الدقيق: NetworkPolicy هي resource أصلية في Kubernetes API تحت networking.k8s.io/v1. بتحدد قائمة allow rules على مستوى podSelector لـ ingress (الطلبات الداخلة) و egress (الطلبات الخارجة). الافتراض implicit: لو في policy مطبقة على pod، أي طلب مش matching بيترفض. الـ policy نفسها بتنفّذها الـ CNI plugin (Calico, Cilium, Antrea). الـ kube-proxy لا بيشوف ولا بيطبّق الـ policies — ده شغل الـ CNI بالظبط.

ازاي تكتب أول NetworkPolicy

نبدأ بقاعدة شائعة جداً: السماح للـ frontend بس يكلّم الـ backend على بورت 8080، ومنع أي pod تاني. الـ frontend بـ label app=frontend والـ backend بـ app=backend.

# network-policy-backend.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-allow-frontend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

اعمل apply وافحص:

kubectl apply -f network-policy-backend.yaml
kubectl describe networkpolicy backend-allow-frontend -n production

اختبر بسرعة من pod تاني مش frontend:

kubectl run tmp --rm -it --image=curlimages/curl -- \
  curl -m 5 backend.production.svc.cluster.local:8080
# المتوقع: timeout بعد 5 ثواني — الـ policy رفضت الاتصال

ركّز هنا في تفصيلة مهمة: الـ policy لما بتتطبق على pod، الـ pod بيدخل في وضع "default deny" لكل ingress مش مسموح به صراحة. يعني policy واحدة فيها allow للـ frontend بتمنع تلقائياً أي pod تاني. الافتراض المخفي ده بيلخبط ناس كتير في الأول.

4 أنماط شائعة لازم تعرفها

1. Default deny للـ namespace كلها: policy فاضية بـ podSelector فارغ بتمنع كل ingress في namespace كاملة. بعدين بتضيف allow rules فوقها بالتدريج. ده الـ baseline اللي CNCF Security Whitepaper بتوصي بيه في أي production cluster.
2. Allow from specific namespace: تستخدم namespaceSelector لو الـ frontend في namespace والـ backend في تانية. مثلاً تسمح لـ kube-system بطلبات DNS بس على بورت 53.
3. Egress restrictions: منع الـ pod من يطلع للإنترنت أو لـ subnet معيّن. مفيد جداً لـ pods حساسة زي إدارة الـ secrets. ده اللي بيفرق وقت الاختراق — المهاجم لو دخل pod مش هيقدر يبعت data خارج الـ cluster.
4. Allow from CIDR: تسمح من range IPs محدد. بدل ما تعتمد على labels تستخدم ipBlock. ضروري لما الـ traffic جاي من خارج الـ cluster (مثلاً Ingress controller أو office VPN).

trade-offs والافتراضات اللي لازم تعرفها

بدل ما أبيعهالك على إنها حل سحري، خد القايمة دي بصراحة:

• الـ CNI لازم يدعم NetworkPolicy. Flannel الافتراضي في كذا managed cluster مش بيدعمها. لازم Calico أو Cilium أو Antrea. لو طبقت policy على CNI ما بيدعمش، الـ kubectl هيقول "applied" والـ traffic هيعدّي عادي. ده الفخ الكبير اللي ناس كتير وقعت فيه.
• التكلفة على CPU وLatency. Calico في وضع iptables بيضيف 0.3 إلى 0.6 مللي ثانية لكل packet على cluster متوسط. Cilium بـ eBPF بيقلل ده لحوالي 0.05ms. الأرقام دي مقاسة في تقارير Tigera وIsovalent. مش رقم كبير في الغالب، لكنه موجود.
• Debugging صعب. لما طلب يفشل، الـ pod بيشوف "connection refused" أو timeout. مفيش log من Kubernetes يقولك السبب الـ policy. لازم تشغّل calicoctl أو cilium hubble observe علشان تشوف الحزمة اتمسكت في أنهي rule. خصّص يومين بحاله للأداة دي قبل ما تطلق على إنتاج.
• Stateful بطبيعتها. لو سمحت للـ frontend بـ ingress، الـ response من الـ backend هيعدّي تلقائياً عبر connection tracking. مش لازم تضيف egress rule مقابل. الافتراض ده بيوفّر سطور كتيرة، بس بيلخبط اللي جايين من firewall تقليدي.

الافتراض الكبير في كل اللي فات: عندك Kubernetes 1.21 أو أحدث، CNI من Calico 3.26+ أو Cilium 1.14+، وأقل من 5,000 pod في الـ cluster. لو خدمتك بتشتغل بـ 50K pod أو أكتر، ادرس Cilium ClusterMesh و identity-based policies بدل selectors عادية، لأن الـ scale بيكسر فرضيات الـ iptables.

متى لا تستخدم Network Policy

تلات حالات فعلية الـ NetworkPolicy فيها overkill:

• Cluster تطوير محلي لمطور وحيد. Minikube أو Kind، الـ policies بتزوّد debugging بدون فايدة أمنية حقيقية. اعمل setup للـ policies في staging بس.
• Cluster كل الـ pods فيه نفس الـ trust domain. مثلاً 3 services لنفس الفريق ومفيش tenant خارجي. مش هيغيّر كتير في الـ blast radius لأن الـ permissions كلها واحدة أصلاً.
• الأمن مفروض على layer أعلى. لو عندك Service Mesh زي Istio بـ mTLS و AuthorizationPolicies، الـ overlap مع NetworkPolicy ممكن يعقّد الـ debugging. اختار طبقة واحدة وتمسّك بيها.

برضه لو الـ cluster بياخد public ingress بأي شكل، فيه multi-tenant، أو بيخدم fintech أو healthcare، الـ NetworkPolicy مش optional. اعتبرها زي قفل الباب الخارجي.

الخطوة التالية

افتح cluster التطوير بتاعك دلوقتي، اعمل namespace جديدة اسمها policy-test، وطبّق kubectl apply على policy واحدة فاضية بتمنع ingress كلها. بعدين شغّل deployment فيها واتأكد إنك مش قادر توصله من namespace تانية. لو وصّلت للـ pod من غير ما تعمل allow rule، الـ CNI بتاعك مش بيدعم Network Policy، وده أول مشكلة لازم تحلها قبل أي شيء تاني. لو شفت "applied" لكن الـ traffic عدّى، اقفز فوراً على cilium status أو calicoctl get felixconfiguration وراجع الـ datapath.

المصادر

• NetworkPolicy specification الرسمي: kubernetes.io/docs/concepts/services-networking/network-policies.
• Verizon Data Breach Investigations Report 2024 — قسم Lateral Movement.
• CNCF Cloud Native Security Whitepaper v2 (2022) — توصيات zero-trust داخل الـ cluster.
• Tigera Calico Documentation — قسم Performance Benchmarks (2024).
• Isovalent Cilium eBPF Datapath Benchmarks — تقارير 2024.
• Kubernetes 1.29 Release Notes — تحسينات AdminNetworkPolicy API.