NetworkPolicy في Kubernetes ليست حكماً على تدفق شبكة

الخلاصة

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

قد تجعل عبارة «الرفض الافتراضي» ملف YAML يبدو كأنه نتيجة أمنية اكتملت. ليس كذلك. قيمة NetworkPolicy أنها سطح تحكم تصريحي: تعزل Pods مختارة للدخول أو الخروج أو كليهما وتصف الاتصالات التي ينبغي أن تبقى ممكنة. هذا قرار عن حد شبكي مطلوب. وليس دليلاً على أن اتصالاً معيناً رُفض، أو أن اتصالاً مسموحاً تأسس، أو أن عبء عمل صار آمناً.

يرسم نموذج المورد الحد الأول. فـ NetworkPolicySpec يمثل السلوك المرغوب. تختار السياسة Pods، وتحدد عزل Ingress أو Egress، وتورد القواعد. النتائج ليست سلسلة رفضات تتغلب الواحدة على الأخرى؛ بل هي تراكمية. عندما يعزل Pod في اتجاه، تكون الاتصالات المسموحة اتحاد ما تسمح به جميع السياسات المطبقة. ولكي يصل Pod مصدر إلى Pod وجهة، يجب أن يسمح خروج المصدر ودخول الوجهة معاً. هذه قاعدة لفهم مجموعة سياسات، لا سجل للعنوان المرصود أو المنفذ أو البروتوكول أو الوقت أو العملية أو مسار الرزمة أو نتيجة الاتصال.

حالة المحددات حقيقة مستقلة أيضاً. podSelector أو namespaceSelector أو ipBlock ليست قائمة دائمة من نهايات ملموسة. تتبدل labels، وتستبدل Pods، وقد يغير توجيه Service المسار. وتحذر Kubernetes كذلك من أن آليات الدخول والخروج قد تعيد كتابة العناوين. عندئذ لا يُعرّف هل تقع إعادة الكتابة قبل معالجة NetworkPolicy أم بعدها، وقد يختلف السلوك باختلاف plugin الشبكة أو مزود السحابة أو تنفيذ Service أو تركيبها. يستطيع manifest وصف النطاق المقصود لكنه لا يحكم كيف مثلت رزمة مرصودة عند نقطة التطبيق.

طبقة التنفيذ سطح دليل آخر. توضح Kubernetes أن plugin الشبكة هي التي تنفذ NetworkPolicy. إنشاء المورد بلا متحكم ينفذها لا يحدث أثراً رغم بقاء API موجودة. هذا ليس اتهاماً لمنتج أو مدير؛ بل تضييق لما يثبته كائن قبله خادم API. فهو يثبت قبول control plane، ولا يثبت قدرة مكوّن data plane أو تهيئته أو صحته أو فعاليته في ذلك الوقت.

والزمن يضيق النتيجة أكثر. تقول Kubernetes إن كل NetworkPolicy منشأة ستعالج في النهاية، لكن لا وسيلة في API لمعرفة اللحظة الدقيقة. كما تصف مناظر قد تكون غير متسقة قليلاً أثناء تغير Pods أو السياسات. وإذا تغيرت مجموعة السياسات المؤثرة في اتصال قائم، فتأثير التغير محدد بالتنفيذ. ليست هذه ثغرات لغوية، بل أسباب لعدم مطالبة لقطة إعداد بسرد تنفيذ لا تحتفظ به.

لنطاق البروتوكول حد مستقل. NetworkPolicy معرفة لاتصالات TCP وUDP وSCTP الاختيارية في الطبقة الرابعة. أما بروتوكولات أخرى فقد يختلف سلوكها بين plugins. لذلك لا يجوز تحويل حد ظاهر إلى ادعاء شامل عن كل رزمة أو مسار hostNetwork أو service mesh أو التشفير أو هوية عبء العمل أو المصادقة أو DNS أو تفويض التطبيق أو التسليم. كل واحد منها سطح تحكم يحتاج دليله الخاص.

يقترح Daniel Kade إيصال تدفق من خمسة أجزاء للحالات المهمة. الأول مراجعة السياسة: namespace، هوية الكائن، generation أو لقطة ثابتة، المحدد، الاتجاه، القواعد ووقت المشاهدة. الثاني حالة المحددات والنهايات: labels الخاصة بـ Pod وNamespace، وربط IP أو endpoint ولحظة القراءة. الثالث تنفيذ الشبكة: قدرة NetworkPolicy المعلنة، الإصدار، الإعداد ذو الصلة ودليل الصحة. الرابع ملاحظة اتصال محصورة زمنياً مع المصدر والوجهة كما شوهدتا، والبروتوكول والمنفذ والاتجاه والنتيجة والجامع وحدود الرؤية. الخامس سجل مستقل لهوية عبء العمل أو التفويض أو TLS أو DNS أو استجابة التطبيق أو النشر. يمكن حماية التفاصيل الحساسة من دون دمج السجلات.

تصف هذه الطريقة النتائج العادية أيضاً. قد تكون السياسة سليمة فيما يمنع عطل مستقل الاتصال. وقد يفشل تدفق مسموح في الاتجاهين في DNS أو TLS أو المصادقة أو التطبيق. وقد تقبل API السياسة قبل أن يجعلها plugin بعينه نافذة. لا يثبت أي من ذلك عيباً أو حادثاً. إنه يبين فقط لماذا لا ينبغي أن يحمل manifest واحد تاريخ تدفق كامل.

المصادر

1. Kubernetes — Network Policies
2. Kubernetes — Services, Load Balancing, and Networking
3. مرجع Kubernetes API — NetworkPolicy v1