Kubernetes کے لیے سب سے زیادہ مقبول پیکیج مینیجر کے بارے میں کہانی کا نچوڑ ایک ایموجی کا استعمال کرتے ہوئے دکھایا جا سکتا ہے:
- باکس ہیلم ہے (جو تازہ ترین ایموجی ریلیز کی قریب ترین چیز ہے)؛
- تالا - سیکورٹی؛
- چھوٹا آدمی مسئلے کا حل ہے۔
اصل میں، سب کچھ تھوڑا زیادہ پیچیدہ ہو جائے گا، اور کہانی کے بارے میں تکنیکی تفصیلات سے بھرا ہوا ہے ہیلم کو محفوظ بنانے کا طریقہ.
- مختصراً ہیلم کیا ہے اگر آپ نہیں جانتے یا بھول گئے ہیں۔ یہ کون سے مسائل حل کرتا ہے اور یہ ماحولیاتی نظام میں کہاں واقع ہے۔
- آئیے ہیلم فن تعمیر کو دیکھتے ہیں۔ سیکیورٹی کے بارے میں اور کسی ٹول یا حل کو زیادہ محفوظ بنانے کے طریقے کے بارے میں کوئی بات چیت جزو کے فن تعمیر کو سمجھے بغیر مکمل نہیں ہوتی۔
- آئیے ہیلم کے اجزاء پر بات کرتے ہیں۔
- سب سے سلگتا ہوا سوال مستقبل کا ہے - ہیلم 3 کا نیا ورژن۔
اس آرٹیکل میں ہر چیز کا اطلاق ہیلم 2 پر ہوتا ہے۔ یہ ورژن فی الحال پروڈکشن میں ہے اور غالباً وہی ورژن ہے جسے آپ فی الحال استعمال کر رہے ہیں، اور یہ وہ ورژن ہے جس میں سیکیورٹی کے خطرات ہیں۔
اسپیکر کے بارے میں: الیگزینڈر خیروف () مواد کو بہتر بنانے میں مدد کرتے ہوئے 10 سالوں سے ترقی کر رہا ہے۔ اور کمیٹی میں شامل ہوئے۔ . اب وہ ڈیولپمنٹ لیڈ کے طور پر Chainstack میں کام کرتا ہے - یہ ایک ڈویلپمنٹ مینیجر اور ایک ایسے شخص کے درمیان ایک ہائبرڈ ہے جو حتمی ریلیز فراہم کرنے کا ذمہ دار ہے۔ یعنی یہ میدان جنگ میں واقع ہے، جہاں پروڈکٹ کی تخلیق سے لے کر اس کے آپریشن تک سب کچھ ہوتا ہے۔
Chainstack ایک چھوٹا، فعال طور پر بڑھتا ہوا سٹارٹ اپ ہے جس کا مقصد کلائنٹس کو اس قابل بنانا ہے کہ وہ وکندریقرت ایپلی کیشنز کو چلانے کے بنیادی ڈھانچے اور پیچیدگیوں کو بھول جائیں؛ ترقیاتی ٹیم سنگاپور میں واقع ہے۔ Chainstack سے کرپٹو کرنسی بیچنے یا خریدنے کے لیے نہ کہیں، بلکہ انٹرپرائز بلاکچین فریم ورک کے بارے میں بات کرنے کی پیشکش کریں، اور وہ خوشی سے آپ کو جواب دیں گے۔
پتوار
یہ Kubernetes کے لیے ایک پیکیج (چارٹ) مینیجر ہے۔ ایپلیکیشنز کو کبرنیٹس کلسٹر میں لانے کا سب سے بدیہی اور عالمگیر طریقہ۔
یقیناً ہم آپ کے اپنے YAML مینی فیسٹ بنانے اور چھوٹی افادیت لکھنے سے زیادہ ساختی اور صنعتی نقطہ نظر کے بارے میں بات کر رہے ہیں۔
ہیلم بہترین ہے جو فی الحال دستیاب اور مقبول ہے۔
ہیلم کیوں؟ بنیادی طور پر اس لیے کہ اسے CNCF کی طرف سے تعاون حاصل ہے۔ Cloud Native ایک بڑی تنظیم ہے اور Kubernetes، etcd، Fluentd اور دیگر پروجیکٹس کے لیے بنیادی کمپنی ہے۔
ایک اور اہم حقیقت یہ ہے کہ ہیلم ایک بہت مقبول منصوبہ ہے۔ جب میں نے جنوری 2019 میں ہیلم کو محفوظ بنانے کے بارے میں بات کرنا شروع کی تو اس پروجیکٹ کے GitHub پر ایک ہزار ستارے تھے۔ مئی تک ان میں سے 12 ہزار تھے۔
بہت سے لوگ ہیلم میں دلچسپی رکھتے ہیں، لہذا اگر آپ اسے ابھی تک استعمال نہیں کرتے ہیں، تو آپ کو اس کی حفاظت کے بارے میں جان کر فائدہ ہوگا۔ حفاظت اہم ہے۔
بنیادی ہیلم ٹیم کو مائیکروسافٹ Azure کی حمایت حاصل ہے اور اس وجہ سے بہت سے دوسرے لوگوں کے برعکس کافی مستحکم پروجیکٹ ہے۔ جولائی کے وسط میں Helm 3 Alpha 2 کی ریلیز اس بات کی نشاندہی کرتی ہے کہ اس پروجیکٹ پر کافی لوگ کام کر رہے ہیں، اور ان میں ہیلم کو تیار کرنے اور اسے بہتر بنانے کی خواہش اور توانائی ہے۔
ہیلم کبرنیٹس میں ایپلیکیشن مینجمنٹ کے کئی بنیادی مسائل کو حل کرتا ہے۔
- درخواست کی پیکیجنگ۔ یہاں تک کہ ورڈپریس پر "ہیلو، ورلڈ" جیسی ایپلیکیشن پہلے سے ہی کئی سروسز پر مشتمل ہوتی ہے، اور آپ انہیں ایک ساتھ پیک کرنا چاہتے ہیں۔
- ان ایپلی کیشنز کے انتظام کے ساتھ آنے والی پیچیدگی کا انتظام کرنا۔
- ایک لائف سائیکل جو ایپلیکیشن کے انسٹال یا تعینات ہونے کے بعد ختم نہیں ہوتا ہے۔ یہ زندہ رہتا ہے، اسے اپ ڈیٹ کرنے کی ضرورت ہے، اور ہیلم اس میں مدد کرتا ہے اور اس کے لیے صحیح اقدامات اور پالیسیاں لانے کی کوشش کرتا ہے۔
بیگنگ یہ ایک واضح انداز میں ترتیب دیا گیا ہے: لینکس، ونڈوز یا میک او ایس کے لیے باقاعدہ پیکیج مینیجر کے کام کے مطابق میٹا ڈیٹا موجود ہے۔ یعنی ایک ذخیرہ، مختلف پیکجز پر انحصار، ایپلی کیشنز کے لیے میٹا معلومات، سیٹنگز، کنفیگریشن فیچرز، انفارمیشن انڈیکسنگ وغیرہ۔ ہیلم آپ کو ایپلی کیشنز کے لیے یہ سب حاصل کرنے اور استعمال کرنے کی اجازت دیتا ہے۔
پیچیدگی کا انتظام. اگر آپ کے پاس ایک ہی قسم کی بہت سی ایپلی کیشنز ہیں، تو پیرامیٹرائزیشن کی ضرورت ہے۔ ٹیمپلیٹس اس سے آتے ہیں، لیکن ٹیمپلیٹس بنانے کے اپنے طریقے کے ساتھ آنے سے بچنے کے لیے، آپ باکس کے باہر ہیلم کی پیشکش کو استعمال کر سکتے ہیں۔
ایپلیکیشن لائف سائیکل مینجمنٹ - میری رائے میں، یہ سب سے دلچسپ اور حل طلب سوال ہے۔ یہی وجہ ہے کہ میں دن میں ہیلم واپس آیا۔ ہمیں ایپلیکیشن لائف سائیکل پر نظر رکھنے کی ضرورت تھی اور ہم اپنے CI/CD اور ایپلیکیشن سائیکل کو اس پیراڈائم میں منتقل کرنا چاہتے تھے۔
ہیلم آپ کو اجازت دیتا ہے:
- تعیناتیوں کا انتظام، ترتیب اور نظر ثانی کا تصور متعارف کرایا؛
- کامیابی سے رول بیک کرنا؛
- مختلف واقعات کے لئے ہکس کا استعمال کریں؛
- اضافی درخواست کی جانچ پڑتال شامل کریں اور ان کے نتائج کا جواب دیں۔
اس کے علاوہ ہیلم میں "بیٹریاں" ہیں - بہت ساری لذیذ چیزیں جو آپ کی زندگی کو آسان بناتے ہوئے پلگ ان کی شکل میں شامل کی جا سکتی ہیں۔ پلگ انز کو آزادانہ طور پر لکھا جا سکتا ہے، وہ کافی الگ تھلگ ہیں اور ان کے لیے ہم آہنگ فن تعمیر کی ضرورت نہیں ہے۔ اگر آپ کسی چیز کو نافذ کرنا چاہتے ہیں، تو میں اسے بطور پلگ ان کرنے کی تجویز کرتا ہوں، اور پھر ممکنہ طور پر اسے اپ اسٹریم میں شامل کریں۔
ہیلم تین اہم تصورات پر مبنی ہے:
- چارٹ ریپو - آپ کے مینی فیسٹ کے لیے ممکنہ پیرامیٹرائزیشنز کی تفصیل اور صف۔
- تشکیل - یعنی وہ اقدار جو لاگو ہوں گی (متن، عددی قدریں، وغیرہ)۔
- رہائی دو اوپری اجزاء کو جمع کرتا ہے، اور ایک ساتھ وہ ریلیز میں بدل جاتے ہیں۔ ریلیز کو ورژن بنایا جا سکتا ہے، اس طرح ایک منظم لائف سائیکل حاصل ہوتا ہے: انسٹالیشن کے وقت چھوٹا اور اپ گریڈ، ڈاؤن گریڈ یا رول بیک کے وقت بڑا۔
ہیلم فن تعمیر
خاکہ تصوراتی طور پر ہیلم کے اعلیٰ سطحی فن تعمیر کو پیش کرتا ہے۔
میں آپ کو یاد دلاتا ہوں کہ ہیلم کوئیبرنیٹس سے متعلق ہے۔ لہذا، ہم ایک Kubernetes کلسٹر (مستطیل) کے بغیر نہیں کر سکتے ہیں. kube-apiserver جزو ماسٹر پر رہتا ہے۔ ہیلم کے بغیر ہمارے پاس Kubeconfig ہے۔ ہیلم ایک چھوٹی بائنری لاتا ہے، اگر آپ اسے کہہ سکتے ہیں تو، ہیلم سی ایل آئی یوٹیلیٹی، جو کمپیوٹر، لیپ ٹاپ، مین فریم - کسی بھی چیز پر انسٹال ہوتی ہے۔
لیکن یہ کافی نہیں ہے۔ ہیلم میں سرور کا ایک جزو ہے جسے ٹلر کہتے ہیں۔ یہ کلسٹر کے اندر ہیلم کے مفادات کی نمائندگی کرتا ہے؛ یہ کسی دوسرے کی طرح Kubernetes کلسٹر کے اندر ایک ایپلی کیشن ہے۔
چارٹ ریپو کا اگلا جزو چارٹس کے ساتھ ایک ذخیرہ ہے۔ ایک سرکاری ذخیرہ ہے، اور کسی کمپنی یا پروجیکٹ کا نجی ذخیرہ ہوسکتا ہے۔
انٹریکشن
آئیے دیکھتے ہیں کہ جب ہم ہیلم کا استعمال کرتے ہوئے ایک ایپلی کیشن انسٹال کرنا چاہتے ہیں تو فن تعمیر کے اجزاء آپس میں کیسے تعامل کرتے ہیں۔
- ہم بول رہے ہیں
Helm installریپوزٹری تک رسائی حاصل کریں (چارٹ ریپو) اور ہیلم چارٹ حاصل کریں۔
- ہیلم یوٹیلیٹی (Helm CLI) Kubeconfig کے ساتھ بات چیت کرتی ہے تاکہ یہ معلوم کیا جا سکے کہ کس کلسٹر سے رابطہ کرنا ہے۔
- یہ معلومات حاصل کرنے کے بعد، یوٹیلیٹی ٹیلر سے مراد ہے، جو ہمارے کلسٹر میں واقع ہے، بطور درخواست۔
- Tiller Kube-apiserver کو Kubernetes میں اعمال انجام دینے، کچھ اشیاء (سروسز، پوڈز، نقلیں، راز وغیرہ) بنانے کے لیے کال کرتا ہے۔
اس کے بعد، ہم اٹیک ویکٹر کو دیکھنے کے لیے خاکے کو پیچیدہ کریں گے جس سے مجموعی طور پر ہیلم کے پورے فن تعمیر کو سامنے لایا جا سکتا ہے۔ اور پھر ہم اس کی حفاظت کرنے کی کوشش کریں گے۔
حملہ ویکٹر
پہلا ممکنہ کمزور نقطہ ہے۔ مراعات یافتہ API-صارف. اسکیم کے حصے کے طور پر، یہ ایک ہیکر ہے جس نے ہیلم CLI تک ایڈمن تک رسائی حاصل کی ہے۔
غیر مراعات یافتہ API صارف اگر یہ کہیں آس پاس ہے تو خطرہ بھی بن سکتا ہے۔ ایسے صارف کا سیاق و سباق مختلف ہو گا، مثال کے طور پر، اسے Kubeconfig سیٹنگز میں ایک کلسٹر نام کی جگہ میں طے کیا جا سکتا ہے۔
سب سے دلچسپ حملہ ویکٹر ایک ایسا عمل ہو سکتا ہے جو ٹلر کے قریب کسی کلسٹر کے اندر رہتا ہو اور اس تک رسائی حاصل کر سکتا ہو۔ یہ ایک ویب سرور یا مائیکرو سروس ہو سکتا ہے جو کلسٹر کے نیٹ ورک ماحول کو دیکھتا ہے۔
ایک غیر ملکی، لیکن تیزی سے مقبول، اٹیک ویرینٹ میں چارٹ ریپو شامل ہے۔ ایک بے ضمیر مصنف کی طرف سے بنایا گیا چارٹ غیر محفوظ وسائل پر مشتمل ہو سکتا ہے، اور آپ اسے ایمان پر لے کر مکمل کریں گے۔ یا یہ اس چارٹ کی جگہ لے سکتا ہے جسے آپ آفیشل ریپوزٹری سے ڈاؤن لوڈ کرتے ہیں اور مثال کے طور پر، پالیسیوں کی شکل میں ایک وسیلہ بنا سکتے ہیں اور اس تک رسائی کو بڑھا سکتے ہیں۔
آئیے ان چاروں اطراف سے حملوں کو روکنے کی کوشش کریں اور یہ معلوم کریں کہ ہیلم کے فن تعمیر میں کہاں مسائل ہیں، اور کہاں، شاید، کوئی نہیں ہے۔
آئیے ڈایاگرام کو بڑا کریں، مزید عناصر شامل کریں، لیکن تمام بنیادی اجزاء کو رکھیں۔
ہیلم CLI چارٹ ریپو کے ساتھ بات چیت کرتا ہے، Kubeconfig کے ساتھ بات چیت کرتا ہے، اور کام کو کلسٹر میں Tiller کے جزو میں منتقل کر دیا جاتا ہے۔
ٹلر کی نمائندگی دو اشیاء سے ہوتی ہے:
- Tiller-deploy svc، جو ایک مخصوص سروس کو ظاہر کرتا ہے؛
- Tiller-deploy pod (ایک نقل میں ایک ہی کاپی میں ڈایاگرام میں)، جس پر پورا بوجھ چلتا ہے، جو کلسٹر تک رسائی حاصل کرتا ہے۔
بات چیت کے لیے مختلف پروٹوکول اور اسکیمیں استعمال کی جاتی ہیں۔ سیکورٹی کے نقطہ نظر سے، ہم سب سے زیادہ دلچسپی رکھتے ہیں:
- وہ طریقہ کار جس کے ذریعے ہیلم CLI چارٹ ریپو تک رسائی حاصل کرتا ہے: کیا پروٹوکول، کیا تصدیق ہے اور اس کے ساتھ کیا کیا جا سکتا ہے۔
- پروٹوکول جس کے ذریعے ہیلم CLI، کیوبیکٹل کا استعمال کرتے ہوئے، ٹلر کے ساتھ بات چیت کرتا ہے۔ یہ کلسٹر کے اندر نصب ایک RPC سرور ہے۔
- Tiller بذات خود مائیکرو سروسز کے لیے قابل رسائی ہے جو کلسٹر میں رہتی ہیں اور Kube-apiserver کے ساتھ تعامل کرتی ہیں۔
آئیے ترتیب سے ان تمام شعبوں پر بات کریں۔
آر بی اے سی۔
ہیلم یا کلسٹر کے اندر کسی دوسری سروس کے بارے میں بات کرنے کا کوئی فائدہ نہیں ہے جب تک کہ RBAC فعال نہ ہو۔
ایسا لگتا ہے کہ یہ تازہ ترین سفارش نہیں ہے، لیکن مجھے یقین ہے کہ بہت سے لوگوں نے اب بھی پروڈکشن میں بھی RBAC کو فعال نہیں کیا ہے، کیونکہ یہ بہت ہنگامہ خیز ہے اور بہت سی چیزوں کو ترتیب دینے کی ضرورت ہے۔ تاہم، میں آپ کو ایسا کرنے کی ترغیب دیتا ہوں۔
- ویب سائٹ کے وکیل برائے RBAC۔ اس میں بہت زیادہ دلچسپ مواد موجود ہے جو آپ کو RBAC ترتیب دینے میں مدد کرے گا، یہ بتائے گا کہ یہ کیوں اچھا ہے اور بنیادی طور پر پیداوار میں اس کے ساتھ کیسے رہنا ہے۔
میں یہ بتانے کی کوشش کروں گا کہ Tiller اور RBAC کیسے کام کرتے ہیں۔ ٹلر ایک مخصوص سروس اکاؤنٹ کے تحت کلسٹر کے اندر کام کرتا ہے۔ عام طور پر، اگر RBAC کو کنفیگر نہیں کیا گیا ہے، تو یہ سپر یوزر ہوگا۔ بنیادی ترتیب میں، Tiller ایک منتظم ہوگا۔ یہی وجہ ہے کہ اکثر یہ کہا جاتا ہے کہ ٹلر آپ کے کلسٹر کے لیے ایک SSH سرنگ ہے۔ درحقیقت، یہ سچ ہے، اس لیے آپ اوپر دیے گئے خاکے میں ڈیفالٹ سروس اکاؤنٹ کے بجائے ایک علیحدہ وقف سروس اکاؤنٹ استعمال کر سکتے ہیں۔
جب آپ ہیلم کو شروع کرتے ہیں اور اسے پہلی بار سرور پر انسٹال کرتے ہیں، تو آپ سروس اکاؤنٹ استعمال کرکے سیٹ کر سکتے ہیں۔ --service-account. یہ آپ کو حقوق کے کم از کم مطلوبہ سیٹ کے ساتھ صارف کو استعمال کرنے کی اجازت دے گا۔ یہ سچ ہے کہ آپ کو ایسا "مالا" بنانا پڑے گا: رول اور رول بائنڈنگ۔
بدقسمتی سے، ہیلم آپ کے لیے ایسا نہیں کرے گا۔ آپ یا آپ کے Kubernetes کلسٹر ایڈمنسٹریٹر کو ہیلم پاس کرنے کے لیے پہلے سے سروس اکاؤنٹ کے لیے رولز اور رول بائنڈنگز کا ایک سیٹ تیار کرنا ہوگا۔
سوال پیدا ہوتا ہے - رول اور کلسٹر رول میں کیا فرق ہے؟ فرق یہ ہے کہ ClusterRole تمام نام کی جگہوں کے لیے کام کرتا ہے، باقاعدہ Roles اور RoleBindings کے برعکس، جو صرف ایک مخصوص نام کی جگہ کے لیے کام کرتا ہے۔ آپ پورے کلسٹر اور تمام نام کی جگہوں کے لیے پالیسیاں ترتیب دے سکتے ہیں، یا ہر نام کی جگہ کے لیے انفرادی طور پر ذاتی بنا سکتے ہیں۔
یہ بات قابل ذکر ہے کہ RBAC ایک اور بڑا مسئلہ حل کرتا ہے۔ بہت سے لوگ شکایت کرتے ہیں کہ ہیلم، بدقسمتی سے، ملٹی ٹیننسی نہیں ہے (ملٹی ٹیننسی کی حمایت نہیں کرتا)۔ اگر کئی ٹیمیں ایک کلسٹر کا استعمال کرتی ہیں اور ہیلم کا استعمال کرتی ہیں، تو بنیادی طور پر اس کلسٹر کے اندر پالیسیاں ترتیب دینا اور ان کی رسائی کو محدود کرنا ناممکن ہے، کیونکہ ایک مخصوص سروس اکاؤنٹ ہے جس کے تحت ہیلم چلتا ہے، اور یہ کلسٹر کے تمام وسائل اپنے نیچے سے بناتا ہے۔ ، جو کبھی کبھی بہت تکلیف دہ ہوتا ہے۔ یہ سچ ہے - بائنری فائل کی طرح، عمل کی طرح، ہیلم ٹلر کے پاس ملٹی ٹیننسی کا کوئی تصور نہیں ہے۔.
تاہم، ایک بہت اچھا طریقہ ہے جو آپ کو ایک کلسٹر میں کئی بار ٹلر چلانے کی اجازت دیتا ہے۔ اس میں کوئی حرج نہیں ہے، ٹلر کو ہر نام کی جگہ پر لانچ کیا جا سکتا ہے۔ اس طرح، آپ RBAC، Kubeconfig کو ایک سیاق و سباق کے طور پر استعمال کر سکتے ہیں، اور ایک خصوصی ہیلم تک رسائی کو محدود کر سکتے ہیں۔
یہ اس طرح نظر آئے گا۔
مثال کے طور پر، مختلف ٹیموں (دو نام کی جگہوں) کے سیاق و سباق کے ساتھ دو Kubeconfigs ہیں: ترقیاتی ٹیم کے لیے X ٹیم اور ایڈمن کلسٹر۔ ایڈمن کلسٹر کا اپنا وسیع ٹِلر ہے، جو کیوب سسٹم کے نام کی جگہ میں واقع ہے، جو کہ اسی طرح ایک جدید سروس اکاؤنٹ ہے۔ اور ڈویلپمنٹ ٹیم کے لیے ایک علیحدہ نام کی جگہ، وہ اپنی خدمات کو ایک خاص نام کی جگہ پر تعینات کر سکیں گے۔
یہ ایک قابل عمل نقطہ نظر ہے، ٹلر اتنا طاقت کا بھوکا نہیں ہے کہ یہ آپ کے بجٹ کو بہت متاثر کرے۔ یہ فوری حل میں سے ایک ہے۔
Tiller کو الگ سے کنفیگر کرنے کے لیے آزاد محسوس کریں اور ٹیم کے لیے، مخصوص ڈویلپر کے لیے یا ماحول کے لیے Kubeconfig کو سیاق و سباق فراہم کریں: Dev، Staging، Production (یہ شک ہے کہ سب کچھ ایک ہی کلسٹر پر ہوگا، تاہم، ایسا کیا جا سکتا ہے)۔
اپنی کہانی کو جاری رکھتے ہوئے، آئیے RBAC سے سوئچ کریں اور ConfigMaps کے بارے میں بات کریں۔
کنفیگ میپس
ہیلم اپنے ڈیٹا اسٹور کے طور پر ConfigMaps کو استعمال کرتا ہے۔ جب ہم نے فن تعمیر کے بارے میں بات کی تو کہیں بھی کوئی ڈیٹا بیس نہیں تھا جو ریلیز، کنفیگریشن، رول بیکس وغیرہ کے بارے میں معلومات کو محفوظ کرتا۔ اس کے لیے ConfigMaps استعمال کیا جاتا ہے۔
ConfigMaps کے ساتھ بنیادی مسئلہ معلوم ہے - وہ اصولی طور پر غیر محفوظ ہیں۔ حساس ڈیٹا کو ذخیرہ کرنا ناممکن ہے۔. ہم ہر چیز کے بارے میں بات کر رہے ہیں جو سروس سے آگے نہیں بڑھنا چاہئے، مثال کے طور پر، پاس ورڈ. ہیلم کے لیے اس وقت سب سے مقامی طریقہ یہ ہے کہ ConfigMaps کو استعمال کرنے سے راز میں تبدیل کیا جائے۔
یہ بہت سادگی سے کیا جاتا ہے۔ Tiller کی ترتیب کو اوور رائیڈ کریں اور بتا دیں کہ سٹوریج راز ہو گا۔ پھر ہر تعیناتی کے لیے آپ کو ConfigMap نہیں بلکہ ایک راز ملے گا۔
آپ بحث کر سکتے ہیں کہ راز بذات خود ایک عجیب تصور ہیں اور زیادہ محفوظ نہیں ہیں۔ تاہم، یہ سمجھنے کے قابل ہے کہ Kubernetes کے ڈویلپرز خود یہ کام کر رہے ہیں۔ ورژن 1.10 سے شروع ہو رہا ہے، یعنی اب کافی عرصے سے، کم از کم عوامی بادلوں میں، رازوں کو ذخیرہ کرنے کے لیے صحیح اسٹوریج کو جوڑنا ممکن ہوا ہے۔ ٹیم اب رازوں، انفرادی پوڈز، یا دیگر اداروں تک رسائی کو بہتر طریقے سے تقسیم کرنے کے طریقوں پر کام کر رہی ہے۔
اسٹوریج ہیلم کو رازوں میں منتقل کرنا بہتر ہے، اور وہ، بدلے میں، مرکزی طور پر محفوظ ہیں.
یقیناً رہے گا۔ ڈیٹا اسٹوریج کی حد 1 MB ہے۔. ہیلم یہاں وغیرہ ڈی کو ConfigMaps کے لیے تقسیم شدہ اسٹوریج کے طور پر استعمال کرتا ہے۔ اور وہاں انہوں نے غور کیا کہ یہ نقل تیار کرنے کے لیے موزوں ڈیٹا کا حصہ ہے۔ Reddit پر اس کے بارے میں ایک دلچسپ بحث ہے، میں ہفتے کے آخر میں اس مضحکہ خیز پڑھنے یا اقتباس کو پڑھنے کا مشورہ دیتا ہوں .
چارٹ ریپوز
چارٹس سماجی طور پر سب سے زیادہ کمزور ہوتے ہیں اور "Man in the Middle" کا ذریعہ بن سکتے ہیں، خاص طور پر اگر آپ اسٹاک سلوشن استعمال کرتے ہیں۔ سب سے پہلے، ہم ان ذخیروں کے بارے میں بات کر رہے ہیں جو HTTP کے ذریعے سامنے آتی ہیں۔
آپ کو یقینی طور پر ہیلم ریپو کو HTTPS پر بے نقاب کرنے کی ضرورت ہے - یہ بہترین آپشن ہے اور سستا ہے۔
پر دھیان دیں چارٹ کے دستخط کا طریقہ کار. ٹیکنالوجی جہنم کی طرح آسان ہے۔ یہ وہی چیز ہے جسے آپ GitHub پر استعمال کرتے ہیں، ایک باقاعدہ PGP مشین جس میں عوامی اور نجی کلیدیں ہیں۔ سیٹ اپ کریں اور یقینی بنائیں، ضروری چابیاں ہوں اور ہر چیز پر دستخط کریں، کہ یہ واقعی آپ کا چارٹ ہے۔
اس کے علاوہ، ہیلم کلائنٹ TLS کو سپورٹ کرتا ہے۔ (سرور سائیڈ HTTP معنوں میں نہیں، بلکہ باہمی TLS)۔ آپ بات چیت کرنے کے لیے سرور اور کلائنٹ کیز استعمال کر سکتے ہیں۔ سچ پوچھیں تو، میں ایسا طریقہ کار استعمال نہیں کرتا کیونکہ مجھے باہمی سرٹیفکیٹ پسند نہیں ہیں۔ بنیادی طور پر، - Helm 2 کے لیے Helm Repo ترتیب دینے کا اہم ٹول - بنیادی توثیق کو بھی سپورٹ کرتا ہے۔ اگر یہ زیادہ آسان اور پرسکون ہو تو آپ بنیادی سند استعمال کر سکتے ہیں۔
ایک پلگ ان بھی ہے۔ ، جو آپ کو گوگل کلاؤڈ اسٹوریج پر چارٹ ریپوز کی میزبانی کرنے کی اجازت دیتا ہے۔ یہ کافی آسان ہے، بہت اچھا کام کرتا ہے اور کافی محفوظ ہے، کیونکہ تمام بیان کردہ میکانزم کو ری سائیکل کیا جاتا ہے۔
اگر آپ HTTPS یا TLS کو فعال کرتے ہیں، mTLS استعمال کرتے ہیں، اور خطرات کو مزید کم کرنے کے لیے بنیادی تصدیق کو فعال کرتے ہیں، تو آپ کو ہیلم CLI اور چارٹ ریپو کے ساتھ ایک محفوظ مواصلاتی چینل ملے گا۔
gRPC API
اگلا مرحلہ بہت اہم ہے - ٹلر کو محفوظ کرنے کے لیے، جو کہ کلسٹر میں واقع ہے اور ایک طرف، ایک سرور ہے، دوسری طرف، یہ خود دوسرے اجزاء تک رسائی حاصل کرتا ہے اور کسی کے ہونے کا بہانہ کرنے کی کوشش کرتا ہے۔
جیسا کہ میں پہلے ہی کہہ چکا ہوں، ٹلر ایک ایسی خدمت ہے جو gRPC کو بے نقاب کرتی ہے، ہیلم کلائنٹ اس کے پاس gRPC کے ذریعے آتا ہے۔ پہلے سے طے شدہ طور پر، یقیناً، TLS غیر فعال ہے۔ ایسا کیوں کیا گیا یہ ایک قابل بحث سوال ہے، ایسا لگتا ہے کہ مجھے شروع میں سیٹ اپ کو آسان بنانا ہے۔
پروڈکشن اور یہاں تک کہ سٹیجنگ کے لیے، میں gRPC پر TLS کو فعال کرنے کی تجویز کرتا ہوں۔
میری رائے میں، چارٹس کے لیے mTLS کے برعکس، یہ یہاں مناسب ہے اور بہت سادگی سے کیا جاتا ہے - ایک PQI انفراسٹرکچر تیار کریں، ایک سرٹیفکیٹ بنائیں، Tiller لانچ کریں، ابتدا کے دوران سرٹیفکیٹ منتقل کریں۔ اس کے بعد، آپ اپنے آپ کو تیار کردہ سرٹیفکیٹ اور پرائیویٹ کلید کے ساتھ پیش کرتے ہوئے تمام ہیلم کمانڈز پر عمل درآمد کر سکتے ہیں۔
اس طرح آپ اپنے آپ کو کلسٹر کے باہر سے ٹلر کی تمام درخواستوں سے محفوظ رکھیں گے۔
لہذا، ہم نے ٹلر سے کنکشن چینل کو محفوظ کر لیا ہے، ہم نے پہلے ہی RBAC پر تبادلہ خیال کیا ہے اور Kubernetes apiserver کے حقوق کو ایڈجسٹ کیا ہے، اس ڈومین کو کم کر دیا ہے جس کے ساتھ یہ بات چیت کر سکتا ہے۔
ہیلم کی حفاظت کی۔
آئیے آخری خاکہ دیکھتے ہیں۔ یہ ایک ہی تیروں کے ساتھ ایک ہی فن تعمیر ہے۔
تمام کنکشن اب محفوظ طریقے سے سبز رنگ میں کھینچے جا سکتے ہیں:
- چارٹ ریپو کے لیے ہم TLS یا mTLS اور بنیادی تصدیق کا استعمال کرتے ہیں۔
- ٹلر کے لیے mTLS، اور یہ TLS کے ساتھ ایک gRPC سروس کے طور پر سامنے آیا ہے، ہم سرٹیفکیٹ استعمال کرتے ہیں۔
- کلسٹر رول اور رول بائنڈنگ کے ساتھ ایک خصوصی سروس اکاؤنٹ استعمال کرتا ہے۔
ہم نے کلسٹر کو نمایاں طور پر محفوظ کر لیا ہے، لیکن کسی ہوشیار نے کہا:
"صرف ایک ہی مکمل طور پر محفوظ حل ہو سکتا ہے - ایک سوئچ آف کمپیوٹر، جو کنکریٹ کے ڈبے میں ہوتا ہے اور اس کی حفاظت سپاہی کرتے ہیں۔"
ڈیٹا میں ہیرا پھیری کرنے اور نئے حملہ کرنے والے ویکٹر تلاش کرنے کے مختلف طریقے ہیں۔ تاہم، مجھے یقین ہے کہ یہ سفارشات حفاظت کے لیے صنعت کا ایک بنیادی معیار حاصل کریں گی۔
بونس
یہ حصہ سیکورٹی سے براہ راست متعلق نہیں ہے، لیکن یہ بھی مفید ہو گا. میں آپ کو کچھ دلچسپ چیزیں دکھاتا ہوں جن کے بارے میں بہت کم لوگ جانتے ہیں۔ مثال کے طور پر، چارٹس کو کیسے تلاش کیا جائے - سرکاری اور غیر سرکاری۔
مخزن میں اب تقریباً 300 چارٹ اور دو سلسلے ہیں: مستحکم اور انکیوبیٹر۔ جو بھی حصہ ڈالتا ہے وہ بخوبی جانتا ہے کہ انکیوبیٹر سے اسٹیبل تک جانا کتنا مشکل ہے، اور اسٹیبل سے باہر اڑنا کتنا آسان ہے۔ تاہم، یہ پرومیتھیس کے لیے چارٹس تلاش کرنے کا بہترین ٹول نہیں ہے اور جو کچھ بھی آپ کو پسند ہے، ایک سادہ سی وجہ سے - یہ کوئی ایسا پورٹل نہیں ہے جہاں آپ آسانی سے پیکجز تلاش کر سکیں۔
لیکن ایک خدمت ہے۔ ، جس سے چارٹ تلاش کرنا زیادہ آسان ہوجاتا ہے۔ سب سے اہم بات یہ ہے کہ بہت سے بیرونی ذخیرے اور تقریباً 800 دلکش دستیاب ہیں۔ اس کے علاوہ، اگر آپ کسی وجہ سے اپنے چارٹس کو مستحکم پر نہیں بھیجنا چاہتے ہیں تو آپ اپنے ذخیرے کو جوڑ سکتے ہیں۔
hub.helm.sh کو آزمائیں اور آئیے مل کر اسے تیار کریں۔ یہ سروس ہیلم پروجیکٹ کے تحت ہے، اور آپ اس کے UI میں بھی حصہ ڈال سکتے ہیں اگر آپ فرنٹ اینڈ ڈویلپر ہیں اور صرف ظاہری شکل کو بہتر بنانا چاہتے ہیں۔
میں آپ کی توجہ اس طرف بھی مبذول کرانا چاہوں گا۔ اوپن سروس بروکر API انضمام. یہ بوجھل اور غیر واضح لگتا ہے، لیکن یہ ان مسائل کو حل کرتا ہے جن کا سب کو سامنا ہے۔ ایک سادہ سی مثال سے سمجھاتا ہوں۔
ایک Kubernetes کلسٹر ہے جس میں ہم ایک کلاسک ایپلی کیشن - ورڈپریس چلانا چاہتے ہیں۔ عام طور پر، مکمل فعالیت کے لیے ڈیٹا بیس کی ضرورت ہوتی ہے۔ بہت سے مختلف حل ہیں، مثال کے طور پر، آپ اپنی سٹیٹ فل سروس شروع کر سکتے ہیں۔ یہ بہت آسان نہیں ہے، لیکن بہت سے لوگ کرتے ہیں.
دوسرے، ہمارے جیسے Chainstack پر، اپنے سرورز کے لیے MySQL یا PostgreSQL جیسے منظم ڈیٹا بیس استعمال کرتے ہیں۔ اس لیے ہمارے ڈیٹا بیس بادل میں کہیں موجود ہیں۔
لیکن ایک مسئلہ پیدا ہوتا ہے: ہمیں اپنی سروس کو ڈیٹا بیس سے جوڑنے، ڈیٹا بیس کا ذائقہ بنانے، اسناد کو منتقل کرنے اور کسی نہ کسی طرح اس کا انتظام کرنے کی ضرورت ہے۔ یہ سب عام طور پر سسٹم ایڈمنسٹریٹر یا ڈویلپر کے ذریعہ دستی طور پر کیا جاتا ہے۔ اور جب کم ایپلی کیشنز ہوں تو کوئی حرج نہیں ہے۔ جب ان میں سے بہت سارے ہوتے ہیں تو آپ کو ایک کمبائن کی ضرورت ہوتی ہے۔ اس طرح کا ایک فصل کاٹنے والا ہے - یہ سروس بروکر ہے۔ یہ آپ کو عوامی کلاؤڈ کلسٹر کے لیے ایک خصوصی پلگ ان استعمال کرنے اور بروکر کے ذریعے فراہم کنندہ سے وسائل آرڈر کرنے کی اجازت دیتا ہے، گویا یہ ایک API ہے۔ ایسا کرنے کے لیے، آپ مقامی Kubernetes ٹولز استعمال کر سکتے ہیں۔
یہ بہت آسان ہے۔ آپ استفسار کر سکتے ہیں، مثال کے طور پر، Azure میں مینیجڈ MySQL کو بیس ٹائر کے ساتھ (اسے کنفیگر کیا جا سکتا ہے)۔ Azure API کا استعمال کرتے ہوئے، ڈیٹا بیس بنایا جائے گا اور استعمال کے لیے تیار کیا جائے گا۔ آپ کو اس میں مداخلت کرنے کی ضرورت نہیں ہے، پلگ ان اس کے لیے ذمہ دار ہے۔ مثال کے طور پر، OSBA (Azure پلگ ان) سروس کو اسناد واپس کرے گا اور اسے ہیلم کو دے گا۔ آپ کلاؤڈ مائی ایس کیو ایل کے ساتھ ورڈپریس استعمال کرنے کے قابل ہو جائیں گے، منظم ڈیٹا بیس کے ساتھ بالکل بھی ڈیل نہیں کریں گے اور اندر کی اسٹیٹ فل سروسز کی فکر نہیں کریں گے۔
ہم کہہ سکتے ہیں کہ ہیلم ایک گلو کے طور پر کام کرتا ہے جو کہ ایک طرف آپ کو خدمات کی تعیناتی کی اجازت دیتا ہے اور دوسری طرف کلاؤڈ فراہم کرنے والوں کے وسائل کو استعمال کرتا ہے۔
آپ اپنا پلگ ان لکھ سکتے ہیں اور اس پوری کہانی کو بنیاد پر استعمال کر سکتے ہیں۔ تب آپ کے پاس کارپوریٹ کلاؤڈ فراہم کنندہ کے لیے اپنا پلگ ان ہوگا۔ میں اس نقطہ نظر کو آزمانے کی سفارش کرتا ہوں، خاص طور پر اگر آپ کے پاس بڑا پیمانہ ہے اور آپ کسی خصوصیت کے لیے ڈیو، سٹیجنگ، یا پورے انفراسٹرکچر کو تیزی سے تعینات کرنا چاہتے ہیں۔ یہ آپ کے آپریشنز یا DevOps کے لیے زندگی کو آسان بنا دے گا۔
ایک اور تلاش جس کا میں نے پہلے ہی ذکر کیا ہے۔ ہیلم-جی سی ایس پلگ ان، جو آپ کو ہیلم چارٹس کو ذخیرہ کرنے کے لیے گوگل-بکیٹس (آبجیکٹ اسٹوریج) استعمال کرنے کی اجازت دیتا ہے۔
اس کا استعمال شروع کرنے کے لیے آپ کو صرف چار کمانڈز کی ضرورت ہے:
- پلگ ان انسٹال کریں؛
- اسے شروع کریں؛
- بالٹی کا راستہ طے کریں، جو gcp میں واقع ہے؛
- معیاری طریقے سے چارٹ شائع کریں۔
خوبصورتی یہ ہے کہ اجازت کے لیے مقامی gcp طریقہ استعمال کیا جائے گا۔ آپ سروس اکاؤنٹ، ڈویلپر اکاؤنٹ، جو چاہیں استعمال کر سکتے ہیں۔ یہ بہت آسان ہے اور اسے چلانے کے لیے کچھ بھی خرچ نہیں ہوتا۔ اگر آپ، میری طرح، آپس لیس فلسفے کو فروغ دیتے ہیں، تو یہ بہت آسان ہوگا، خاص طور پر چھوٹی ٹیموں کے لیے۔
متبادل
ہیلم سروس مینجمنٹ کا واحد حل نہیں ہے۔ اس کے بارے میں بہت سارے سوالات ہیں، شاید یہی وجہ ہے کہ تیسرا ورژن اتنی جلدی شائع ہوا۔ یقیناً متبادل موجود ہیں۔
یہ خصوصی حل ہو سکتے ہیں، مثال کے طور پر، Ksonnet یا Metaparticle۔ آپ اپنے کلاسک انفراسٹرکچر مینجمنٹ ٹولز (Ansible، Terraform، Chef، وغیرہ) کو انہی مقاصد کے لیے استعمال کر سکتے ہیں جن کے بارے میں میں نے بات کی ہے۔
آخر میں ایک حل ہے جس کی مقبولیت بڑھ رہی ہے۔
آپریٹر فریم ورک پر غور کرنے کے لیے سب سے اوپر ہیلم متبادل ہے۔
یہ CNCF اور Kubernetes سے زیادہ مقامی ہے، لیکن داخلے میں رکاوٹ بہت زیادہ ہے۔، آپ کو زیادہ پروگرام کرنے کی ضرورت ہے اور ظاہر کو کم بیان کرنا ہوگا۔
مختلف ایڈونز ہیں، جیسے ڈرافٹ، سکافولڈ۔ وہ زندگی کو بہت آسان بنا دیتے ہیں، مثال کے طور پر، وہ ڈیولپرز کے لیے آزمائشی ماحول کو تعینات کرنے کے لیے ہیلم بھیجنے اور لانچ کرنے کے چکر کو آسان بناتے ہیں۔ میں انہیں بااختیار کہوں گا۔
یہاں ایک بصری چارٹ ہے جہاں سب کچھ ہے۔
x-axis پر جو کچھ ہو رہا ہے اس پر آپ کے ذاتی کنٹرول کی سطح ہے، y-axis پر Kubernetes کی اصلیت کی سطح ہے۔ ہیلم ورژن 2 درمیان میں کہیں آتا ہے۔ ورژن 3 میں، بہت زیادہ نہیں، لیکن کنٹرول اور مقامیت کی سطح دونوں کو بہتر بنایا گیا ہے۔ Ksonnet کی سطح پر حل اب بھی ہیلم 2 سے کمتر ہیں۔ تاہم، یہ جاننے کے لیے کہ اس دنیا میں اور کیا ہے، ان کو دیکھنے کے قابل ہے۔ بلاشبہ، آپ کا کنفیگریشن مینیجر آپ کے کنٹرول میں ہو گا، لیکن یہ بلکل کوبرنیٹس کا مقامی نہیں ہے۔
آپریٹر فریم ورک مکمل طور پر Kubernetes کا ہے اور آپ کو اس کا انتظام زیادہ خوبصورتی اور احتیاط سے کرنے کی اجازت دیتا ہے (لیکن داخلے کی سطح کے بارے میں یاد رکھیں)۔ بلکہ، یہ ہیلم کا استعمال کرتے ہوئے بڑی تعداد میں ایپلی کیشنز کو پیک کرنے کے لیے ماس ہارویسٹر کے بجائے ایک خصوصی ایپلی کیشن اور اس کے لیے انتظام کی تخلیق کے لیے موزوں ہے۔
ایکسٹینڈر بس کنٹرول کو تھوڑا بہتر بناتے ہیں، ورک فلو کو پورا کرتے ہیں، یا CI/CD پائپ لائنوں پر کونے کونے کاٹتے ہیں۔
ہیلم کا مستقبل
اچھی خبر یہ ہے کہ Helm 3 آ رہا ہے۔ Helm 3.0.0-alpha.2 کا الفا ورژن پہلے ہی ریلیز ہو چکا ہے، آپ اسے آزما سکتے ہیں۔ یہ کافی مستحکم ہے، لیکن فعالیت اب بھی محدود ہے۔
آپ کو ہیلم 3 کی ضرورت کیوں ہے؟ سب سے پہلے، یہ ایک کہانی ہے ٹلر کی گمشدگی، ایک جزو کے طور پر۔ یہ، جیسا کہ آپ پہلے ہی سمجھ چکے ہیں، ایک بہت بڑا قدم ہے، کیونکہ فن تعمیر کی حفاظت کے نقطہ نظر سے، ہر چیز کو آسان بنایا گیا ہے۔
جب ہیلم 2 بنایا گیا تھا، جو کہ کبرنیٹس 1.8 یا اس سے بھی پہلے کے زمانے میں تھا، بہت سے تصورات ناپختہ تھے۔ مثال کے طور پر، CRD کا تصور اب فعال طور پر نافذ کیا جا رہا ہے، اور ہیلم کرے گا۔ CRD استعمال کریں۔ڈھانچے کو ذخیرہ کرنے کے لئے. صرف کلائنٹ کو استعمال کرنا ممکن ہو گا اور سرور کے حصے کو برقرار نہیں رکھا جائے گا۔ اس کے مطابق، ڈھانچے اور وسائل کے ساتھ کام کرنے کے لیے مقامی Kubernetes کمانڈ استعمال کریں۔ یہ ایک بہت بڑا قدم ہے۔
پیش ہوں گے مقامی OCI ذخیروں کے لیے سپورٹ (اوپن کنٹینر انیشی ایٹو)۔ یہ ایک بہت بڑا اقدام ہے، اور ہیلم بنیادی طور پر اپنے چارٹ پوسٹ کرنے میں دلچسپی رکھتا ہے۔ بات یہاں تک آتی ہے کہ، مثال کے طور پر، Docker Hub بہت سے OCI معیارات کی حمایت کرتا ہے۔ میں اندازہ نہیں لگا رہا ہوں، لیکن شاید کلاسک ڈوکر ریپوزٹری فراہم کرنے والے آپ کو اپنے ہیلم چارٹس کی میزبانی کرنے کا موقع دینا شروع کر دیں گے۔
میرے لیے متنازعہ کہانی ہے۔ لوا سپورٹاسکرپٹ لکھنے کے لیے ایک ٹیمپلیٹنگ انجن کے طور پر۔ میں Lua کا بڑا پرستار نہیں ہوں، لیکن یہ مکمل طور پر اختیاری خصوصیت ہوگی۔ میں نے اسے 3 بار چیک کیا - Lua کا استعمال ضروری نہیں ہوگا۔ لہٰذا، جو لوگ Lua استعمال کرنے کے قابل ہونا چاہتے ہیں، وہ لوگ جو گو کو پسند کرتے ہیں، ہمارے بہت بڑے کیمپ میں شامل ہوں اور اس کے لیے go-tmpl کا استعمال کریں۔
آخر میں، جو میں یقینی طور پر غائب تھا اسکیما کا ظہور اور ڈیٹا کی قسم کی توثیق. int یا سٹرنگ کے ساتھ مزید مسائل نہیں ہوں گے، صفر کو ڈبل کوٹس میں لپیٹنے کی ضرورت نہیں ہے۔ ایک JSONS اسکیما ظاہر ہوگا جو آپ کو قدروں کے لیے اسے واضح طور پر بیان کرنے کی اجازت دے گا۔
بھاری بھرکم دوبارہ کام کیا جائے گا۔ واقعہ پر مبنی ماڈل. یہ پہلے ہی تصوراتی طور پر بیان کیا جا چکا ہے۔ ہیلم 3 برانچ کو دیکھیں، اور آپ دیکھیں گے کہ کتنے واقعات اور ہکس اور دیگر چیزیں شامل کی گئی ہیں، جو بہت آسان ہو جائیں گی اور دوسری طرف، ان پر تعیناتی کے عمل اور ردعمل پر کنٹرول شامل کریں گی۔
ہیلم 3 آسان، محفوظ، اور زیادہ پرلطف ہو گا، اس لیے نہیں کہ ہم ہیلم 2 کو پسند نہیں کرتے، بلکہ اس لیے کہ Kubernetes زیادہ ترقی یافتہ ہوتا جا رہا ہے۔ اس کے مطابق، ہیلم Kubernetes کی ترقی کو استعمال کر سکتا ہے اور اس پر Kubernetes کے لیے بہترین مینیجر بنا سکتا ہے۔
ایک اور اچھی خبر یہ ہے۔ الیگزینڈر خیروف آپ کو بتائے گا، ہم آپ کو یاد دلاتے ہیں کہ ترقی، جانچ اور آپریشن کے عمل کے انضمام پر کانفرنس ماسکو میں منعقد کی جائے گی۔ 30 ستمبر اور 1 اکتوبر. آپ اب بھی 20 اگست تک کر سکتے ہیں۔ اور حل کے ساتھ اپنے تجربے کے بارے میں ہمیں بتائیں DevOps نقطہ نظر کے کام۔
کانفرنس چوکیوں اور خبروں پر عمل کریں۔ и .
ماخذ: www.habr.com