فهم خيارات تنفيذ سياسة الشبكة مع كاليكو

يوفر البرنامج الإضافي لشبكة Calico نطاقًا واسعًا من سياسات الشبكة مع بناء جملة موحد لحماية الأجهزة المضيفة والأجهزة الافتراضية والقرون. يمكن تطبيق هذه السياسات ضمن مساحة اسم أو أن تكون سياسات شبكة عالمية تنطبق عليها نقطة نهاية المضيف (لحماية التطبيقات التي تعمل مباشرة على المضيف - يمكن أن يكون المضيف خادمًا أو جهازًا افتراضيًا) أو نقطة نهاية عبء العمل (لحماية التطبيقات التي تعمل في حاويات أو أجهزة افتراضية مستضافة). تسمح لك سياسات Calico بتطبيق إجراءات الأمان في نقاط مختلفة في مسار الحزمة باستخدام خيارات مثل preDNAT وunraracked وapplyOnForward. يمكن أن يساعد فهم كيفية عمل هذه الخيارات في تحسين أمان وأداء نظامك بشكل عام. تشرح هذه المقالة جوهر خيارات سياسة Calico هذه (preDNAT، وunraracked، وapplyOnForward) المطبقة على نقاط النهاية المضيفة، مع التركيز على ما يحدث في مسارات معالجة الحزم (سلاسل iptabels).

تفترض هذه المقالة أن لديك فهمًا أساسيًا لكيفية عمل سياسات شبكة Kubernetes وCalico. إذا لم يكن الأمر كذلك، نوصي بتجربته البرنامج التعليمي لسياسة الشبكة الأساسية и البرنامج التعليمي لحماية المضيف باستخدام كاليكو قبل قراءة هذا المقال. نتوقع أيضًا أن يكون لديك فهم أساسي للعمل يبتابليس في لينكس.

كاليكو سياسة الشبكة العالمية يسمح لك بتطبيق مجموعة من قواعد الوصول حسب التصنيفات (على مجموعات المضيفين وأعباء العمل/الوحدات). يعد هذا مفيدًا جدًا إذا كنت تستخدم أنظمة غير متجانسة معًا - أجهزة افتراضية، أو نظام متصل مباشرة بالأجهزة، أو بنية أساسية لـ kubernetes. بالإضافة إلى ذلك، يمكنك حماية مجموعتك (العقد) باستخدام مجموعة من السياسات التصريحية وتطبيق سياسات الشبكة على حركة المرور الواردة (على سبيل المثال، من خلال خدمة NodePorts أو عناوين IP الخارجية).

على المستوى الأساسي، عندما تقوم كاليكو بتوصيل جراب بالشبكة (انظر الرسم البياني أدناه)، فإنها تقوم بتوصيله بالمضيف باستخدام واجهة إيثرنت افتراضية (veth). تأتي حركة المرور المرسلة من الكبسولة إلى المضيف من هذه الواجهة الافتراضية وتتم معالجتها بنفس الطريقة كما لو كانت تأتي من واجهة شبكة فعلية. افتراضيًا، تقوم شركة Calico بتسمية هذه الواجهات بـ caliXXX. نظرًا لأن حركة المرور تأتي عبر الواجهة الافتراضية، فإنها تمر عبر iptables كما لو كانت الكبسولة على بعد خطوة واحدة. لذلك، عندما تأتي حركة المرور من/إلى الكبسولة، يتم إعادة توجيهها من وجهة نظر المضيف.

في عقدة Kubernetes التي تقوم بتشغيل Calico، يمكنك تعيين واجهة افتراضية (veth) لحجم العمل على النحو التالي. في المثال أدناه، يمكنك أن ترى أن veth#10 (calic1cbf1ca0f8) متصل بـ cnx-manager-* في مساحة اسم مراقبة calico.

[centos@ip-172-31-31-46 K8S]$ sudo ip a
...
10: calic1cbf1ca0f8@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:ff link-netnsid 5
    inet6 fe80::ecee:eeff:feee:eeee/64 scope link
       valid_lft forever preferred_lft forever
...

[centos@ip-172-31-31-46 K8S]$ calicoctl get wep --all-namespaces
...
calico-monitoring cnx-manager-8f778bd66-lz45m                            ip-172-31-31-46.ec2.internal 192.168.103.134/32
calic1cbf1ca0f8
...

