Kubernetes کلسٹر میں سوراخ بھرنا۔ DevOpsConf سے رپورٹ اور ٹرانسکرپٹ

Pavel Selivanov، ساؤتھ برج سلوشنز آرکیٹیکٹ اور Slurm کے استاد، نے DevOpsConf 2019 میں ایک پریزنٹیشن دی۔ یہ گفتگو Kubernetes "Slurm Mega" پر گہرائی کے کورس کے عنوانات میں سے ایک کا حصہ ہے۔

سلرم بنیادی: کبرنیٹس کا تعارف 18-20 نومبر کو ماسکو میں ہوتا ہے۔
سلرم میگا: کبرنیٹس کے نیچے دیکھ رہا ہے۔ — ماسکو، نومبر 22-24۔
سلرم آن لائن: دونوں کوبرنیٹس کورسز ہمیشہ دستیاب.

کٹ کے نیچے رپورٹ کی نقل ہے۔

صبح بخیر، ساتھیوں اور ان کے ساتھ ہمدردی رکھنے والوں کو۔ آج میں حفاظت کے بارے میں بات کروں گا۔

میں دیکھ رہا ہوں کہ آج ہال میں بہت سے سیکورٹی گارڈ موجود ہیں۔ میں آپ سے پیشگی معذرت خواہ ہوں اگر میں سلامتی کی دنیا سے ایسی اصطلاحات استعمال کرتا ہوں جیسا کہ آپ کا رواج ہے۔

ایسا ہوا کہ تقریباً چھ مہینے پہلے میں نے ایک عوامی Kubernetes کلسٹر کو دیکھا۔ عوامی کا مطلب ہے کہ نام کی جگہوں کا نواں نمبر ہے؛ ان نام کی جگہوں میں صارف اپنے نام کی جگہ میں الگ تھلگ ہیں۔ ان تمام صارفین کا تعلق مختلف کمپنیوں سے ہے۔ ٹھیک ہے، یہ فرض کیا گیا تھا کہ اس کلسٹر کو CDN کے طور پر استعمال کیا جانا چاہئے. یعنی، وہ آپ کو ایک کلسٹر دیتے ہیں، وہ آپ کو وہاں صارف دیتے ہیں، آپ وہاں اپنے نام کی جگہ پر جاتے ہیں، اپنے محاذوں کو تعینات کرتے ہیں۔

میری پچھلی کمپنی نے ایسی سروس بیچنے کی کوشش کی۔ اور مجھے یہ دیکھنے کے لیے کلسٹر کو پوک کرنے کو کہا گیا کہ آیا یہ حل مناسب ہے یا نہیں۔

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

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

میں آپ کو مثالوں کے ساتھ بتاؤں گا کہ میں نے یہ کیسے کیا اور اپنے آپ کو اس سے کیسے بچایا۔

لیکن پہلے میں اپنا تعارف کرواتا ہوں۔ میرا نام Pavel Selivanov ہے۔ میں ساؤتھ برج میں ایک معمار ہوں۔ میں Kubernetes، DevOps اور ہر طرح کی فینسی چیزوں کو سمجھتا ہوں۔ ساؤتھ برج انجینئرز اور میں یہ سب بنا رہے ہیں، اور میں مشاورت کر رہا ہوں۔

اپنی اہم سرگرمیوں کے علاوہ، ہم نے حال ہی میں Slurms نامی پروجیکٹ شروع کیے ہیں۔ ہم Kubernetes کے ساتھ کام کرنے کی اپنی صلاحیت کو عوام تک پہنچانے کی کوشش کر رہے ہیں، تاکہ دوسرے لوگوں کو بھی K8s کے ساتھ کام کرنا سکھائیں۔

آج میں کیا بات کروں گا؟ رپورٹ کا موضوع واضح ہے - Kubernetes کلسٹر کی سیکورٹی کے بارے میں۔ لیکن میں فوراً یہ کہنا چاہتا ہوں کہ یہ موضوع بہت بڑا ہے - اور اس لیے میں فوری طور پر واضح کرنا چاہتا ہوں کہ میں اس کے بارے میں یقینی طور پر بات نہیں کروں گا۔ میں ایسی ہیکنی اصطلاحات کے بارے میں بات نہیں کروں گا جو پہلے ہی انٹرنیٹ پر سو بار استعمال ہو چکی ہیں۔ تمام قسم کے RBAC اور سرٹیفکیٹ۔

میں اس کے بارے میں بات کروں گا جو مجھے اور میرے ساتھیوں کو ایک Kubernetes کلسٹر میں سیکورٹی کے بارے میں تکلیف دیتا ہے۔ ہم یہ مسائل کوبرنیٹس کلسٹر فراہم کرنے والے فراہم کنندگان اور ہمارے پاس آنے والے کلائنٹس دونوں میں دیکھتے ہیں۔ اور یہاں تک کہ ان کلائنٹس سے جو ہمارے پاس دیگر مشاورتی ایڈمن کمپنیوں سے آتے ہیں۔ یعنی اس سانحے کا پیمانہ دراصل بہت بڑا ہے۔

لفظی طور پر تین نکات ہیں جن پر میں آج بات کروں گا:

1. صارف کے حقوق بمقابلہ پوڈ کے حقوق۔ صارف کے حقوق اور پوڈ کے حقوق ایک ہی چیز نہیں ہیں۔
2. کلسٹر کے بارے میں معلومات جمع کرنا۔ میں دکھاؤں گا کہ آپ اس کلسٹر میں خصوصی حقوق کے بغیر کلسٹر سے اپنی ضرورت کی تمام معلومات اکٹھا کر سکتے ہیں۔
3. کلسٹر پر DoS حملہ۔ اگر ہم معلومات جمع نہیں کر سکتے ہیں، تو ہم کسی بھی صورت میں کلسٹر لگانے کے قابل ہو جائیں گے۔ میں کلسٹر کنٹرول عناصر پر DoS حملوں کے بارے میں بات کروں گا۔

