کیلیکو کے ساتھ نیٹ ورک پالیسی کے نفاذ کے اختیارات کو سمجھنا

کیلیکو نیٹ ورک پلگ ان ہارڈ ویئر ہوسٹس، ورچوئل مشینوں اور پوڈز کی حفاظت کے لیے متحد نحو کے ساتھ نیٹ ورک کی پالیسیوں کی ایک وسیع رینج فراہم کرتا ہے۔ یہ پالیسیاں نام کی جگہ کے اندر لاگو کی جا سکتی ہیں یا عالمی نیٹ ورک کی پالیسیاں ہو سکتی ہیں جن پر لاگو ہوتا ہے۔ میزبان اختتامی نقطہ (میزبان پر براہ راست چلنے والی ایپلیکیشنز کی حفاظت کے لیے - میزبان سرور یا ورچوئل مشین ہو سکتا ہے) یا کام کا بوجھ اختتامی نقطہ (کنٹینرز یا میزبان ورچوئل مشینوں میں چلنے والی ایپلیکیشنز کی حفاظت کے لیے)۔ Calico کی پالیسیاں آپ کو preDNAT، unracked، اور applyOnForward جیسے اختیارات کا استعمال کرتے ہوئے پیکٹ کے راستے میں مختلف مقامات پر حفاظتی اقدامات کو لاگو کرنے کی اجازت دیتی ہیں۔ یہ سمجھنا کہ یہ اختیارات کیسے کام کرتے ہیں آپ کے مجموعی نظام کی حفاظت اور کارکردگی کو بہتر بنانے میں مدد کر سکتے ہیں۔ یہ مضمون ان Calico پالیسی آپشنز (preDNAT، unracked اور applyOnForward) کے جوہر کی وضاحت کرتا ہے جو میزبان اینڈ پوائنٹس پر لاگو ہوتے ہیں، اس بات پر زور دیتے ہوئے کہ پیکٹ پروسیسنگ پاتھ (iptabels chains) میں کیا ہوتا ہے۔

یہ مضمون فرض کرتا ہے کہ آپ کو اس بات کی بنیادی سمجھ ہے کہ Kubernetes اور Calico نیٹ ورک کی پالیسیاں کیسے کام کرتی ہیں۔ اگر نہیں، تو ہم اسے آزمانے کی تجویز کرتے ہیں۔ بنیادی نیٹ ورک پالیسی ٹیوٹوریل и میزبان تحفظ ٹیوٹوریل اس مضمون کو پڑھنے سے پہلے کیلیکو کا استعمال کریں۔ ہم آپ سے یہ بھی توقع کرتے ہیں کہ آپ کام کی بنیادی سمجھ رکھتے ہیں۔ iptables لینکس میں

کیلیکو۔ عالمی نیٹ ورک کی پالیسی آپ کو لیبلز کے ذریعے رسائی کے قوانین کا ایک سیٹ لاگو کرنے کی اجازت دیتا ہے (میزبانوں کے گروپوں اور کام کے بوجھ/پڈز پر)۔ یہ بہت مفید ہے اگر آپ متضاد نظاموں کو ایک ساتھ استعمال کرتے ہیں - ورچوئل مشینیں، براہ راست ہارڈ ویئر پر ایک سسٹم، یا کبرنیٹس انفراسٹرکچر۔ اس کے علاوہ، آپ اعلاناتی پالیسیوں کے سیٹ کا استعمال کرتے ہوئے اپنے کلسٹر (نوڈس) کی حفاظت کر سکتے ہیں اور آنے والی ٹریفک پر نیٹ ورک کی پالیسیاں لاگو کر سکتے ہیں (مثال کے طور پر، NodePorts یا External IPs سروس کے ذریعے)۔