بالنظر إلى أن كاليكو تقوم بإنشاء واجهة veth لكل عبء عمل، كيف يمكنها فرض السياسات؟ للقيام بذلك، تقوم كاليكو بإنشاء خطافات في سلاسل مختلفة من مسار معالجة الحزم باستخدام iptables.

يوضح الرسم البياني أدناه السلاسل المشاركة في معالجة الحزم في iptables (أو النظام الفرعي netfilter). عندما تصل الحزمة عبر واجهة الشبكة، فإنها تمر أولاً عبر سلسلة PREROUTING. يتم بعد ذلك اتخاذ قرار التوجيه، وبناءً على ذلك، تمر الحزمة إما عبر INPUT (الموجه إلى العمليات المضيفة) أو FORWARD (الموجه إلى حجرة أو عقدة أخرى على الشبكة). من العملية المحلية، تمر الحزمة عبر سلسلة OUTPUT ثم POSTROUTING قبل إرسالها عبر الكبل.

لاحظ أن البود هو أيضًا كيان خارجي (متصل بـ veth) من حيث معالجة iptables. دعونا نلخص:

• تمر حركة المرور المُعاد توجيهها (nat أو الموجهة أو من/إلى الكبسولة) عبر سلاسل PREROUTING - FORWARD - POSTROUTING.
• تمر حركة المرور إلى عملية المضيف المحلي عبر سلسلة PREROUTING - INPUT.
• تمر حركة المرور من عملية المضيف المحلي عبر سلسلة OUTPUT - POSTROUTING.

توفر كاليكو خيارات السياسة التي تسمح لك بتطبيق السياسات عبر جميع السلاسل. مع أخذ ذلك في الاعتبار، دعونا نلقي نظرة على خيارات تكوين السياسة المختلفة المتاحة في كاليكو. تتوافق الأرقام الموجودة في قائمة الخيارات أدناه مع الأرقام الموجودة في الرسم البياني أعلاه.

1. سياسة نقطة نهاية عبء العمل (جراب).
2. سياسة نقطة النهاية المضيفة
3. خيار ApplyOnForward
4. سياسة ما قبل DNAT
5. سياسة غير متعقبة

لنبدأ بالنظر في كيفية تطبيق السياسات على نقاط نهاية عبء العمل (Kubernetes pods أو OpenStack VMs)، ثم ننظر إلى خيارات السياسة لنقاط النهاية المضيفة.

نقاط نهاية عبء العمل

سياسة نقطة نهاية عبء العمل (1)

يعد هذا خيارًا لحماية كبسولات kubernetes الخاصة بك. تدعم Calico العمل مع Kubernetes NetworkPolicy، ولكنها توفر أيضًا سياسات إضافية - Calico NetworkPolicy وGlobalNetworkPolicy. تقوم كاليكو بإنشاء سلسلة لكل جراب (عبء عمل) وخطافات في سلاسل INPUT وOUTPUT لحمل العمل إلى جدول التصفية لسلسلة FORWARD.

نقاط نهاية المضيف

سياسة نقطة نهاية المضيف (2)

بالإضافة إلى CNI (واجهة شبكة الحاويات)، توفر سياسات Calico القدرة على حماية المضيف نفسه. في Calico، يمكنك إنشاء نقطة نهاية مضيفة عن طريق تحديد مجموعة من واجهة المضيف وأرقام المنافذ إذا لزم الأمر. يتم تنفيذ السياسة لهذا الكيان باستخدام جدول التصفية في سلاسل INPUT وOUTPUT. كما ترون من الرسم البياني، (2) تنطبق على العمليات المحلية على العقدة/المضيف. أي أنك إذا قمت بإنشاء سياسة تنطبق على نقطة النهاية المضيفة، فلن يؤثر ذلك على حركة المرور من/إلى حجراتك. ولكنه يوفر واجهة/بناء جملة واحد لمنع حركة المرور لمضيفك والبودات باستخدام سياسات Calico. وهذا يبسط إلى حد كبير عملية إدارة السياسات لشبكة غير متجانسة. يعد تكوين سياسات نقطة النهاية المضيفة لتعزيز أمان المجموعة حالة استخدام مهمة أخرى.

سياسة ApplyOnForward (3)