ایک اور عام چیز جس کا میں ذکر کروں گا وہ یہ ہے کہ میں نے یہ سب کیا ہے جس پر میں یقینی طور پر کہہ سکتا ہوں کہ یہ سب کام کرتا ہے۔

ہم Kubespray کا استعمال کرتے ہوئے Kubernetes کلسٹر کی تنصیب کو بنیاد بناتے ہیں۔ اگر کوئی نہیں جانتا ہے تو، یہ اصل میں جواب دینے والے کے کرداروں کا ایک مجموعہ ہے۔ ہم اسے اپنے کام میں مسلسل استعمال کرتے ہیں۔ اچھی بات یہ ہے کہ آپ اسے کہیں بھی رول کر سکتے ہیں - آپ اسے لوہے کے ٹکڑوں پر یا کہیں بادل میں رول کر سکتے ہیں۔ ایک تنصیب کا طریقہ اصولی طور پر ہر چیز کے لیے کام کرتا ہے۔

اس کلسٹر میں میرے پاس Kubernetes v1.14.5 ہوگا۔ مکمل کیوب کلسٹر، جس پر ہم غور کریں گے، نام کی جگہوں میں تقسیم ہے، ہر نام کی جگہ ایک الگ ٹیم سے تعلق رکھتی ہے، اور اس ٹیم کے اراکین کو ہر نام کی جگہ تک رسائی حاصل ہے۔ وہ مختلف نام کی جگہوں پر نہیں جا سکتے، صرف اپنی جگہ۔ لیکن ایک مخصوص ایڈمن اکاؤنٹ ہے جس کے پاس پورے کلسٹر کے حقوق ہیں۔

میں نے وعدہ کیا تھا کہ سب سے پہلے ہم کلسٹر کے منتظم حقوق حاصل کریں گے۔ ہمیں خاص طور پر تیار شدہ پوڈ کی ضرورت ہے جو Kubernetes کلسٹر کو توڑ دے گی۔ ہمیں بس اسے Kubernetes کلسٹر پر لاگو کرنے کی ضرورت ہے۔

kubectl apply -f pod.yaml

یہ پوڈ Kubernetes کلسٹر کے ماسٹرز میں سے ایک تک پہنچ جائے گا۔ اور اس کے بعد کلسٹر خوشی سے ہمیں admin.conf نامی فائل واپس کر دے گا۔ کیوب میں، یہ فائل تمام ایڈمنسٹریٹر سرٹیفکیٹس کو اسٹور کرتی ہے، اور ساتھ ہی ساتھ کلسٹر API کو بھی ترتیب دیتی ہے۔ میرے خیال میں، 98% Kubernetes کلسٹرز تک ایڈمن تک رسائی حاصل کرنا کتنا آسان ہے۔

میں دہراتا ہوں، یہ پوڈ آپ کے کلسٹر میں ایک ڈویلپر نے بنایا تھا جس کے پاس اپنی تجاویز کو ایک چھوٹے سے نام کی جگہ پر تعینات کرنے کی رسائی ہے، یہ سب RBAC کے ذریعے بند کیا گیا ہے۔ اس کے کوئی حقوق نہیں تھے۔ لیکن اس کے باوجود سرٹیفکیٹ واپس کر دیا گیا۔

اور اب خاص طور پر تیار شدہ پھلی کے بارے میں۔ ہم اسے کسی بھی تصویر پر چلاتے ہیں۔ آئیے ایک مثال کے طور پر debian:jessie لیتے ہیں۔

ہمارے پاس یہ چیز ہے:

tolerations:
-   effect: NoSchedule 
    operator: Exists 
nodeSelector: 
    node-role.kubernetes.io/master: "" 

رواداری کیا ہے؟ Kubernetes کلسٹر میں ماسٹرز کو عام طور پر داغدار چیز سے نشان زد کیا جاتا ہے۔ اور اس "انفیکشن" کا جوہر یہ ہے کہ یہ کہتا ہے کہ پوڈز کو ماسٹر نوڈس کو تفویض نہیں کیا جا سکتا۔ لیکن کوئی بھی کسی بھی پوڈ میں یہ بتانے کی زحمت گوارا نہیں کرتا کہ یہ "انفیکشن" کے لیے روادار ہے۔ ٹولریشن سیکشن صرف یہ کہتا ہے کہ اگر کسی نوڈ میں NoSchedule ہے، تو ہمارا نوڈ اس طرح کے انفیکشن کو برداشت کرتا ہے - اور کوئی مسئلہ نہیں ہے۔

مزید، ہم کہتے ہیں کہ ہمارا انڈر نہ صرف روادار ہے، بلکہ خاص طور پر ماسٹر کو نشانہ بنانا چاہتا ہے۔ کیونکہ ماسٹرز کے پاس سب سے مزیدار چیز ہے جس کی ہمیں ضرورت ہے - تمام سرٹیفکیٹ۔ لہذا، ہم کہتے ہیں نوڈ سلیکٹر - اور ہمارے پاس ماسٹرز پر ایک معیاری لیبل ہے، جو آپ کو کلسٹر میں موجود تمام نوڈس سے بالکل وہی نوڈس منتخب کرنے کی اجازت دیتا ہے جو ماسٹرز ہیں۔