بنیادی سطح پر، جب کیلیکو ایک پوڈ کو نیٹ ورک سے جوڑتا ہے (نیچے خاکہ دیکھیں)، یہ ورچوئل ایتھرنیٹ انٹرفیس (ویتھ) کا استعمال کرتے ہوئے اسے میزبان سے جوڑتا ہے۔ پوڈ کے ذریعے بھیجی جانے والی ٹریفک اس ورچوئل انٹرفیس سے میزبان کے پاس آتی ہے اور اس پر اسی طرح کارروائی ہوتی ہے جیسے یہ کسی فزیکل نیٹ ورک انٹرفیس سے آئی ہو۔ پہلے سے طے شدہ طور پر، کیلیکو ان انٹرفیسز کو caliXXX کا نام دیتا ہے۔ چونکہ ٹریفک ورچوئل انٹرفیس کے ذریعے آتی ہے، اس لیے یہ iptables سے اس طرح گزرتی ہے جیسے پوڈ ایک ہاپ کے فاصلے پر ہو۔ لہذا، جب ٹریفک کسی پوڈ پر/سے آتا ہے، تو اسے میزبان کے نقطہ نظر سے آگے بڑھایا جاتا ہے۔

کیلیکو چلانے والے Kubernetes نوڈ پر، آپ مندرجہ ذیل کام کے بوجھ سے ورچوئل انٹرفیس (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 ہر کام کے بوجھ کے لیے ایک ویتھ انٹرفیس بناتا ہے، یہ پالیسیوں کو کیسے نافذ کرتا ہے؟ ایسا کرنے کے لیے، کیلیکو iptables کا استعمال کرتے ہوئے پیکٹ پروسیسنگ پاتھ کی مختلف زنجیروں میں ہکس بناتا ہے۔

نیچے دیا گیا خاکہ iptables (یا نیٹ فلٹر سب سسٹم) میں پیکٹ پروسیسنگ میں شامل زنجیروں کو دکھاتا ہے۔ جب ایک پیکٹ نیٹ ورک انٹرفیس کے ذریعے آتا ہے، تو یہ سب سے پہلے PREROUTING چین سے گزرتا ہے۔ اس کے بعد روٹنگ کا فیصلہ کیا جاتا ہے، اور اس کی بنیاد پر، پیکٹ یا تو INPUT (پروسیس کی میزبانی کے لیے ہدایت) یا FORWARD (نیٹ ورک پر کسی پوڈ یا کسی اور نوڈ کی طرف ہدایت) سے گزرتا ہے۔ مقامی عمل سے، پیکٹ کیبل بھیجے جانے سے پہلے OUTPUT اور پھر POSTROUTING چین سے گزرتا ہے۔

نوٹ کریں کہ پوڈ iptables پروسیسنگ کے لحاظ سے ایک بیرونی ادارہ (veth سے منسلک) بھی ہے۔ آئیے خلاصہ کرتے ہیں:

• فارورڈ ٹریفک (نیٹ، روٹ یا پوڈ سے) PREROUTING - FORWARD - POSTROUTING زنجیروں سے گزرتی ہے۔
• مقامی میزبان عمل کی ٹریفک PREROUTING - INPUT چین سے گزرتی ہے۔
• مقامی میزبان عمل سے آنے والی ٹریفک OUTPUT - POSTROUTING سلسلہ سے گزرتی ہے۔

Calico پالیسی کے اختیارات فراہم کرتا ہے جو آپ کو تمام زنجیروں پر پالیسیاں لاگو کرنے کی اجازت دیتا ہے۔ اس کو ذہن میں رکھتے ہوئے، آئیے کیلیکو میں دستیاب مختلف پالیسی کنفیگریشن آپشنز کو دیکھتے ہیں۔ نیچے دیے گئے اختیارات کی فہرست میں موجود نمبر اوپر دیے گئے خاکے میں موجود نمبروں کے مساوی ہیں۔

1. ورک لوڈ اینڈ پوائنٹ (پوڈ) پالیسی
2. میزبان اختتامی نقطہ پالیسی
3. اپلائی آن فارورڈ آپشن
4. PreDNAT پالیسی
5. غیر ٹریک شدہ پالیسی

آئیے یہ دیکھ کر شروع کریں کہ پالیسیاں کام کے بوجھ کے اختتامی پوائنٹس (Kubernetes pods یا OpenStack VMs) پر کیسے لاگو ہوتی ہیں، اور پھر میزبان اختتامی پوائنٹس کے لیے پالیسی کے اختیارات کو دیکھیں۔

ورک لوڈ اینڈ پوائنٹس

ورک لوڈ اینڈ پوائنٹ پالیسی (1)

یہ آپ کے kubernetes pods کی حفاظت کے لیے ایک آپشن ہے۔ Calico Kubernetes NetworkPolicy کے ساتھ کام کرنے کی حمایت کرتا ہے، لیکن یہ اضافی پالیسیاں بھی فراہم کرتا ہے - Calico NetworkPolicy اور GlobalNetworkPolicy۔ Calico ہر پوڈ (کام کے بوجھ) کے لیے ایک زنجیر بناتا ہے اور FORWARD چین کے فلٹر ٹیبل پر کام کے بوجھ کے لیے INPUT اور OUTPUT زنجیروں میں ہکس لگاتا ہے۔

میزبان اختتامی پوائنٹس

میزبان اختتامی نقطہ پالیسی (2)

CNI (کنٹینر نیٹ ورک انٹرفیس) کے علاوہ، Calico پالیسیاں میزبان کو خود کی حفاظت کرنے کی صلاحیت فراہم کرتی ہیں۔ کیلیکو میں، آپ میزبان انٹرفیس کے امتزاج اور اگر ضروری ہو تو، پورٹ نمبر بتا کر ایک میزبان اختتامی نقطہ بنا سکتے ہیں۔ اس ادارے کے لیے پالیسی کا نفاذ INPUT اور OUTPUT چینز میں فلٹر ٹیبل کا استعمال کرتے ہوئے حاصل کیا جاتا ہے۔ جیسا کہ آپ آریھ سے دیکھ سکتے ہیں، (2) وہ نوڈ/میزبان پر مقامی عمل پر لاگو ہوتے ہیں۔ یعنی، اگر آپ ایک ایسی پالیسی بناتے ہیں جو میزبان کے اختتامی نقطہ پر لاگو ہوتی ہے، تو یہ آپ کے پوڈز کی طرف جانے والی ٹریفک کو متاثر نہیں کرے گی۔ لیکن یہ کیلیکو پالیسیوں کا استعمال کرتے ہوئے آپ کے میزبان اور پوڈز کے لیے ٹریفک کو روکنے کے لیے ایک ہی انٹرفیس/نحو فراہم کرتا ہے۔ یہ ایک متضاد نیٹ ورک کے لیے پالیسیوں کے انتظام کے عمل کو بہت آسان بناتا ہے۔ کلسٹر سیکورٹی کو بڑھانے کے لیے میزبان اینڈ پوائنٹ کی پالیسیاں ترتیب دینا ایک اور اہم استعمال کا معاملہ ہے۔

اپلائی آن فارورڈ پالیسی (3)

ApplyOnForward آپشن Calico گلوبل نیٹ ورک پالیسی میں دستیاب ہے تاکہ پالیسیوں کو میزبان اینڈ پوائنٹ سے گزرنے والی تمام ٹریفک پر لاگو کرنے کی اجازت دی جائے، بشمول وہ ٹریفک جو میزبان کی طرف سے آگے بھیجی جائے گی۔ اس میں مقامی پوڈ یا نیٹ ورک پر کہیں اور بھیجی جانے والی ٹریفک شامل ہے۔ Calico کو PreDNAT استعمال کرنے والی پالیسیوں کے لیے اس ترتیب کو فعال کرنے اور ٹریک نہ کیے جانے کی ضرورت ہے، درج ذیل حصے دیکھیں۔ اس کے علاوہ، ApplyOnForward کو ان صورتوں میں میزبان ٹریفک کی نگرانی کے لیے استعمال کیا جا سکتا ہے جہاں ایک ورچوئل راؤٹر یا سافٹ ویئر NAT استعمال کیا گیا ہو۔

نوٹ کریں کہ اگر آپ کو ایک ہی نیٹ ورک کی پالیسی کو میزبان عمل اور پوڈ دونوں پر لاگو کرنے کی ضرورت ہے، تو آپ کو ApplyOnForward آپشن استعمال کرنے کی ضرورت نہیں ہے۔ آپ کو بس مطلوبہ ہوسٹنڈ پوائنٹ اور ورک لوڈ اینڈ پوائنٹ (پوڈ) کے لیے ایک لیبل بنانا ہے۔ Calico لیبلز پر مبنی پالیسی کو نافذ کرنے کے لیے کافی ہوشیار ہے، قطع نظر اس کے اینڈ پوائنٹ کی قسم (ہوسٹنڈ پوائنٹ یا کام کا بوجھ)۔

PreDNAT پالیسی (4)

Kubernetes میں، سروس ہستی کی بندرگاہوں کو NodePorts آپشن کا استعمال کرتے ہوئے یا اختیاری طور پر (Calico استعمال کرتے وقت) کلسٹر IPs یا External IPs آپشنز کا استعمال کرتے ہوئے ان کی تشہیر کر کے ظاہر کیا جا سکتا ہے۔ Kube-proxy DNAT کا استعمال کرتے ہوئے متعلقہ سروس کے پوڈز کے لیے سروس سے منسلک آنے والی ٹریفک کو بیلنس کرتا ہے۔ اس کو دیکھتے ہوئے، آپ نوڈ پورٹس کے ذریعے آنے والی ٹریفک کے لیے پالیسیوں کو کیسے نافذ کرتے ہیں؟ اس بات کو یقینی بنانے کے لیے کہ یہ پالیسیاں DNAT (جو کہ host:port اور متعلقہ سروس کے درمیان ایک میپنگ ہے) کے ذریعے ٹریفک پر کارروائی سے پہلے لاگو ہوتی ہیں، Calico گلوبل نیٹ ورک پالیسی کے لیے ایک پیرامیٹر فراہم کرتا ہے جسے "preDNAT: true" کہا جاتا ہے۔

جب پری ڈی این اے ٹی کو فعال کیا جاتا ہے، تو یہ پالیسیاں (4) ڈایاگرام میں - PREROUTING چین کے مینگل ٹیبل میں - DNAT سے فوراً پہلے لاگو ہوتی ہیں۔ یہاں پالیسیوں کے معمول کی ترتیب کی پیروی نہیں کی جاتی ہے، کیونکہ ان پالیسیوں کا اطلاق ٹریفک پراسیسنگ کے راستے میں بہت پہلے ہوتا ہے۔ تاہم، preDNAT پالیسیاں آپس میں درخواست کی ترتیب کا احترام کرتی ہیں۔

پری DNAT کے ساتھ پالیسیاں بناتے وقت، اس ٹریفک کے بارے میں محتاط رہنا ضروری ہے جس پر آپ کارروائی کرنا چاہتے ہیں اور اکثریت کو مسترد کرنے کی اجازت دیتے ہیں۔ پری DNAT پالیسی میں 'اجازت دیں' کے بطور نشان زد ٹریفک کو ہوسٹنڈ پوائنٹ پالیسی کے ذریعے مزید چیک نہیں کیا جائے گا، جبکہ DNAT سے پہلے کی پالیسی میں ناکام ہونے والی ٹریفک باقی زنجیروں کے ذریعے جاری رہے گی۔
Calico نے preDNAT استعمال کرتے وقت ApplyOnForward آپشن کو فعال کرنا لازمی قرار دیا ہے، کیونکہ تعریف کے مطابق ٹریفک کی منزل ابھی تک منتخب نہیں کی گئی ہے۔ ٹریفک کو میزبان کے عمل کی طرف بھیجا جا سکتا ہے، یا اسے پوڈ یا کسی اور نوڈ پر بھیجا جا سکتا ہے۔

غیر ٹریک شدہ پالیسی (5)

نیٹ ورکس اور ایپلیکیشنز کے رویے میں بڑے فرق ہو سکتے ہیں۔ کچھ انتہائی صورتوں میں، ایپلیکیشنز بہت سے قلیل المدتی کنکشن پیدا کر سکتی ہیں۔ یہ conntrack (لینکس نیٹ ورکنگ اسٹیک کا ایک بنیادی جزو) میموری ختم ہونے کا سبب بن سکتا ہے۔ روایتی طور پر، لینکس پر اس قسم کی ایپلی کیشنز کو چلانے کے لیے، آپ کو کنٹراک کو دستی طور پر کنفیگر یا غیر فعال کرنا ہوگا، یا کانٹراک کو نظرانداز کرنے کے لیے iptables کے قواعد لکھنا ہوں گے۔ اگر آپ کنکشنز کو جلد از جلد پروسیس کرنا چاہتے ہیں تو کیلیکو میں غیر ٹریک شدہ پالیسی ایک آسان اور زیادہ موثر آپشن ہے۔ مثال کے طور پر، اگر آپ بڑے پیمانے پر استعمال کرتے ہیں memcache یا کے خلاف تحفظ کے اضافی اقدام کے طور پر DDOS.

اسے پڑھو بلاگ پوسٹ (یا ہمارا ترجمہ) مزید معلومات کے لیے، بشمول غیر ٹریک شدہ پالیسی کا استعمال کرتے ہوئے کارکردگی کے ٹیسٹ۔

جب آپ Calico globalNetworkPolicy میں "doNotTrack: true" آپشن سیٹ کرتے ہیں، تو یہ ایک **ٹریک نہ ہونے والی** پالیسی بن جاتی ہے اور لینکس پیکٹ پروسیسنگ پائپ لائن میں بہت جلد لاگو ہوتی ہے۔ اوپر دیے گئے خاکے کو دیکھتے ہوئے، کنکشن ٹریکنگ (کنٹراک) شروع ہونے سے پہلے خام جدول میں PREROUTING اور OUTPUT زنجیروں میں غیر ٹریک شدہ پالیسیوں کا اطلاق ہوتا ہے۔ جب کسی پیکٹ کو ٹریک نہ کی گئی پالیسی کے ذریعے اجازت دی جاتی ہے، تو اس کو اس پیکٹ کے لیے کنکشن ٹریکنگ کو غیر فعال کرنے کے لیے نشان زد کیا جاتا ہے۔ اس کا مطلب ہے:

• غیر ٹریک شدہ پالیسی فی پیکٹ کی بنیاد پر لاگو ہوتی ہے۔ کنکشن (یا بہاؤ) کا کوئی تصور نہیں ہے۔ کنکشن کی کمی کے کئی اہم نتائج ہیں:
• اگر آپ درخواست اور جوابی ٹریفک دونوں کی اجازت دینا چاہتے ہیں، تو آپ کو ان باؤنڈ اور آؤٹ باؤنڈ دونوں کے لیے ایک اصول کی ضرورت ہے (کیونکہ کیلیکو عام طور پر جوابی ٹریفک کو اجازت کے طور پر نشان زد کرنے کے لیے conntrack کا استعمال کرتا ہے)۔
• ٹریک نہ کی گئی پالیسی Kubernetes کے کام کے بوجھ (pods) کے لیے کام نہیں کرتی، کیونکہ اس صورت میں pod سے آؤٹ گوئنگ کنکشن کو ٹریک کرنے کا کوئی طریقہ نہیں ہے۔
• NAT غیر ٹریک شدہ پیکٹوں کے ساتھ صحیح طریقے سے کام نہیں کرتا ہے (چونکہ کرنل NAT میپنگ کو conntrack میں اسٹور کرتا ہے)۔
• غیر ٹریک شدہ پالیسی میں "سب کو اجازت دیں" کے اصول سے گزرتے وقت، تمام پیکٹوں کو ٹریک نہ کیے گئے کے بطور نشان زد کیا جائے گا۔ یہ تقریبا ہمیشہ وہی نہیں ہوتا ہے جو آپ چاہتے ہیں، لہذا غیر ٹریک شدہ پالیسیوں کے ذریعہ اجازت دی گئی پیکٹوں کے بارے میں بہت منتخب ہونا ضروری ہے (اور زیادہ تر ٹریفک کو عام ٹریک شدہ پالیسیوں سے گزرنے کی اجازت دیں)۔
• غیر ٹریک شدہ پالیسیاں پیکٹ پروسیسنگ پائپ لائن کے بالکل شروع میں لاگو ہوتی ہیں۔ Calico پالیسیاں بناتے وقت یہ سمجھنا بہت ضروری ہے۔ آپ کے پاس آرڈر: 1 کے ساتھ پوڈ پالیسی اور آرڈر: 1000 کے ساتھ غیر ٹریک شدہ پالیسی ہو سکتی ہے۔ اس سے کوئی فرق نہیں پڑے گا۔ پوڈ کی پالیسی سے پہلے غیر ٹریک شدہ پالیسی کا اطلاق کیا جائے گا۔ غیر ٹریک شدہ پالیسیاں صرف آپس میں عملدرآمد کے حکم کا احترام کرتی ہیں۔

چونکہ doNotTrack پالیسی کے مقاصد میں سے ایک پالیسی کو لینکس پیکٹ پروسیسنگ پائپ لائن میں بہت جلد نافذ کرنا ہے، Calico doNotTrack استعمال کرتے وقت ApplyOnForward آپشن کی وضاحت کرنا لازمی بناتا ہے۔ پیکٹ پروسیسنگ ڈایاگرام کا حوالہ دیتے ہوئے، نوٹ کریں کہ کسی بھی روٹنگ کے فیصلوں سے پہلے غیر ٹریک شدہ (5) پالیسی کا اطلاق ہوتا ہے۔ ٹریفک کو میزبان کے عمل کی طرف بھیجا جا سکتا ہے، یا اسے پوڈ یا کسی اور نوڈ پر بھیجا جا سکتا ہے۔

کے نتائج

ہم نے کیلیکو میں پالیسی کے مختلف اختیارات (میزبان اختتامی نقطہ، اپلائی آن فارورڈ، پری ڈی این اے ٹی، اور غیر ٹریک شدہ) کو دیکھا اور پیکٹ پروسیسنگ کے راستے پر ان کا اطلاق کیسے کیا جاتا ہے۔ یہ سمجھنا کہ وہ کیسے کام کرتے ہیں موثر اور محفوظ پالیسیاں بنانے میں مدد کرتے ہیں۔ کیلیکو کے ساتھ آپ ایک عالمی نیٹ ورک پالیسی استعمال کر سکتے ہیں جو ایک لیبل (نوڈس اور پوڈز کا ایک گروپ) پر لاگو ہوتی ہے اور مختلف پیرامیٹرز کے ساتھ پالیسیاں لاگو کر سکتے ہیں۔ یہ سیکیورٹی اور نیٹ ورک ڈیزائن کے پیشہ ور افراد کو کیلیکو پالیسیوں کے ساتھ ایک ہی پالیسی زبان کا استعمال کرتے ہوئے ایک بار میں "ہر چیز" (اینڈ پوائنٹ کی اقسام) کی آسانی سے حفاظت کرنے کی اجازت دیتا ہے۔

اعتراف: میں شکریہ ادا کرنا چاہوں گا۔ شان کرمپٹن и الیکسا پولیٹا ان کے جائزے اور قیمتی معلومات کے لیے۔

ماخذ: www.habr.com