🍋 🤦🏿 🕴🏼 فهم سياسات الشبكة مع كاليكو 👆 👩🏼‍⚕️ 🕴🏾

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

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

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

على المستوى الأساسي ، عندما يقوم Calico بتوصيل جراب شبكة (انظر الرسم البياني أدناه) ، فإنه يربطه بمضيف باستخدام واجهة Ethernet (veth) افتراضية. تصل حركة المرور المرسلة بواسطة pod إلى المضيف من هذه الواجهة الافتراضية وتتم معالجتها كما لو كانت من واجهة شبكة فعلية. بشكل افتراضي ، يستدعي كاليكو هذه الواجهات 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
...

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

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

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

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

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

سياسة نقطة نهاية عبء العمل (pod)
سياسة نقطة نهاية المضيف
تطبيق ApplyOnForward
سياسة PreDNAT
سياسة غير متعقبة

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

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

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

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

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

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

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

تطبيق سياسة الأمام (3)

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

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

سياسة PreDNAT (4)

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

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

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

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

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

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

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

يتم تطبيق سياسة غير متعقبة لكل حزمة. لا يوجد مفهوم اتصال (أو دفق). ينطوي نقص الاتصالات على عواقب مهمة عديدة:
, , , ( Calico conntrack, ).
untracked workload Kubernetes (pod’), pod’.
NAT ( NAT conntrack).
« » untracked- . , , untracked- ( ).
يتم تطبيق السياسات غير المتعقبة في بداية خط أنابيب معالجة الحزم. هذا أمر مهم للغاية لفهم عند إنشاء سياسات كاليكو. يمكنك الحصول على سياسة لجراب مع الطلب: 1 وسياسة غير متعقبة مع الطلب: 1000. لن تكون هامة. سيتم تطبيق السياسة غير المسعرة قبل سياسة الحصة. تحترم السياسات غير المتعقبة أمر التنفيذ فيما بينها فقط.

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

ملخص

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

شكر وتقدير: أود أن أشكر Sean Crampton و Alex Pollitt على مراجعتهما وعلى المعلومات القيمة.

فهم سياسات الشبكة مع كاليكو