ان دو حصوں کے ساتھ وہ ضرور آقا کے پاس آئے گا۔ اور اسے وہاں رہنے کی اجازت ہوگی۔

لیکن صرف آقا کے پاس آنا ہمارے لیے کافی نہیں ہے۔ اس سے ہمیں کچھ نہیں ملے گا۔ تو آگے ہمارے پاس یہ دو چیزیں ہیں:

hostNetwork: true 
hostPID: true 

ہم یہ بتاتے ہیں کہ ہمارا پوڈ، جسے ہم لانچ کرتے ہیں، کرنل کے نام کی جگہ، نیٹ ورک کے نام کی جگہ، اور PID نام کی جگہ میں رہے گا۔ ماسٹر پر پوڈ کے لانچ ہونے کے بعد، یہ اس نوڈ کے تمام حقیقی، لائیو انٹرفیس کو دیکھ سکے گا، تمام ٹریفک کو سن سکے گا اور تمام عمل کی PID دیکھ سکے گا۔

پھر چھوٹی چھوٹی باتوں کا معاملہ ہے۔ etcd لیں اور جو چاہیں پڑھیں۔

سب سے دلچسپ بات یہ Kubernetes کی خصوصیت ہے، جو وہاں ڈیفالٹ کے طور پر موجود ہے۔

volumeMounts:
- mountPath: /host 
  name: host 
volumes:
- hostPath: 
    path: / 
    type: Directory 
  name: host 

اور اس کا خلاصہ یہ ہے کہ ہم پوڈ میں کہہ سکتے ہیں کہ ہم لانچ کرتے ہیں، یہاں تک کہ اس کلسٹر کے حقوق کے بغیر، کہ ہم میزبان پاتھ کی قسم کا حجم بنانا چاہتے ہیں۔ اس کا مطلب ہے میزبان سے راستہ لینا جس پر ہم لانچ کریں گے - اور اسے حجم کے طور پر لینا۔ اور پھر ہم اسے نام کہتے ہیں: میزبان۔ ہم اس پورے ہوسٹ پاتھ کو پوڈ کے اندر ماؤنٹ کرتے ہیں۔ اس مثال میں، /host ڈائریکٹری میں۔

میں اسے دوبارہ دہراؤں گا۔ ہم نے پوڈ کو ماسٹر کے پاس آنے کو کہا، وہاں ہوسٹ نیٹ ورک اور ہوسٹ پی آئی ڈی حاصل کریں - اور اس پوڈ کے اندر ماسٹر کی پوری جڑ لگائیں۔

آپ سمجھتے ہیں کہ Debian میں ہمارے پاس bash چل رہا ہے، اور یہ bash جڑ کے نیچے چلتا ہے۔ یعنی، ہم نے صرف ماسٹر پر روٹ حاصل کیا، بغیر کسی حقوق کے Kubernetes کلسٹر میں۔

پھر سارا کام ذیلی ڈائرکٹری /host /etc/kubernetes/pki پر جانا ہے، اگر میں غلط نہیں ہوں، تو وہاں سے کلسٹر کے تمام ماسٹر سرٹیفکیٹ اٹھائیں اور اس کے مطابق، کلسٹر ایڈمنسٹریٹر بن جائیں۔

اگر آپ اسے اس طرح دیکھیں تو پوڈز میں یہ کچھ سب سے خطرناک حقوق ہیں - قطع نظر اس کے کہ صارف کے پاس کیا حقوق ہیں:

اگر میرے پاس کلسٹر کے کسی نام کی جگہ پر پوڈ چلانے کے حقوق ہیں، تو اس پوڈ کے پاس یہ حقوق بطور ڈیفالٹ ہیں۔ میں مراعات یافتہ پوڈ چلا سکتا ہوں، اور یہ عام طور پر تمام حقوق ہیں، عملی طور پر نوڈ پر جڑ جاتے ہیں۔

میرا پسندیدہ روٹ صارف ہے۔ اور Kubernetes کے پاس یہ Run As Non Root آپشن ہے۔ یہ ہیکر سے تحفظ کی ایک قسم ہے۔ کیا آپ جانتے ہیں "مولڈوین وائرس" کیا ہے؟ اگر آپ اچانک ہیکر ہیں اور میرے Kubernetes کلسٹر میں آتے ہیں، تو ہم، غریب منتظمین، پوچھتے ہیں: "براہ کرم اپنے پوڈز میں اس بات کی نشاندہی کریں کہ آپ میرا کلسٹر ہیک کریں گے، نان روٹ کے طور پر چلائیں۔ بصورت دیگر، یہ ہوگا کہ آپ اپنے پوڈ میں اس عمل کو جڑ کے نیچے چلائیں گے، اور آپ کے لیے مجھے ہیک کرنا بہت آسان ہوگا۔ براہ کرم اپنے آپ کو اپنے آپ سے بچائیں۔"

ہوسٹ پاتھ والیوم، میری رائے میں، Kubernetes کلسٹر سے مطلوبہ نتیجہ حاصل کرنے کا تیز ترین طریقہ ہے۔

لیکن اس سب کا کیا کریں؟

کسی بھی نارمل ایڈمنسٹریٹر کو جو خیال آنا چاہیے جو کبرنیٹس کا سامنا کرتا ہے وہ یہ ہے: "ہاں، میں نے آپ کو بتایا، کبرنیٹس کام نہیں کرتا۔ اس میں سوراخ ہیں۔ اور پورا کیوب بکواس ہے۔" حقیقت میں، دستاویزات کے طور پر ایک ایسی چیز ہے، اور اگر آپ وہاں دیکھیں تو، ایک سیکشن ہے پوڈ سیکیورٹی پالیسی.

