هذا المقال للمستوى المتوسط — يفترض إنك مرتاح مع kubectl والـ YAML الأساسي وعندك cluster Kubernetes شغّال فعلاً، وعارف الفرق بين namespace و pod و service.
Network Policies في Kubernetes: ابنِ Zero-Trust بين microservices في 30 سطر YAML
لو الـ cluster عندك فيه 18 microservice وبتفترض إن الـ Ingress أو الـ firewall الخارجي كفاية يحميك من أي اختراق، إنت بتتجاهل أكبر فجوة أمنية في Kubernetes الافتراضي. أي pod جوّا الـ cluster يقدر يفتح اتصال TCP/UDP مع أي pod تاني على أي port. attacker بيخترق container واحد بيوصل لقواعد البيانات وكل الـ services الداخلية في 3 دقائق، بدون أي مقاومة. الحل اسمه Network Policies، و30 سطر YAML بيقفلوا اللعبة دي.
المشكلة باختصار
الـ networking model في Kubernetes الافتراضي مبني على الـ flat network. كل pod ياخد IP خاص بيه داخل الـ cluster، وبيقدر يفتح اتصال مع أي pod تاني في أي namespace بدون قيد. ده يعني إن pod الـ frontend يقدر يكلم قاعدة بيانات الـ HR مباشرة، حتى لو ما لهوش علاقة شغل بيها.
الـ Ingress (زي NGINX Ingress أو ALB) بيحميك من خارج الـ cluster، بس داخله مفيش حماية. لو attacker لقى ثغرة في endpoint عام (SSRF، RCE، أو حتى dependency vulnerable)، الـ blast radius بيمتد لكل service. حسب تقرير Verizon DBIR 2024، 32% من اختراقات الإنتاج بتبدأ من container واحد ثم بتنتشر lateral داخل الشبكة الداخلية.
مثال للمبتدئ — البوّاب اللي بدون قائمة زيارات
تخيّل عمارة فيها 18 شقة، وبوّاب موجود ساعة دخول العمارة. البوّاب بيتأكد إن اللي داخل من برّا له اسم في القائمة. لكن جوّا العمارة، أي ساكن يقدر يطرق على باب أي شقة تانية وقت ما يحب، ويدخل لو الباب مفتوح. لو واحد دخل العمارة بطريقة ملتوية مرة واحدة (مثلاً قال إنه عامل صيانة)، بقى بحرية تامة يفتح أي شقة. المشكلة مش إن البوّاب فاشل، المشكلة إن مفيش قائمة زيارات داخلية.
Network Policies هي قائمة الزيارات الداخلية. البوّاب بيتحوّل لمسؤول عن تصاريح الزيارة بين الشقق نفسها. شقة 12 (اللي هي الـ orders service) مسموحلها بس تكلم شقة 4 (الـ database) و شقة 7 (الـ payment service)، وأي محاولة طرق على باب تاني بترفض على مستوى البوّاب، قبل ما توصل للباب أصلاً.
التعريف العلمي الدقيق
Network Policy في Kubernetes هو object من نوع networking.k8s.io/v1 بيعرّف قواعد الـ ingress (الترافيك الداخل لمجموعة pods) والـ egress (الترافيك الخارج منها). الـ podSelector بيحدد الـ pods اللي القاعدة بتنطبق عليهم، والـ rules بتحدد المصادر/الوجهات المسموحة عبر podSelector أو namespaceSelector أو ipBlock.
بالظبط، الـ Network Policies نفسها مجرد definitions في الـ API. اللي بينفّذها فعلاً على الـ kernel هو الـ CNI (Container Network Interface) plugin. لو الـ cluster بتاعك شغّال على CNI ما بيدعمش Network Policies (زي Flannel الافتراضي)، الـ YAML اللي بتطبّقه بيتقبل بدون خطأ، لكن مش بيعمل أي حاجة فعلية. الـ CNI plugins اللي بتدعم Network Policies فعلاً: Calico، Cilium، Weave Net، و Antrea.
