CKS کا دائرہ کار، ڈومینز اور لیب ورک لوڈ

دباؤ کے عالم میں ثبوت تیار کرنا

CKS کا کوئی ٹاسک تب مکمل سمجھا جاتا ہے جب مطلوبہ سیکیورٹی حالت (security state) موجود ہو اور آپ کے پاس اس بات کا ثبوت ہو کہ متعلقہ Kubernetes کنٹرول اسے نافذ کر رہا ہے۔ کسی کمانڈ کو زبانی یاد کر کے شاید تیزی سے کوئی آبجیکٹ (object) تو بنایا جا سکتا ہے، لیکن اس سے یہ ثابت نہیں ہوتا کہ ورک لوڈ (workload) کا انتخاب کسی پالیسی کے تحت کیا گیا ہے، یا یہ کہ کسی شناخت (identity) کے پاس صرف مطلوبہ API اجازتیں ہیں، یا یہ کہ کوئی ڈیٹیکشن رول (detection rule) متوقع رن ٹائم رویے کی نگرانی کر رہا ہے۔ کنفیگریشن تبدیل کرنے سے پہلے ٹارگٹ ریسورس، سیکیورٹی باؤنڈری، اور تصدیق کے لیے درکار سگنل سے متعلق تقاضوں کو اچھی طرح پڑھ لیں۔

وقت کی کمی یا دباؤ کے دوران، چھوٹے اور آسانی سے جانچے جانے کے قابل آرٹیفیکٹس (artifacts) تیار کریں۔ ان میں عام طور پر ایک مینیفسٹ (manifest) شامل ہوتا ہے جو مطلوبہ حالت کا اعلان کرتا ہے، ایک محدود دائرہ کار والی کمانڈ جو اسے لاگو یا جانچتی ہے، اور تبدیلی کے بعد آبجیکٹ یا رویے کو ظاہر کرنے والی آؤٹ پٹ۔ مینیفسٹ اس کنفیگریشن کو ثابت کرتا ہے جو Kubernetes API کو جمع کرائی گئی ہے۔ کمانڈ کی آؤٹ پٹ صرف اس لمحے، منتخب کلسٹر اور نیم اسپیس (namespace) کے اندر ریسورس کی حالت یا ردعمل کو ثابت کرتی ہے۔ ان میں سے کوئی بھی اکیلے یہ ثابت نہیں کرتا کہ ہر راستہ محفوظ ہے۔

ایک ایسے عمل (لوپ) کا استعمال کریں جسے دہرایا جا سکے۔ سب سے پہلے، فعال کلسٹر کے سیاق و سباق (context) اور ٹارگٹ نیم اسپیس کی شناخت کریں۔ اس کے بعد، موجودہ آبجیکٹس اور لیبلز کا جائزہ لیں جو پالیسی کے انتخاب یا اجازت کے دائرہ کار (authorization scope) کا تعین کرتے ہیں۔ بیان کردہ شرط کو پورا کرنے کے لیے کم سے کم تبدیلی کریں، اور پھر اس شرط سے مطابقت رکھنے والے مشاہدے کے ذریعے نتیجے کی تصدیق کریں۔ آخر میں، غلط تبدیلی کو واپس کرنے (undo) کے لیے کافی سیاق و سباق محفوظ رکھیں، خاص طور پر جب کلسٹر کی سطح پر کنفیگریشن، نوڈ فائلز، یا API سرور کی ترتیبات میں ترمیم کی جا رہی ہو۔

آپریشنل اصول غیر متعلقہ وسائل کو تبدیل کرنے والی کسی جانی پہچانی کمانڈ کے مقابلے میں، مطلوبہ باؤنڈری سے منسلک ثبوت کو ترجیح دیں۔

لیب کی باؤنڈری (حدود) کا تعین

اس کورس کے دوران، ہم shop نیم اسپیس میں ریٹیل (retail) کے ایک فرضی ورک لوڈ کو محفوظ بنائیں گے۔ نیم اسپیس (namespace) Kubernetes کا ایک دائرہ کار (scope) ہے جو نیم اسپیس والے وسائل کو یکجا کرتا ہے اور اجازت (authorization) اور پالیسی کی باؤنڈری تشکیل دے سکتا ہے۔ اس ورک لوڈ میں 8080 پورٹ پر orders-api:1.0 تک بیرونی رسائی کا راستہ (ingress path) موجود ہے؛ یہ ایپلیکیشن 8443 پورٹ پر payments-api:1.0 کو کال کرتی ہے؛ اور پھر payments-api، orders-db کا استعمال کرتی ہے۔ اس ماڈل میں، انگریس (ingress) کے علاوہ کوئی بھی ورک لوڈ کلسٹر کے باہر سے قابلِ رسائی نہیں ہے۔

ہر ایپلیکیشن اپنا ServiceAccount استعمال کرتی ہے، جو کہ Kubernetes کی ایک شناخت (identity) ہے جسے کوئی Pod، Kubernetes API کو کال کرتے وقت استعمال کر سکتا ہے۔ orders-api، orders-sa کا استعمال کرتی ہے، جبکہ payments-api، payments-sa کا استعمال کرتی ہے۔ ان شناختوں (identities) کو الگ رکھنے سے ہمیں ‘کم سے کم استحقاق’ (least-privilege) پر مبنی اجازت کے عمل کو نیٹ ورک تک رسائی، امیج کے ماخذ (provenance)، پوڈ (Pod) کی پابندیوں اور رن ٹائم سگنلز سے الگ رکھ کر جانچنے کا موقع ملتا ہے۔ اس ضمن میں قابلِ استعمال اصول یہ ہے کہ سیکیورٹی کنٹرول کا انتخاب کرنے سے پہلے ورک لوڈ کے راستے اور شناخت کی حدود (identity boundary) کی نشاندہی کی جائے۔

اب ہم ورک لوڈ کی اس حد کا تعین کر سکتے ہیں جسے بعد میں اختیار کیے جانے والے حفاظتی اقدامات کے تحت برقرار رکھنا ضروری ہوگا۔