کنٹینر بمقابلہ microVM آئسولیشن: سب پروسیس سے مکمل ورچوئل مشین تک 4 سطحوں کا موازنہ

„اسے سینڈباکس میں چلاؤ“ ایک ہدایت جیسا لگتا ہے۔ عملی طور پر لوگ اس سے چار عام سرحدوں میں سے کسی ایک کا مطلب لیتے ہیں، اور وہ بہت مختلف چیزیں روکتی ہیں۔ غلط انتخاب یا تو آپ کو غیر محفوظ چھوڑ دیتا ہے، یا ہر رن کو ضرورت سے زیادہ سست اور مہنگا بنا دیتا ہے۔

یہ موازنہ مان کر چلتا ہے کہ کوڈ واقعی ناقابل اعتماد ہے: کسی لینگویج ماڈل نے لکھا، کسی صارف نے بھیجا، یا کسی انجان شخص کی pull request میں آیا۔ جو کوڈ آپ نے خود لکھا، اس کی ضروریات الگ ہیں۔

کیا غلط ہو سکتا ہے

سرحدوں کے موازنے سے پہلے یہ بتا دینا مفید ہے کہ وہ کس لیے ہیں۔ ناقابل اعتماد کوڈ یہ کر سکتا ہے:

1. وہ پڑھنا جو نہیں پڑھنا چاہیے: environment variables، SSH keys، آپ کی ہوم ڈائریکٹری کی فائلیں، کلاؤڈ کے metadata endpoints۔
2. وسائل ختم کرنا: لامتناہی لوپ، مشین ٹھپ ہونے تک fork، ڈسک بھر دینا۔
3. نیٹ ورک کا غلط استعمال: دوسرے ہوسٹ اسکین کرنا، اسپام بھیجنا، کرپٹو کرنسی مائن کرنا، آپ کی اندرونی سروسز کو کال کرنا۔
4. ٹکے رہنا: ایسا cron job یا سروس انسٹال کرنا جو کام ختم ہونے کے بعد بھی باقی رہے۔
5. باہر نکلنا: نیچے کی تہہ کے کسی بگ سے خود ہوسٹ پر کوڈ چلانا۔

نیچے کی ہر سطح ان میں سے کچھ کو سنبھالتی ہے اور کچھ کو نہیں۔

سطح 1: پروسیس

سب سے سادہ سینڈباکس ایک چائلڈ پروسیس ہے: timeout کے ساتھ subprocess.run، شاید الگ صارف کے تحت، اور اگر آپ باریکی سے کام کرتے ہیں تو وسائل کی حدوں اور seccomp فلٹر کے ساتھ۔

روکتا ہے: بے لگام وقت (timeout)، کچھ حد تک وسائل کی کھپت (حدیں)، کچھ خطرناک system calls ‏(seccomp)۔ نہیں روکتا: اس صارف کے پڑھ سکنے والی ہر چیز پڑھنا، نیٹ ورک تک رسائی، صارف کے لکھ سکنے والی کسی بھی جگہ سے ٹکے رہنا، اور کوئی بھی کرنل بگ۔ عام ناکامی: کوڈ کوئی ایسی فائل پڑھ لیتا ہے جس کے بارے میں آپ بھول گئے تھے کہ وہ پڑھی جا سکتی ہے، یا کوئی „محدود“ لینگویج انٹرپریٹر چور دروازے والا نکلتا ہے۔ تاریخ ایسے زبان کے اندرونی سینڈباکسوں سے بھری ہے جو ٹک نہیں پائے۔

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

سطح 2: کنٹینر

کنٹینر میں namespaces کوڈ کو فائلوں، پروسیسز اور نیٹ ورک کا اپنا منظر دیتے ہیں؛ cgroups ‏CPU اور میموری محدود کرتے ہیں؛ ہٹائی گئی capabilities اور seccomp یہ محدود کرتے ہیں کہ وہ کرنل سے کیا مانگ سکتا ہے۔

روکتا ہے: ہوسٹ کی فائلیں پڑھنا (جب تک ماؤنٹ نہ ہوں)، دوسرے پروسیسز دیکھنا، لامحدود وسائل کا استعمال، اور اگر کنٹینر بعد میں پھینک دیا جائے تو ٹکے رہنے کا زیادہ تر مسئلہ۔ نہیں روکتا: مشترک ہوسٹ کرنل میں بگ۔ مشین کا ہر کنٹینر ایک ہی کرنل سے بات کرتا ہے، اس لیے پہنچ میں آنے والی کرنل کمزوری باہر نکلنے کا راستہ ہے۔ عام ناکامی: عجیب و غریب exploits نہیں، کنفیگریشن۔ privileged کنٹینر، container runtime کا socket اندر ماؤنٹ، „بس ڈیبگنگ کے لیے“ ہوسٹ نیٹ ورکنگ چالو۔ ہر ایک خاموشی سے سرحد ہٹا دیتا ہے۔