یہ ایک یامل آبجیکٹ ہے - ہم اسے Kubernetes کلسٹر میں بنا سکتے ہیں - جو خاص طور پر پوڈز کی تفصیل میں حفاظتی پہلوؤں کو کنٹرول کرتا ہے۔ یعنی، درحقیقت، یہ کسی بھی hostNetwork، hostPID، کچھ حجم کی قسموں کو استعمال کرنے کے حقوق کو کنٹرول کرتا ہے جو شروع کے وقت پوڈز میں ہوتے ہیں۔ پوڈ سیکیورٹی پالیسی کی مدد سے یہ سب کچھ بیان کیا جا سکتا ہے۔

Pod سیکیورٹی پالیسی کے بارے میں سب سے دلچسپ بات یہ ہے کہ Kubernetes کلسٹر میں تمام PSP انسٹالرز کو کسی بھی طرح سے بیان نہیں کیا گیا ہے، وہ صرف ڈیفالٹ کے ذریعے غیر فعال ہیں۔ پوڈ سیکیورٹی پالیسی کو داخلہ پلگ ان کا استعمال کرتے ہوئے فعال کیا گیا ہے۔

ٹھیک ہے، آئیے پوڈ سیکیورٹی پالیسی کو کلسٹر میں متعین کرتے ہیں، ہم کہتے ہیں کہ ہمارے پاس نام کی جگہ میں کچھ سروس پوڈز ہیں، جن تک صرف ایڈمنز کو رسائی حاصل ہے۔ ہم کہتے ہیں، دیگر تمام معاملات میں، پوڈ کے محدود حقوق ہیں۔ کیونکہ زیادہ تر ممکنہ ڈویلپرز کو آپ کے کلسٹر میں مراعات یافتہ پوڈز چلانے کی ضرورت نہیں ہے۔

اور ایسا لگتا ہے کہ ہمارے ساتھ سب کچھ ٹھیک ہے۔ اور ہمارے Kubernetes کلسٹر کو دو منٹ میں ہیک نہیں کیا جا سکتا۔

ایک مسئلہ ہے۔ زیادہ تر امکان ہے، اگر آپ کے پاس Kubernetes کلسٹر ہے، تو آپ کے کلسٹر پر مانیٹرنگ انسٹال ہے۔ میں یہاں تک کہ یہ پیشین گوئی کرنے کے لئے بھی جاؤں گا کہ اگر آپ کے کلسٹر کی نگرانی ہے تو اسے پرومیتھیس کہا جائے گا۔

جو میں آپ کو بتانے جا رہا ہوں وہ Prometheus آپریٹر اور Prometheus دونوں کے لیے اس کی خالص شکل میں ڈیلیور کرنے کے لیے درست ہوگا۔ سوال یہ ہے کہ اگر میں اتنی جلدی کلسٹر میں ایڈمن نہیں لا سکتا، تو اس کا مطلب ہے کہ مجھے مزید دیکھنے کی ضرورت ہے۔ اور میں آپ کی نگرانی کی مدد سے تلاش کر سکتا ہوں۔

شاید ہر کوئی Habré پر ایک جیسے مضامین پڑھتا ہے، اور مانیٹرنگ مانیٹرنگ نام کی جگہ میں واقع ہے۔ ہیلم چارٹ ہر ایک کے لیے تقریباً یکساں کہلاتا ہے۔ میں اندازہ لگا رہا ہوں کہ اگر آپ ہیلم انسٹال کرتے ہیں stable/prometheus، تو آپ تقریباً ایک جیسے ناموں کے ساتھ ختم ہوں گے۔ اور غالباً مجھے آپ کے کلسٹر میں DNS نام کا اندازہ بھی نہیں لگانا پڑے گا۔ کیونکہ یہ معیاری ہے۔

اگلا ہمارے پاس ایک مخصوص ڈیو این ایس ہے، جس میں آپ ایک مخصوص پوڈ چلا سکتے ہیں۔ اور پھر اس پوڈ سے اس طرح کچھ کرنا بہت آسان ہے:

$ curl http://prometheus-kube-state-metrics.monitoring 

prometheus-kube-state-metrics Prometheus برآمد کنندگان میں سے ایک ہے جو خود Kubernetes API سے میٹرکس اکٹھا کرتا ہے۔ وہاں بہت سا ڈیٹا موجود ہے، آپ کے کلسٹر میں کیا چل رہا ہے، یہ کیا ہے، آپ کو اس میں کیا مسائل ہیں۔

ایک سادہ مثال کے طور پر:

