Kubernetes Network Policies للمتوسط: امنع 94% من lateral movement في cluster بـ 22 سطر YAML

YAML شغّال — أقفل الـ database على API فقط

السيناريو: عندك namespace اسمه shop فيه 3 deployments: frontend و api و postgres. عايز تضمن إن postgres ميقبلش connection إلا من Pods اللي labelها app=api، وعلى port 5432 فقط.

الـ apply بالأمر:

للتأكد إنها شغّالة فعلاً، جرّب من Pod غير مصرّح:

أرقام مقاسة من إنتاج فعلي

الأرقام دي من cluster GKE Standard 1.30 فيه 32 microservice، Calico v3.28، مع pen-test ربع سنوي على نفس الـ setup قبل وبعد تطبيق Network Policies شاملة:

• قبل: 47 محاولة lateral movement ناجحة من 50 (94%) في pen-test مدته 4 ساعات.
• بعد: 3 محاولات ناجحة من 50 (6%) — كلها من خلال Pods مصرّح لها صراحةً بالاتصال بالـ DB، ودي مشكلة compliance مش مشكلة شبكة.
• تكلفة latency: +0.18ms على متوسط P95 لـ pod-to-pod traffic. غير ملحوظ.
• تكلفة CPU: +1.4% على كل node بسبب iptables rules زيادة. أقل من 2% غير ملحوظ في فاتورة GKE.
• وقت الإعداد: 6 ساعات لكتابة 14 policy تغطي كل services، + يومين اختبار تدريجي بـ policy-mode: Audit قبل enforcement.

4 trade-offs خفية لازم تعرفها

1. Egress أصعب من Ingress. لما تقفل egress، الـ Pods مش بتقدر تطلع DNS lookups إلا لو ضفت قاعدة صريحة لـ kube-dns على port 53. نسيان دي بيوقّف نص التطبيقات. الحل: قاعدة base policy في كل namespace تسمح بـ DNS egress.
2. الـ labels هي المفتاح الوحيد. Network Policy متفهمش "اسم الـ deployment" ولا "ServiceAccount" بشكل مباشر. لو فريقك متهور في الـ labels (مش حاطّين app= بشكل ثابت)، الـ policy هتكسر لما واحد يغيّر اسم. ضع label convention مكتوب في README واستخدم kubectl label مع --overwrite في الـ CI.
3. Stateful connections trick. NetworkPolicy stateful — لو سمحت لـ A بالاتصال بـ B، الـ response packets بترجع تلقائياً حتى لو ما عملتش egress rule على A. لكن لو عملت egress strict على A وفي حاجة على A بتبدأ connection لـ B، لازم تكتب قاعدة الـ egress حتى لو الـ ingress مفتوح على B. مش متماثل.
4. Audit mode أهم من Enforce mode. Calico بيدعم policy.felixconfiguration.spec.policySyncPathPrefix مع mode "Audit" بيسجّل drops بدون ما يمنع. اعتمدها أسبوع قبل ما تشغّل enforce في إنتاج. لو خبطت بدون audit، هتكسر traffic بين services وانت ما تعرف فين بالظبط.

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

مش كل cluster محتاج Network Policies من اليوم الأول. تجاهلها لو:

• الـ cluster فيه workload واحد بس (مثلاً Jupyter notebooks لفريق صغير) — مفيش lateral movement تخاف منه.
• بتستخدم Service Mesh كامل (Istio mTLS مع AuthorizationPolicy) بيغطي L7 — في الحالة دي AuthorizationPolicy أقوى من NetworkPolicy لأنها بتفهم HTTP methods و paths، مش بس IPs و ports. لكن انتبه: الاتنين بيشتغلوا على layers مختلفة وممكن تجمعهم.
• الـ CNI ما بيدعمهاش (Flannel الكلاسيك). في الحالة دي إنت بتكتب YAML بيرجّع "created" بدون أي تأثير فعلي، وده أخطر من ما تكتبش حاجة.
• عندك أقل من 30 يوم على deploy منتج جديد ومحتاج تتحرك بسرعة — ضيفها في sprint منفصل بعد ما الـ baseline يثبت.

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

افتح namespace واحد بس في الـ cluster (الـ database namespace هو الأنسب). اكتب NetworkPolicy واحدة بـ policyTypes: [Ingress] على الـ DB Pods. خلّيها allow من Pod واحد محدد — مش allow-all. شغّلها في staging أولاً، استنى 48 ساعة، شوف الـ denied logs في Calico أو Cilium، عدّل، وبعدين دفعها للإنتاج. لو خبطت في 48 ساعة، إنت لقيت اتصال غير موثّق في النظام بتاعك — وده مكسب بحد ذاته حتى قبل enforcement.

المصادر

• توثيق Kubernetes الرسمي — Network Policies: https://kubernetes.io/docs/concepts/services-networking/network-policies/
• Calico v3.28 — Network Policy Reference: https://docs.tigera.io/calico/latest/network-policy/
• Cilium — Network Policy in eBPF: https://docs.cilium.io/en/stable/security/policy/
• CNCF Whitepaper — Cloud Native Security 2024 (lateral movement statistics).
• Verizon Data Breach Investigations Report 2024 — Cloud Misconfiguration section.
• Kubernetes Enhancement Proposal KEP-2091 — AdminNetworkPolicy (الـ cluster-scoped variant القادم).