يتوفر خيار ApplyOnForward في سياسة شبكة Calico العالمية للسماح بتطبيق السياسات على كل حركة المرور التي تمر عبر نقطة نهاية المضيف، بما في ذلك حركة المرور التي سيتم إعادة توجيهها بواسطة المضيف. يتضمن ذلك حركة المرور التي يتم توجيهها إلى الكبسولة المحلية أو إلى أي مكان آخر على الشبكة. يتطلب Calico تمكين هذا الإعداد للسياسات التي تستخدم PreDNAT وعدم تعقبه، راجع الأقسام التالية. بالإضافة إلى ذلك، يمكن استخدام ApplyOnForward لمراقبة حركة مرور المضيف في الحالات التي يتم فيها استخدام جهاز توجيه افتراضي أو برنامج NAT.

لاحظ أنه إذا كنت بحاجة إلى تطبيق نفس سياسة الشبكة على كل من العمليات المضيفة والبودات، فلن تحتاج إلى استخدام خيار ApplyOnForward. كل ما عليك فعله هو إنشاء تسمية لنقطة المضيف المطلوبة ونقطة نهاية عبء العمل (الجراب). تتميز شركة Calico بالذكاء الكافي لفرض السياسة بناءً على التصنيفات، بغض النظر عن نوع نقطة النهاية (نقطة المضيف أو عبء العمل).

سياسة PreDNAT (4)

في Kubernetes، يمكن عرض منافذ كيان الخدمة خارجيًا باستخدام خيار NodePorts أو، اختياريًا (عند استخدام Calico)، عن طريق الإعلان عنها باستخدام خيارات عناوين IP العنقودية أو عناوين IP الخارجية. يقوم Kube-proxy بموازنة حركة المرور الواردة المرتبطة بالخدمة مع كبسولات الخدمة المقابلة باستخدام DNAT. بالنظر إلى ذلك، كيف يمكنك فرض سياسات حركة المرور القادمة عبر NodePorts؟ لضمان تطبيق هذه السياسات قبل معالجة حركة المرور بواسطة DNAT (وهو تعيين بين المنفذ المضيف والخدمة المقابلة)، توفر Calico معلمة لـ globalNetworkPolicy تسمى "preDNAT: true".

عند تمكين pre-DNAT، يتم تنفيذ هذه السياسات في (4) في الرسم التخطيطي - في جدول mangle لسلسلة PREROUTING - مباشرة قبل DNAT. ولا يتم اتباع الترتيب المعتاد للسياسات هنا، نظرًا لأن تطبيق هذه السياسات يحدث في وقت مبكر جدًا في مسار معالجة حركة المرور. ومع ذلك، فإن سياسات preDNAT تحترم ترتيب التطبيق فيما بينها.

عند إنشاء سياسات باستخدام ما قبل DNAT، من المهم توخي الحذر بشأن حركة المرور التي تريد معالجتها والسماح برفض الأغلبية. لن يتم فحص حركة المرور التي تم وضع علامة "السماح بها" في سياسة ما قبل DNAT بعد الآن بواسطة سياسة نقطة المضيف، بينما ستستمر حركة المرور التي تفشل في سياسة ما قبل DNAT عبر السلاسل المتبقية.
لقد جعلت كاليكو تمكين خيار ApplyOnForward إلزاميًا عند استخدام preDNAT، نظرًا لأنه بحكم التعريف لم يتم تحديد وجهة حركة المرور بعد. يمكن توجيه حركة المرور إلى العملية المضيفة، أو يمكن إعادة توجيهها إلى حجرة أو عقدة أخرى.

السياسة غير المتعقبة (5)

يمكن أن يكون للشبكات والتطبيقات اختلافات كبيرة في السلوك. في بعض الحالات القصوى، قد تقوم التطبيقات بإنشاء العديد من الاتصالات قصيرة العمر. يمكن أن يتسبب هذا في نفاد ذاكرة conntrack (مكون أساسي في مكدس شبكة Linux). تقليديًا، لتشغيل هذه الأنواع من التطبيقات على Linux، سيتعين عليك تكوين conntrack أو تعطيله يدويًا، أو كتابة قواعد iptables لتجاوز conntrack. تعد السياسة غير المتعقبة في Calico خيارًا أبسط وأكثر كفاءة إذا كنت تريد معالجة الاتصالات في أسرع وقت ممكن. على سبيل المثال، إذا كنت تستخدم ضخمة memcache أو كإجراء إضافي للحماية ضد DDOS.