kube_pod_container_info{namespace="kube-system",pod="kube-apiserver-k8s- 1″,container="kube-apiserver",image=

"gcr.io/google-containers/kube-apiserver:v1.14.5"

,image_id=»docker-pullable://gcr.io/google-containers/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1

غیر مراعات یافتہ پوڈ سے ایک سادہ کرل کی درخواست کر کے، آپ درج ذیل معلومات حاصل کر سکتے ہیں۔ اگر آپ نہیں جانتے ہیں کہ آپ Kubernetes کا کون سا ورژن چلا رہے ہیں، تو یہ آپ کو آسانی سے بتا دے گا۔

اور سب سے دلچسپ بات یہ ہے کہ kube-state-metrics تک رسائی کے علاوہ، آپ Prometheus تک براہ راست آسانی سے رسائی حاصل کر سکتے ہیں۔ آپ وہاں سے میٹرکس اکٹھا کر سکتے ہیں۔ آپ وہاں سے میٹرکس بھی بنا سکتے ہیں۔ یہاں تک کہ نظریاتی طور پر، آپ Prometheus میں ایک کلسٹر سے اس طرح کا سوال بنا سکتے ہیں، جو اسے بند کر دے گا۔ اور آپ کی نگرانی کلسٹر سے مکمل طور پر کام کرنا بند کر دے گی۔

اور یہاں سوال یہ پیدا ہوتا ہے کہ کیا کوئی بیرونی نگرانی آپ کی مانیٹرنگ کو مانیٹر کرتی ہے؟ مجھے ابھی ایک Kubernetes کلسٹر میں کام کرنے کا موقع ملا ہے جس کے میرے لیے کوئی نتائج نہیں ہیں۔ آپ کو یہ بھی معلوم نہیں ہوگا کہ میں وہاں کام کر رہا ہوں، کیونکہ اب کوئی نگرانی نہیں ہے۔

بالکل اسی طرح جیسے PSP کے ساتھ، ایسا محسوس ہوتا ہے کہ مسئلہ یہ ہے کہ یہ تمام فینسی ٹیکنالوجیز - Kubernetes، Prometheus - وہ کام نہیں کرتی ہیں اور سوراخوں سے بھری ہوئی ہیں۔ واقعی نہیں۔

ایسی بات ہے - نیٹ ورک کی پالیسی.

اگر آپ ایک عام ایڈمن ہیں، تو غالباً آپ نیٹ ورک پالیسی کے بارے میں جانتے ہوں گے کہ یہ صرف ایک اور یامل ہے، جس میں سے پہلے ہی بہت سارے کلسٹر میں موجود ہیں۔ اور کچھ نیٹ ورک پالیسیوں کی ضرور ضرورت نہیں ہے۔ اور یہاں تک کہ اگر آپ یہ پڑھتے ہیں کہ نیٹ ورک پالیسی کیا ہے، کہ یہ Kubernetes کی yaml فائر وال ہے، یہ آپ کو نام کی جگہوں کے درمیان، pods کے درمیان رسائی کے حقوق کو محدود کرنے کی اجازت دیتی ہے، پھر آپ نے یقینی طور پر فیصلہ کیا ہے کہ Kubernetes میں yaml فارمیٹ میں فائر وال اگلے خلاصوں پر مبنی ہے۔ ... نہیں نہیں . یہ یقینی طور پر ضروری نہیں ہے۔

یہاں تک کہ اگر آپ نے اپنے سیکیورٹی ماہرین کو یہ نہیں بتایا کہ اپنے Kubernetes کا استعمال کرتے ہوئے آپ ایک بہت ہی آسان اور سادہ فائر وال بنا سکتے ہیں، اور اس میں بہت دانے دار بھی۔ اگر وہ ابھی تک یہ نہیں جانتے ہیں اور آپ کو پریشان نہیں کرتے ہیں: "ٹھیک ہے، مجھے دو، مجھے دو..." پھر کسی بھی صورت میں، آپ کو کچھ سروس مقامات تک رسائی کو روکنے کے لیے نیٹ ورک پالیسی کی ضرورت ہے جنہیں آپ کے کلسٹر سے نکالا جا سکتا ہے۔ بغیر کسی اجازت کے۔

جیسا کہ میں نے مثال دی ہے، آپ کوبرنیٹس کلسٹر میں کسی بھی نام کی جگہ سے کیوب اسٹیٹ میٹرکس کو بغیر کسی حقوق کے کھینچ سکتے ہیں۔ نیٹ ورک کی پالیسیوں نے دیگر تمام نام کی جگہوں سے نگرانی کے نام کی جگہ تک رسائی بند کر دی ہے اور بس: کوئی رسائی نہیں، کوئی مسئلہ نہیں۔ موجود تمام چارٹس میں، معیاری Prometheus اور Prometheus دونوں جو آپریٹر میں ہیں، صرف ان کے لیے نیٹ ورک کی پالیسیوں کو فعال کرنے کے لیے ہیلم ویلیوز میں ایک آپشن موجود ہے۔ آپ کو صرف اسے آن کرنے کی ضرورت ہے اور وہ کام کریں گے۔

یہاں واقعی ایک مسئلہ ہے۔ ایک عام داڑھی والے منتظم ہونے کے ناطے، آپ نے غالباً فیصلہ کیا ہے کہ نیٹ ورک کی پالیسیوں کی ضرورت نہیں ہے۔ اور Habr جیسے وسائل پر ہر قسم کے مضامین کو پڑھنے کے بعد، آپ نے فیصلہ کیا کہ فلالین، خاص طور پر ہوسٹ-گیٹ وے موڈ کے ساتھ، وہ بہترین چیز ہے جسے آپ منتخب کر سکتے ہیں۔

کیا؟

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

اور مسئلہ درحقیقت بہت آسانی سے حل ہو جاتا ہے۔ کلسٹر میں سرٹیفکیٹ ہیں، اور آپ جانتے ہیں کہ آپ کے سرٹیفکیٹس ایک سال میں ختم ہو جائیں گے۔ ٹھیک ہے، عام طور پر ایک کلسٹر میں سرٹیفکیٹس کے ساتھ ایک عام حل - ہم پریشان کیوں ہیں، ہم قریب ہی ایک نیا کلسٹر بنائیں گے، پرانے کو بوسیدہ ہونے دیں گے، اور ہر چیز کو دوبارہ تعینات کریں گے۔ سچ ہے، جب یہ بوسیدہ ہو جائے گا، تو ہمیں ایک دن بیٹھنا پڑے گا، لیکن یہاں ایک نیا جھرمٹ ہے۔

جب آپ ایک نیا کلسٹر اٹھاتے ہیں، اسی وقت فلالین کے بجائے کیلیکو ڈالیں۔

اگر آپ کے سرٹیفکیٹ سو سال کے لیے جاری کیے جائیں اور آپ کلسٹر کو دوبارہ تعینات نہیں کریں گے تو کیا کریں؟ Kube-RBAC-Proxy جیسی چیز ہے۔ یہ ایک بہت ہی عمدہ پیشرفت ہے، یہ آپ کو کبرنیٹس کلسٹر میں کسی بھی پوڈ میں سائڈ کار کنٹینر کے طور پر سرایت کرنے کی اجازت دیتی ہے۔ اور یہ اصل میں خود کوبرنیٹس کے RBAC کے ذریعے اس پوڈ میں اجازت دیتا ہے۔

ایک مسئلہ ہے۔ پہلے، یہ Kube-RBAC-Proxy حل آپریٹر کے Prometheus میں بنایا گیا تھا۔ لیکن پھر وہ چلا گیا تھا۔ اب جدید ورژن اس حقیقت پر انحصار کرتے ہیں کہ آپ کے پاس نیٹ ورک کی پالیسی ہے اور ان کا استعمال کرتے ہوئے اسے بند کر دیں۔ اور اس لیے ہمیں چارٹ کو تھوڑا سا دوبارہ لکھنا پڑے گا۔ اصل میں، اگر آپ جاتے ہیں یہ ذخیرہ، اس کو سائڈ کار کے طور پر استعمال کرنے کے طریقے کی مثالیں موجود ہیں، اور چارٹس کو کم سے کم دوبارہ لکھنا پڑے گا۔

ایک اور چھوٹا مسئلہ ہے۔ Prometheus صرف وہی نہیں ہے جو اس کی پیمائش صرف کسی کو دے رہا ہے۔ ہمارے تمام Kubernetes کلسٹر اجزاء بھی اپنے اپنے میٹرکس واپس کرنے کے قابل ہیں۔

لیکن جیسا کہ میں نے پہلے ہی کہا ہے، اگر آپ کلسٹر تک رسائی حاصل نہیں کر سکتے اور معلومات اکٹھا نہیں کر سکتے، تو آپ کم از کم کچھ نقصان پہنچا سکتے ہیں۔

لہذا میں جلدی سے دو طریقے دکھاؤں گا کہ کبرنیٹس کلسٹر کو کیسے برباد کیا جا سکتا ہے۔

جب میں آپ کو یہ بتاؤں گا تو آپ ہنسیں گے، یہ دو حقیقی زندگی کے واقعات ہیں۔

طریقہ ایک۔ وسائل کی کمی۔

آئیے ایک اور خصوصی پوڈ لانچ کرتے ہیں۔ اس کا ایک سیکشن اس طرح ہوگا۔

resources: 
    requests: 
        cpu: 4 
        memory: 4Gi 

جیسا کہ آپ جانتے ہیں، درخواستیں سی پی یو اور میموری کی مقدار ہے جو درخواستوں کے ساتھ مخصوص پوڈز کے لیے میزبان پر محفوظ ہے۔ اگر ہمارے پاس Kubernetes کلسٹر میں ایک چار کور میزبان ہے، اور چار CPU پوڈز درخواستوں کے ساتھ وہاں پہنچتے ہیں، تو اس کا مطلب ہے کہ درخواستوں کے ساتھ مزید پوڈز اس میزبان کے پاس نہیں آسکیں گے۔

اگر میں ایسی پوڈ چلاتا ہوں، تو میں کمانڈ چلاؤں گا:

$ kubectl scale special-pod --replicas=...

پھر کوئی اور کوبرنیٹس کلسٹر میں تعینات نہیں کر سکے گا۔ کیونکہ تمام نوڈس کی درخواستیں ختم ہو جائیں گی۔ اور اس طرح میں آپ کے Kubernetes کلسٹر کو روک دوں گا۔ اگر میں شام کو ایسا کرتا ہوں تو میں کافی دیر تک تعیناتیوں کو روک سکتا ہوں۔

اگر ہم کوبرنیٹس کی دستاویزات پر دوبارہ نظر ڈالیں، تو ہمیں یہ چیز نظر آئے گی جسے Limit Range کہتے ہیں۔ یہ کلسٹر آبجیکٹ کے لیے وسائل متعین کرتا ہے۔ آپ yaml میں Limit Range آبجیکٹ لکھ سکتے ہیں، اسے مخصوص نام کی جگہوں پر لاگو کر سکتے ہیں - اور پھر اس نام کی جگہ میں آپ کہہ سکتے ہیں کہ آپ کے پاس پوڈز کے لیے پہلے سے طے شدہ، زیادہ سے زیادہ اور کم سے کم وسائل ہیں۔

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

اور یہیں سے طریقہ نمبر دو آتا ہے۔ ہم 11 پوڈز لانچ کرتے ہیں۔ یہ گیارہ ارب ہے۔ یہ اس لیے نہیں ہے کہ میں اس طرح کا نمبر لے کر آیا ہوں، بلکہ اس لیے کہ میں نے اسے خود دیکھا ہے۔

حقیقی کہانی۔ شام کو میں دفتر سے نکلنے ہی والا تھا۔ میں دیکھتا ہوں کہ ڈویلپرز کا ایک گروپ کونے میں بیٹھا ہے، جو اپنے لیپ ٹاپ کے ساتھ بزدلانہ طور پر کچھ کر رہا ہے۔ میں لڑکوں کے پاس جاتا ہوں اور پوچھتا ہوں: "تمہیں کیا ہوا؟"

تھوڑی دیر پہلے، شام نو بجے کے قریب، ایک ڈویلپر گھر جانے کے لیے تیار ہو رہا تھا۔ اور میں نے فیصلہ کیا: "اب میں اپنی درخواست کو ایک تک کم کروں گا۔" میں نے ایک دبایا، لیکن انٹرنیٹ تھوڑا سا سست ہوگیا۔ اس نے ایک کو دوبارہ دبایا، اس نے ایک کو دبایا، اور Enter پر کلک کیا۔ میں نے ہر ممکن کوشش کی۔ پھر انٹرنیٹ زندگی میں آیا - اور ہر چیز اس نمبر تک کم ہونے لگی۔

سچ ہے، یہ کہانی کوبرنیٹس پر نہیں ہوئی؛ اس وقت یہ خانہ بدوش تھی۔ یہ اس حقیقت کے ساتھ ختم ہوا کہ نوماد کو پیمانہ بنانے کی مسلسل کوششوں سے روکنے کی ہماری کوششوں کے ایک گھنٹے کے بعد، نوماد نے جواب دیا کہ وہ پیمانہ بندی نہیں روکے گا اور کچھ نہیں کرے گا۔ "میں تھک گیا ہوں، جا رہا ہوں۔" اور وہ جھک گیا۔

قدرتی طور پر، میں نے Kubernetes پر ایسا کرنے کی کوشش کی۔ Kubernetes گیارہ بلین پھلیوں سے خوش نہیں تھا، اس نے کہا: "میں نہیں کر سکتا۔ اندرونی ماؤتھ گارڈز سے زیادہ ہے۔" لیکن 1 pods کر سکتے ہیں.

ایک ارب کے جواب میں، کیوب اپنے آپ میں واپس نہیں آیا۔ اس نے واقعی اسکیلنگ شروع کردی۔ یہ عمل جتنا آگے بڑھتا گیا، اسے نئی پھلیاں بنانے میں اتنا ہی وقت لگا۔ لیکن پھر بھی عمل جاری رہا۔ مسئلہ صرف یہ ہے کہ اگر میں اپنے نام کی جگہ پر پوڈز کو لامحدود طور پر لانچ کر سکتا ہوں، تو پھر بھی درخواستوں اور حدود کے بغیر میں کچھ کاموں کے ساتھ اتنے زیادہ پوڈز لانچ کر سکتا ہوں کہ ان کاموں کی مدد سے نوڈس میموری میں، CPU میں شامل ہونا شروع ہو جائیں گے۔ جب میں بہت سارے پوڈز لانچ کرتا ہوں تو ان سے معلومات کو سٹوریج میں جانا چاہیے، یعنی وغیرہ۔ اور جب بہت زیادہ معلومات وہاں پہنچ جاتی ہیں، تو ذخیرہ بہت آہستہ سے واپس آنا شروع ہو جاتا ہے - اور Kubernetes سست ہونا شروع ہو جاتا ہے۔

اور ایک اور مسئلہ... جیسا کہ آپ جانتے ہیں، Kubernetes کنٹرول عناصر ایک مرکزی چیز نہیں ہیں، بلکہ کئی اجزاء ہیں۔ خاص طور پر، ایک کنٹرولر مینیجر، شیڈولر، اور اسی طرح ہے. یہ سب لوگ ایک ہی وقت میں غیر ضروری، احمقانہ کام کرنے لگیں گے، جس میں وقت گزرنے کے ساتھ ساتھ زیادہ سے زیادہ وقت لگنا شروع ہو جائے گا۔ کنٹرولر مینیجر نئے پوڈز بنائے گا۔ شیڈولر ان کے لیے ایک نیا نوڈ تلاش کرنے کی کوشش کرے گا۔ آپ کے کلسٹر میں جلد ہی نئے نوڈس ختم ہونے کا امکان ہے۔ Kubernetes کلسٹر آہستہ سے کام کرنا شروع کر دے گا۔

لیکن میں نے اس سے بھی آگے جانے کا فیصلہ کیا۔ جیسا کہ آپ جانتے ہیں، Kubernetes میں ایسی چیز ہے جسے سروس کہتے ہیں۔ ٹھیک ہے، آپ کے کلسٹرز میں بطور ڈیفالٹ، غالباً، سروس آئی پی ٹیبلز کا استعمال کرتے ہوئے کام کرتی ہے۔

اگر آپ مثال کے طور پر ایک ارب پوڈ چلاتے ہیں، اور پھر Kubernetis کو نئی سروسز بنانے پر مجبور کرنے کے لیے اسکرپٹ کا استعمال کرتے ہیں:

for i in {1..1111111}; do
    kubectl expose deployment test --port 80  
        --overrides="{"apiVersion": "v1", 
           "metadata": {"name": "nginx$i"}}"; 