شروع ہونے کا وقت ملی سیکنڈ ہے۔ مضبوط کی گئی شکلیں بھی موجود ہیں، جن میں user-space کرنل شامل ہیں جو system calls کو ہوسٹ تک پہنچنے سے پہلے روک لیتے ہیں، رفتار اور مطابقت کی کچھ قیمت پر۔ جن لوگوں پر آپ بھروسا کرتے ہیں ان کے کوڈ کے لیے اچھی طرح کنفیگر کیا گیا کنٹینر ایک معقول ڈیفالٹ ہے۔

سطح 3: microVM

ایک microVM مکمل ورچوئل مشین کی طرح ہائپروائزر کے تحت اپنا کرنل چلاتی ہے، لیکن تقریباً سارا ایمولیٹ کیا گیا ہارڈویئر ہٹا دیا گیا ہے۔ Firecracker اس کی سب سے معروف مثال ہے۔

روکتی ہے: وہ سب جو کنٹینر روکتا ہے، ساتھ میں مشترک کرنل کا مسئلہ بھی۔ ہوسٹ تک پہنچنے کے لیے کوڈ کو ہائپروائزر یا گنے چنے ورچوئل ڈیوائسز میں سے کسی ایک کو توڑنا ہوگا، جو کرنل کے system-call انٹرفیس سے کہیں چھوٹی سطح ہے۔ نہیں روکتی: جو آپ اسے سونپتے ہیں اس کا غلط استعمال۔ کھلا egress اب بھی غلط استعمال ہو سکتا ہے؛ جو راز آپ اندر ڈالتے ہیں، وہ اب بھی لیک ہو سکتے ہیں۔ عام ناکامی: آئسولیشن نہیں، پالیسی۔ کوئی „ٹیسٹ چلانے کے لیے“ پروڈکشن ٹوکن دے دیتا ہے، یا ایسے ورک لوڈ پر آؤٹ باؤنڈ ٹریفک بے روک ٹوک چھوڑ دیتا ہے جسے اس کی ضرورت ہی نہیں۔

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

سطح 4: مکمل ورچوئل مشین

ایک عام ورچوئل مشین، یا VPS، کی سرحد microVM جیسی ہی ہے: ہارڈویئر ورچوئلائزیشن اور ہائپروائزر۔ فرق اس کے آس پاس کی ہر چیز میں ہے: پورا ڈیوائس ماڈل، پورا آپریٹنگ سسٹم، چاہیں تو پبلک IP، اور دنوں یا مہینوں میں ناپا جانے والا لائف سائیکل۔

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

شروع ہونے کا وقت دسیوں سیکنڈ سے منٹوں تک ہے، اور بلنگ عام طور پر ماہانہ ہوتی ہے۔ یہ ان طویل چلنے والی سروسز کے لیے درست شکل ہے جنہیں ان باؤنڈ پورٹ چاہیے، اور 20 سیکنڈ کے کوڈ رن کے لیے غلط شکل۔

موازنہ

انتخاب

• آپ کا یا آپ کی ٹیم کا لکھا کوڈ: پروسیس یا کنٹینر کافی ہے۔
• آپ کی اپنی branches کے لیے مسلسل انضمام (CI): آپ کے runner پر کنٹینر۔
• ایجنٹ کا بنایا کوڈ، صارفین کی بھیجی چیزیں، باہر کی pull requests: ہر کام کے لیے ایک microVM، بعد میں حذف کی جائے۔
• ایسی ناقابل اعتماد سروس جسے کنکشن لینے ہوں یا ہفتوں چلنا ہو: اپنے IP والی الگ ورچوئل مشین، اس ہر چیز سے دور جو آپ کے کریڈینشلز رکھتی ہو یا آپ کی ای میل بھیجتی ہو۔

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

ہماری مصنوعات کہاں آتی ہیں

سطح 3 کے لیے ہم کوڈ سینڈباکس چلاتے ہیں: Firecracker microVM جو تقریباً ایک سیکنڈ میں شروع ہوتی ہیں، آؤٹ باؤنڈ انٹرنیٹ کے ساتھ، بغیر ان باؤنڈ پورٹ کے اور فی سیکنڈ بلنگ کے ساتھ۔ یہ ٹھیک اوپر والے تیسرے نکتے کے لیے ہیں؛ MCP کے حفاظتی اقدامات کا صفحہ بتاتا ہے کہ کسی ایجنٹ کو ان کے ساتھ کیا کرنے دیا جائے، اسے کیسے محدود کریں۔ سطح 4 کے لیے، AI agent پلان جیسا VPS آپ کو مہینے کے حساب سے پوری مشین دیتا ہے۔ AI ایجنٹوں کے لیے سینڈباکس کی مثالیں microVM پیٹرن کو شروع سے آخر تک دکھاتی ہیں، اور AI ایجنٹوں کو انفراسٹرکچر سے کیا چاہیے آئسولیشن کو کئی ضروریات میں سے ایک کے طور پر دیکھتا ہے۔