اقرا هذا بلوق وظيفة (أو الترجمة لدينا) لمزيد من المعلومات، بما في ذلك اختبارات الأداء باستخدام النهج غير المتتبع.

عندما تقوم بتعيين خيار "doNotTrack: true" في Calico globalNetworkPolicy، فإنه يصبح سياسة **غير متتبعة** ويتم تطبيقه مبكرًا جدًا في مسار معالجة حزم Linux. بالنظر إلى الرسم البياني أعلاه، يتم تطبيق السياسات غير المتعقبة في سلاسل PREROUTING وOUTPUT في الجدول الأولي قبل بدء تشغيل تتبع الاتصال (conntrack). عندما تسمح السياسة غير المتعقبة بحزمة ما، يتم وضع علامة عليها لتعطيل تتبع الاتصال لتلك الحزمة. هذا يعني:

• يتم تطبيق السياسة التي لم يتم تعقبها على أساس كل حزمة. لا يوجد مفهوم الاتصال (أو التدفق). يؤدي عدم وجود اتصالات إلى عدة عواقب مهمة:
• إذا كنت تريد السماح بحركة مرور الطلب والاستجابة، فأنت بحاجة إلى قاعدة لكل من حركة المرور الواردة والصادرة (نظرًا لأن Calico تستخدم عادةً conntrack لوضع علامة على حركة الاستجابة على أنها مسموح بها).
• لا تعمل السياسة غير المتعقبة مع أحمال عمل Kubernetes (pods)، لأنه في هذه الحالة لا توجد طريقة لتتبع الاتصال الصادر من pod.
• لا يعمل NAT بشكل صحيح مع الحزم التي لم يتم تعقبها (نظرًا لأن النواة تقوم بتخزين تعيين NAT في conntrack).
• عند المرور عبر قاعدة "السماح للكل" في السياسة غير المتعقبة، سيتم وضع علامة على جميع الحزم على أنها غير متعقبة. هذا ليس ما تريده دائمًا تقريبًا، لذا من المهم أن تكون انتقائيًا للغاية بشأن الحزم التي تسمح بها السياسات غير المتعقبة (والسماح لمعظم حركة المرور بالمرور عبر السياسات المتعقبة العادية).
• يتم تطبيق السياسات التي لم يتم تعقبها في بداية مسار معالجة الحزم. من المهم جدًا فهم ذلك عند إنشاء سياسات كاليكو. يمكن أن يكون لديك سياسة جراب مع الطلب:1 وسياسة غير متعقبة مع الطلب:1000. لن يهم. سيتم تطبيق سياسة Untracked قبل سياسة الكبسولة. السياسات التي لم يتم تتبعها تحترم أمر التنفيذ فيما بينها فقط.

نظرًا لأن أحد أغراض سياسة doNotTrack هو فرض السياسة مبكرًا جدًا في مسار معالجة حزم Linux، فإن Calico تجعل من الضروري تحديد خيار ApplyOnForward عند استخدام doNotTrack. بالإشارة إلى مخطط معالجة الحزم، لاحظ أنه يتم تطبيق سياسة untracked(5) قبل أي قرارات توجيه. يمكن توجيه حركة المرور إلى العملية المضيفة، أو يمكن إعادة توجيهها إلى حجرة أو عقدة أخرى.

نتائج

لقد نظرنا في خيارات السياسة المختلفة (نقطة نهاية المضيف، ApplyOnForward، preDNAT، وUntracked) في Calico وكيفية تطبيقها على طول مسار معالجة الحزمة. إن فهم كيفية عملهم يساعد في تطوير سياسات فعالة وآمنة. مع Calico، يمكنك استخدام سياسة الشبكة العالمية التي تنطبق على تسمية (مجموعة من العقد والكبسولات) وتطبيق السياسات بمعلمات مختلفة. يتيح ذلك لمحترفي الأمن وتصميم الشبكات حماية "كل شيء" (أنواع نقاط النهاية) بشكل ملائم في وقت واحد باستخدام لغة سياسة واحدة مع سياسات Calico.

شكر وتقدير: أود أن أشكر شون كرامبتون и اليكسا بوليتا لمراجعتهم والمعلومات القيمة.

المصدر: www.habr.com