done 

کلسٹر کے تمام نوڈس پر، تقریباً ایک ہی وقت میں زیادہ سے زیادہ نئے iptables قواعد تیار کیے جائیں گے۔ مزید برآں، ہر سروس کے لیے ایک بلین iptables قواعد تیار کیے جائیں گے۔

میں نے اس ساری چیز کو کئی ہزار، دس تک چیک کیا۔ اور مسئلہ یہ ہے کہ پہلے ہی اس دہلیز پر نوڈ پر ssh کرنا کافی مشکل ہے۔ کیونکہ پیکٹ، بہت سی زنجیروں سے گزرتے ہوئے، بہت اچھے نہیں لگنے لگتے ہیں۔

اور یہ سب بھی Kubernetes کی مدد سے حل ہو جاتا ہے۔ اس طرح کا ریسورس کوٹہ آبجیکٹ ہے۔ کلسٹر میں نام کی جگہ کے لیے دستیاب وسائل اور اشیاء کی تعداد مقرر کرتا ہے۔ ہم Kubernetes کلسٹر کے ہر نام کی جگہ میں yaml آبجیکٹ بنا سکتے ہیں۔ اس آبجیکٹ کو استعمال کرتے ہوئے، ہم کہہ سکتے ہیں کہ ہمارے پاس اس نام کی جگہ کے لیے مخصوص تعداد میں درخواستیں اور حدود مختص ہیں، اور پھر ہم کہہ سکتے ہیں کہ اس نام کی جگہ میں 10 سروسز اور 10 پوڈز بنانا ممکن ہے۔ اور ایک ہی ڈویلپر کم از کم شام کو اپنا گلا گھونٹ سکتا ہے۔ کوبرنیٹس اس سے کہے گا: "آپ اپنی پھلیوں کو اس مقدار تک نہیں بڑھا سکتے، کیونکہ وسائل کوٹے سے زیادہ ہے۔" بس، مسئلہ حل ہو گیا۔ یہاں دستاویزی.

