कंटेनर बनाम microVM आइसोलेशन: सबप्रोसेस से पूरी VM तक, 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 पूरी VM की तरह हाइपरवाइज़र के तहत अपना कर्नेल चलाती है, लेकिन लगभग सारा एम्युलेटेड हार्डवेयर हटा दिया गया है। Firecracker इसका सबसे जाना-माना उदाहरण है।

रोकती है: वह सब जो कंटेनर रोकता है, साथ में साझा कर्नेल की समस्या भी। होस्ट तक पहुँचने के लिए कोड को हाइपरवाइज़र या गिने-चुने वर्चुअल डिवाइसों में से किसी एक को तोड़ना होगा, जो कर्नेल के system-call इंटरफ़ेस से कहीं छोटी सतह है। नहीं रोकती: जो आप उसे सौंपते हैं उसका दुरुपयोग। खुला egress अब भी दुरुपयोग हो सकता है; जो सीक्रेट आप अंदर डालते हैं, वे अब भी लीक हो सकते हैं। आम विफलता: आइसोलेशन नहीं, नीति। कोई “टेस्ट चलाने के लिए” प्रोडक्शन टोकन दे देता है, या ऐसे वर्कलोड पर आउटबाउंड ट्रैफ़िक बेरोक-टोक छोड़ देता है जिसे उसकी ज़रूरत ही नहीं।

शुरू होने का समय सेकंड के एक हिस्से से लेकर लगभग एक सेकंड तक है, कुछ मेगाबाइट के ओवरहेड के साथ। यह इतना तेज़ है कि हर काम के लिए एक बनाकर बाद में हटा दें, जिससे टिके रहने की समस्या भी हल हो जाती है: लौटने के लिए कुछ बचता ही नहीं।

स्तर 4: पूरी वर्चुअल मशीन

एक सामान्य VM, या VPS, की सीमा microVM जैसी ही है: हार्डवेयर वर्चुअलाइज़ेशन और हाइपरवाइज़र। फ़र्क़ उसके आसपास की हर चीज़ में है: पूरा डिवाइस मॉडल, पूरा OS, चाहें तो पब्लिक IP, और दिनों या महीनों में मापा जाने वाला जीवनचक्र।

रोकती है: microVM जैसी ही श्रेणियों की समस्याएँ, कुछ बड़ी attack surface के साथ क्योंकि ज़्यादा हार्डवेयर एम्युलेट होता है। नहीं रोकती: अपनी नेटवर्क पहचान का दुरुपयोग। पब्लिक IP वाली VM जो दुरुपयोग करने वाला कोड चलाती है, अपना IP ब्लॉकलिस्ट करवा लेती है, जो तब मायने रखता है जब वही IP आपका ईमेल भी भेजता हो। (अगर ऐसा हो चुका है, तो देखें जब आपका IP ब्लॉकलिस्ट पर हो तो क्या करें।) आम विफलता: यह बहुत लंबा जीती है। किसी एक प्रयोग के लिए बनाई गई VM क्रेडेंशियल और स्टेट जमा करती जाती है, और धीरे-धीरे वही भरोसेमंद मशीन बन जाती है जिसकी उसे रक्षा करनी थी।

शुरू होने का समय दसियों सेकंड से मिनटों तक है, और बिलिंग आम तौर पर मासिक होती है। यह उन लंबे समय तक चलने वाली सेवाओं के लिए सही रूप है जिन्हें इनबाउंड पोर्ट चाहिए, और 20 सेकंड के कोड रन के लिए ग़लत रूप।

तुलना

चुनाव

• आपका या आपकी टीम का लिखा कोड: प्रोसेस या कंटेनर काफ़ी है।
• आपकी अपनी branches के लिए CI: आपके runner पर कंटेनर।
• एजेंट का बनाया कोड, यूज़र की भेजी चीज़ें, बाहर के pull requests: हर काम के लिए एक microVM, बाद में हटाई जाए।
• ऐसी अविश्वसनीय सेवा जिसे कनेक्शन लेने हों या हफ़्तों चलना हो: अपने IP वाली अलग VM, उस हर चीज़ से दूर जो आपके क्रेडेंशियल रखती हो या आपका ईमेल भेजती हो।

आप जो भी चुनें, ऊपर से दो नियम लागू होते हैं: अंदर ऐसा कुछ न रखें जो आप कोड के लेखक को न सौंपते, और सोच-समझकर तय करें कि नेटवर्क क्या कर सकता है।

हमारे प्रोडक्ट कहाँ आते हैं

स्तर 3 के लिए हम कोड सैंडबॉक्स चलाते हैं: Firecracker microVM जो लगभग एक सेकंड में शुरू होती हैं, आउटबाउंड इंटरनेट के साथ, बिना इनबाउंड पोर्ट के और प्रति-सेकंड बिलिंग के साथ। ये ठीक ऊपर वाले तीसरे बिंदु के लिए हैं; MCP सुरक्षा उपाय पेज बताता है कि किसी एजेंट को इनके साथ क्या करने दिया जाए, इसे कैसे सीमित करें। स्तर 4 के लिए, AI agent प्लान जैसा VPS आपको महीने के हिसाब से पूरी मशीन देता है। AI एजेंटों के लिए सैंडबॉक्स के उदाहरण microVM पैटर्न को शुरू से अंत तक दिखाते हैं, और AI एजेंटों को इन्फ्रास्ट्रक्चर से क्या चाहिए आइसोलेशन को कई ज़रूरतों में से एक के रूप में देखता है।