اس سلسلے میں ایک مسئلہ پیدا ہوتا ہے۔ آپ محسوس کرتے ہیں کہ Kubernetes میں نام کی جگہ بنانا کتنا مشکل ہوتا جا رہا ہے۔ اسے بنانے کے لیے ہمیں بہت سی چیزوں کو مدنظر رکھنا ہوگا۔

وسائل کا کوٹہ + حد کی حد + RBAC
• ایک نام کی جگہ بنائیں
• اندر ایک حد بندی بنائیں
• اندر وسائل کوٹہ بنائیں
• CI کے لیے ایک سروس اکاؤنٹ بنائیں
• CI اور صارفین کے لیے رول بائنڈنگ بنائیں
• اختیاری طور پر ضروری سروس پوڈز شروع کریں۔

لہذا، میں اس موقع کو اپنی پیشرفت کا اشتراک کرنا چاہتا ہوں۔ ایسی چیز ہے جسے SDK آپریٹر کہتے ہیں۔ یہ Kubernetes کلسٹر کے لیے آپریٹرز لکھنے کا ایک طریقہ ہے۔ آپ Ansible کا استعمال کرتے ہوئے بیانات لکھ سکتے ہیں۔

سب سے پہلے یہ Ansible میں لکھا گیا تھا، اور پھر میں نے دیکھا کہ ایک SDK آپریٹر تھا اور جوابی کردار کو آپریٹر میں دوبارہ لکھا۔ یہ بیان آپ کو Kubernetes کلسٹر میں ایک ایسی چیز بنانے کی اجازت دیتا ہے جسے کمانڈ کہتے ہیں۔ ایک کمانڈ کے اندر، یہ آپ کو یامل میں اس کمانڈ کے ماحول کو بیان کرنے کی اجازت دیتا ہے۔ اور ٹیم کے ماحول میں، یہ ہمیں یہ بیان کرنے کی اجازت دیتا ہے کہ ہم بہت سارے وسائل مختص کر رہے ہیں۔

تھوڑا سا اس پورے پیچیدہ عمل کو آسان بنانا.

اور آخر میں۔ اس سب کا کیا کیا جائے؟
پہلا. پوڈ سیکیورٹی پالیسی اچھی ہے۔ اور اس حقیقت کے باوجود کہ کوبرنیٹس انسٹالرز میں سے کوئی بھی انہیں آج تک استعمال نہیں کرتا ہے، پھر بھی آپ کو انہیں اپنے کلسٹرز میں استعمال کرنے کی ضرورت ہے۔

نیٹ ورک پالیسی صرف ایک اور غیر ضروری خصوصیت نہیں ہے۔ یہ وہی ہے جو ایک کلسٹر میں واقعی ضرورت ہے.

LimitRange/ResourceQuota - اسے استعمال کرنے کا وقت آگیا ہے۔ ہم نے اسے بہت پہلے استعمال کرنا شروع کیا تھا، اور کافی عرصے سے مجھے یقین تھا کہ ہر کوئی اسے استعمال کر رہا ہے۔ معلوم ہوا کہ یہ نایاب ہے۔

اس کے علاوہ جو میں نے رپورٹ کے دوران ذکر کیا ہے، وہاں غیر دستاویزی خصوصیات ہیں جو آپ کو کلسٹر پر حملہ کرنے کی اجازت دیتی ہیں۔ حال ہی میں ریلیز ہوا۔ Kubernetes کی کمزوریوں کا وسیع تجزیہ.

کچھ چیزیں بہت افسوسناک اور تکلیف دہ ہوتی ہیں۔ مثال کے طور پر، کچھ شرائط کے تحت، کبرنیٹس کلسٹر میں کیوبلیٹس وارلاک ڈائرکٹری کے مواد کو کسی غیر مجاز صارف کو دے سکتے ہیں۔

یہاں اس بارے میں ہدایات موجود ہیں کہ میں نے آپ کو بتائی ہر چیز کو دوبارہ کیسے بنایا جائے۔ ایسی فائلیں موجود ہیں جن میں پروڈکشن کی مثالیں ہیں کہ ریسورس کوٹا اور پوڈ سیکیورٹی پالیسی کیسی نظر آتی ہے۔ اور آپ ان سب کو چھو سکتے ہیں۔

سب کا شکریہ.

ماخذ: www.habr.com