कंटेनरों को और भी अलग कैसे बनाया जाए: कंटेनर सैंडबॉक्स प्रौद्योगिकियों की समीक्षा

इस तथ्य के बावजूद कि अधिकांश आईटी उद्योग कंटेनरों और क्लाउड समाधानों के आधार पर बुनियादी ढांचे के समाधान को लागू करते हैं, इन प्रौद्योगिकियों की सीमाओं को समझना आवश्यक है। परंपरागत रूप से, डॉकर, लिनक्स कंटेनर (एलएक्ससी) और रॉकेट (आरकेटी) वास्तव में अलग-थलग नहीं हैं, क्योंकि वे अपने काम में मूल ऑपरेटिंग सिस्टम के कोर को साझा करते हैं। हां, वे संसाधनों के मामले में प्रभावी हैं, लेकिन अनुमानित हमले वाले वैक्टर की कुल संख्या और हैकिंग से संभावित नुकसान अभी भी बड़े हैं, खासकर एक बहु-किरायेदार बादल वातावरण के मामले में जिसमें कंटेनर स्थित हैं।



हमारी समस्या की जड़ उस समय कंटेनरों के कमजोर परिसीमन में निहित है जब मेजबान ऑपरेटिंग सिस्टम उनमें से प्रत्येक के लिए एक आभासी उपयोगकर्ता क्षेत्र बनाता है। हां, पूर्ण विकसित सैंडबॉक्स के साथ वास्तविक "कंटेनर" बनाने के उद्देश्य से अनुसंधान और विकास किया गया है। और अधिकांश परिणामी समाधान उनके अलगाव को बढ़ाने के लिए कंटेनरों के बीच की सीमाओं के पुनर्गठन के लिए नेतृत्व करते हैं। इस लेख में, हम क्रमशः IBM, Google, Amazon और OpenStack की चार अनूठी परियोजनाओं को देखेंगे, जो एक ही लक्ष्य को प्राप्त करने के लिए विभिन्न तरीकों का उपयोग करती हैं: विश्वसनीय अलगाव का निर्माण। इसलिए, आईबीएम नबला ने यूनिकबर्न के शीर्ष पर कंटेनरों को चित्रित किया, Google gVisor एक विशिष्ट अतिथि कर्नेल बनाता है, अमेज़ॅन पटाखे सैंडबॉक्स अनुप्रयोगों के लिए एक अत्यंत हल्के हाइपरवाइज़र का उपयोग करता है, और ऑर्केस्ट्रेशन टूल के लिए अनुकूलित एक विशेष वर्चुअल मशीन में ओपनस्टैक स्थानों के कंटेनरों का उपयोग करता है।

आधुनिक कंटेनर प्रौद्योगिकी का अवलोकन

कंटेनर एक एप्लिकेशन को पैकेज, शेयर और तैनात करने का एक आधुनिक तरीका है। एक अखंड आवेदन के विपरीत, जिसमें सभी कार्यों को एक कार्यक्रम में पैक किया जाता है, कंटेनर अनुप्रयोगों या माइक्रोसिस्ट्र्स को लक्षित संकीर्ण उपयोग के लिए लक्षित किया जाता है और केवल एक कार्य में विशेषज्ञ होता है।

एक कंटेनर में सभी निर्भरताएं शामिल हैं (उदाहरण के लिए, पैकेज, लाइब्रेरी और बायनेरिज़) जो कि एक आवेदन को अपने विशिष्ट कार्य को पूरा करने की आवश्यकता होती है। नतीजतन, कंटेनरीकृत एप्लिकेशन प्लेटफ़ॉर्म स्वतंत्र हैं और किसी भी ऑपरेटिंग सिस्टम पर चल सकते हैं, चाहे संस्करण या इंस्टॉल किए गए पैकेज। यह सुविधा डेवलपर्स को विभिन्न प्लेटफार्मों या क्लाइंट के लिए सॉफ़्टवेयर के विभिन्न संस्करणों को अपनाने पर काम के एक बड़े हिस्से से बचाता है। हालांकि वैचारिक रूप से पूरी तरह से सही नहीं है, कई लोग कंटेनरों को "हल्के आभासी मशीनों" के रूप में सोचना पसंद करते हैं।

जब एक कंटेनर को एक मेजबान पर तैनात किया जाता है, तो प्रत्येक कंटेनर के संसाधन, जैसे कि इसकी फ़ाइल प्रणाली, प्रक्रिया और नेटवर्क स्टैक, को लगभग अलग-थलग वातावरण में डाल दिया जाता है, जो अन्य कंटेनरों तक नहीं पहुंच सकते। यह आर्किटेक्चर सैकड़ों और हजारों कंटेनरों को एक साथ एक ही क्लस्टर में चलाने की अनुमति देता है, और प्रत्येक एप्लिकेशन (या माइक्रोसर्विस) को बड़ी संख्या में उदाहरणों को दोहराकर आसानी से बढ़ाया जा सकता है।

इस मामले में, कंटेनर लेआउट दो प्रमुख "बिल्डिंग ब्लॉक्स" पर आधारित है: लिनक्स नेमस्पेस और लिनक्स कंट्रोल ग्रुप (cgroups)।

नाम स्थान लगभग अलग-थलग उपयोगकर्ता स्थान बनाता है और फ़ाइल सिस्टम, नेटवर्क स्टैक, प्रक्रिया ID और उपयोगकर्ता ID जैसे समर्पित सिस्टम संसाधनों के साथ अनुप्रयोग प्रदान करता है। इस पृथक उपयोगकर्ता स्थान में, एप्लिकेशन फाइल सिस्टम की रूट डायरेक्टरी को नियंत्रित करता है और इसे रूट के रूप में चलाया जा सकता है। यह सार स्थान एक ही होस्ट पर रहने वाले अन्य अनुप्रयोगों के साथ हस्तक्षेप किए बिना, प्रत्येक एप्लिकेशन को स्वतंत्र रूप से काम करने की अनुमति देता है। छह नामस्थान वर्तमान में उपलब्ध हैं: माउंट, अंतर-प्रक्रिया संचार (ipc), UNIX समय-साझाकरण प्रणाली (uts), प्रोसेस आईडी (pid), नेटवर्क और उपयोगकर्ता। यह सूची दो अतिरिक्त नामस्थान: समय और syslog के साथ पूरक होने का प्रस्ताव है, लेकिन लिनक्स समुदाय ने अभी तक अंतिम विनिर्देशों पर निर्णय नहीं लिया है।

Cgroups हार्डवेयर संसाधन सीमा, प्राथमिकता, अनुप्रयोग निगरानी और नियंत्रण प्रदान करते हैं। हार्डवेयर संसाधनों का एक उदाहरण जो वे नियंत्रित कर सकते हैं, प्रोसेसर, मेमोरी, डिवाइस और नेटवर्क है। नेमस्पेस और कॉग्रुप्स को मिलाते समय, हम सुरक्षित रूप से एक ही होस्ट पर कई एप्लिकेशन चला सकते हैं, जिसमें प्रत्येक एप्लिकेशन अपने अलग वातावरण में होता है - जो कंटेनर की मूलभूत संपत्ति है।

वर्चुअल मशीन (VM) और कंटेनर के बीच मुख्य अंतर यह है कि वर्चुअल मशीन हार्डवेयर स्तर पर वर्चुअलाइजेशन है, और कंटेनर ऑपरेटिंग सिस्टम स्तर पर वर्चुअलाइजेशन है। VM हाइपरविजर प्रत्येक मशीन के लिए हार्डवेयर वातावरण का अनुकरण करता है, जहां कंटेनर रनटाइम पहले से ही प्रत्येक ऑब्जेक्ट के लिए ऑपरेटिंग सिस्टम का अनुकरण करता है। वर्चुअल मशीनें होस्ट के भौतिक हार्डवेयर को साझा करती हैं, और कंटेनर हार्डवेयर और ओएस कोर दोनों को साझा करते हैं। चूंकि कंटेनर आमतौर पर मेजबान के साथ अधिक संसाधन साझा करते हैं, इसलिए भंडारण, मेमोरी और सीपीयू साइकिल के साथ उनका काम एक आभासी मशीन की तुलना में बहुत अधिक कुशल है। हालांकि, इस साझा पहुंच का नुकसान सूचना सुरक्षा के विमान में एक समस्या है, क्योंकि ट्रस्ट कंटेनरों और मेजबान के बीच स्थापित है। चित्रा 1 एक कंटेनर और एक आभासी मशीन के बीच के वास्तु अंतर को दर्शाता है।



सामान्य तौर पर, वर्चुअलाइज्ड उपकरणों का अलगाव एक नेमस्पेस के अलगाव से ज्यादा मजबूत सुरक्षा परिधि बनाता है। एक हमलावर जो सफलतापूर्वक एक पृथक प्रक्रिया को छोड़ देता है, वह वर्चुअल मशीन को सफलतापूर्वक छोड़ने की संभावना से बहुत अधिक है। सीमित कंटेनर पर्यावरण से परे जाने के उच्च जोखिम का कारण नामस्थान और cgroups द्वारा बनाई गई खराब अलगाव है। लिनक्स प्रत्येक प्रक्रिया के साथ नए संपत्ति क्षेत्रों को जोड़कर उन्हें लागू करता है। /proc फ़ाइल सिस्टम में ये फ़ील्ड होस्ट ऑपरेटिंग सिस्टम को इंगित करती हैं कि क्या एक प्रक्रिया दूसरे को देख सकती है, या प्रोसेसर / मेमोरी संसाधन किसी विशेष प्रक्रिया का उपयोग कर सकते हैं। पैरेंट ओएस (उदाहरण के लिए, शीर्ष या पीएस कमांड) से चल रही प्रक्रियाओं और थ्रेड्स को देखते समय, कंटेनर प्रक्रिया किसी अन्य की तरह ही दिखती है। आमतौर पर, पारंपरिक समाधान, जैसे LXC या डॉकर, को पूरी तरह से अलग नहीं माना जाता है क्योंकि वे एक ही मेजबान के भीतर एक ही कोर का उपयोग करते हैं। इसलिए, यह आश्चर्यजनक नहीं है कि कंटेनरों में पर्याप्त संख्या में कमजोरियां हैं। उदाहरण के लिए, CVE-2014-3519, CVE-2016-5195, CVE-2016-9962, CVE-2017-5123, और CVE-2019-5736 कंटेनर के बाहर डेटा तक पहुंच प्राप्त करने में हमलावर हो सकते हैं।

अधिकांश कर्नेल कारनामे एक सफल हमले के लिए एक वेक्टर बनाते हैं, क्योंकि वे आमतौर पर विशेषाधिकार वृद्धि का परिणाम देते हैं और एक समझौता प्रक्रिया को अपने इच्छित नाम स्थान के बाहर नियंत्रण प्राप्त करने की अनुमति देते हैं। सॉफ्टवेयर कमजोरियों के संदर्भ में वैक्टर पर हमला करने के अलावा, अनुचित कॉन्फ़िगरेशन भी एक भूमिका निभा सकता है। उदाहरण के लिए, अत्यधिक विशेषाधिकारों (CAP_SYS_ADMIN, विशेषाधिकार प्राप्त पहुंच) या महत्वपूर्ण माउंट बिंदु ( /var/run/docker.sock ) के साथ छवियों को तैनात करने से एक रिसाव हो सकता है। इन संभावित विनाशकारी परिणामों को देखते हुए, आपको उस जोखिम को समझना चाहिए जो आप सिस्टम को मल्टी-टेनेंट स्पेस में तैनात करते समय या संवेदनशील डेटा को स्टोर करने के लिए कंटेनरों का उपयोग करते समय करते हैं।

ये समस्याएं शोधकर्ताओं को मजबूत सुरक्षा परिधि बनाने के लिए प्रेरित करती हैं। विचार एक असली सैंडबॉक्स कंटेनर बनाने के लिए है जो मुख्य ओएस से यथासंभव पृथक है। इनमें से अधिकांश समाधानों में हाइब्रिड आर्किटेक्चर का विकास शामिल है जो एप्लिकेशन और वर्चुअल मशीन के बीच एक सख्त अंतर का उपयोग करता है, और कंटेनर समाधानों की दक्षता में सुधार करने पर ध्यान केंद्रित करता है।

लेखन के समय, एक भी परियोजना नहीं थी जिसे एक मानक के रूप में स्वीकार किए जाने के लिए पर्याप्त रूप से परिपक्व कहा जा सकता था, लेकिन भविष्य में, डेवलपर्स निस्संदेह इनमें से कुछ अवधारणाओं को मुख्य रूप से स्वीकार करेंगे।

हम यूनिकबर्न के साथ अपनी समीक्षा शुरू करते हैं, सबसे पुराना अति विशिष्ट सिस्टम जो ओएस लाइब्रेरी के न्यूनतम सेट का उपयोग करके एक एप्लिकेशन को एक छवि में पैक करता है। यूनिकबर्न की अवधारणा ही कई परियोजनाओं के लिए मौलिक साबित हुई जिनका लक्ष्य सुरक्षित, कॉम्पैक्ट और अनुकूलित छवियां बनाना था। उसके बाद, हम आईबीएम नबला पर विचार करने के लिए आगे बढ़ेंगे, कंटेनर सहित यूनिकबर्न अनुप्रयोगों को लॉन्च करने की परियोजना। इसके अलावा, हमारे पास Google gVisor है, जो उपयोगकर्ता कर्नेल स्थान में कंटेनर लॉन्च करने के लिए एक परियोजना है। अगला, हम वर्चुअल मशीन - अमेज़ॅन पटाखा और ओपनस्टैक काटा के आधार पर कंटेनर समाधान पर स्विच करेंगे। उपरोक्त सभी समाधानों की तुलना करके इस पोस्ट को संक्षेप में प्रस्तुत करें।

Unikernel

वर्चुअलाइजेशन प्रौद्योगिकियों के विकास ने हमें क्लाउड कंप्यूटिंग में जाने की अनुमति दी है। एक्सईएन और केवीएम जैसे हाइपरवाइजर्स ने इस बात की नींव रखी है कि अब हम अमेज़ॅन वेब सर्विसेज (एडब्ल्यूएस) और गूगल क्लाउड प्लेटफॉर्म (जीसीपी) के रूप में क्या जानते हैं। और यद्यपि आधुनिक हाइपरविजर एक ही क्लस्टर में संयुक्त सैकड़ों आभासी मशीनों के साथ काम करने में सक्षम हैं, पारंपरिक सामान्य-उद्देश्य ऑपरेटिंग सिस्टम ऐसे वातावरण में काम करने के लिए अनुकूलित और अनुकूलित नहीं हैं। सामान्य उद्देश्य ओएस का उद्देश्य है, सबसे पहले, समर्थन करना और यथासंभव विभिन्न अनुप्रयोगों के साथ काम करना, इसलिए उनकी गुठली में सभी प्रकार के ड्राइवर, लाइब्रेरी, प्रोटोकॉल, शेड्यूलर और इतने पर शामिल हैं। हालाँकि, अधिकांश वर्चुअल मशीनें जो अब क्लाउड में कहीं पर तैनात हैं, का उपयोग एकल एप्लिकेशन को चलाने के लिए किया जाता है, उदाहरण के लिए, DNS, एक प्रॉक्सी या किसी प्रकार का डेटाबेस प्रदान करने के लिए। चूँकि ऐसा एकल अनुप्रयोग केवल OS कर्नेल के एक विशिष्ट और छोटे हिस्से पर अपने काम में निर्भर करता है, इसके सभी अन्य "स्कर्ट" बस सिस्टम संसाधनों को बर्बाद करते हैं, और इसके अस्तित्व के तथ्य से संभावित हमले के लिए वैक्टर की संख्या में वृद्धि होती है। वास्तव में, कोड आधार जितना बड़ा होगा, सभी कमियों को खत्म करना उतना ही मुश्किल होगा, और अधिक संभावित कमजोरियां, त्रुटियां और अन्य कमजोरियां। यह समस्या विशेषज्ञों को एक विशेष अनुप्रयोग का समर्थन करने के लिए उपकरण बनाने के लिए, कर्नेल कार्यक्षमता के न्यूनतम सेट के साथ अत्यधिक विशिष्ट ऑपरेटिंग सिस्टम विकसित करने के लिए प्रोत्साहित करती है।

पहली बार, यूनिकबर्न का विचार 90 के दशक में पैदा हुआ था। फिर उन्होंने एक मशीन की एक विशेष छवि के रूप में एक एकल पता स्थान लिया, जो सीधे हाइपरविज़र पर काम कर सकता था। यह कोर और कर्नेल-निर्भर अनुप्रयोगों और कार्यों को एक ही छवि में पैक करता है। नेमिसिस और एक्सोकोर्नेल, यूनिकबर्न परियोजना के दो शुरुआती अनुसंधान संस्करण हैं। पैकेजिंग और परिनियोजन प्रक्रिया को चित्र 2 में दिखाया गया है।


चित्रा 2. बहुउद्देशीय ऑपरेटिंग सिस्टम सभी प्रकार के अनुप्रयोगों का समर्थन करने के लिए डिज़ाइन किया गया है, इसलिए कई पुस्तकालयों और ड्राइवरों को अग्रिम में लोड किया जाता है। Unikernels अत्यधिक विशिष्ट ऑपरेटिंग सिस्टम हैं जो एक विशिष्ट एप्लिकेशन का समर्थन करने के लिए डिज़ाइन किए गए हैं।

यूनिकबर्न कर्नेल को कई पुस्तकालयों में तोड़ता है और छवि में केवल आवश्यक घटक डालता है। नियमित रूप से आभासी मशीनों की तरह, अनिकर्बिन को तैनात करता है और वीएम हाइपरवाइजर पर चलता है। अपने छोटे आकार के कारण, यह जल्दी से लोड हो सकता है और जल्दी से स्केल भी कर सकता है। यूनिकबर्न की सबसे महत्वपूर्ण विशेषताएं बढ़ी हुई सुरक्षा, छोटे पदचिह्न, अनुकूलन की एक उच्च डिग्री और तेजी से लोड हो रही हैं। चूँकि इन चित्रों में केवल अनुप्रयोग-निर्भर पुस्तकालय होते हैं, और OS शेल सुलभ नहीं होता है यदि यह उद्देश्यपूर्ण रूप से जुड़ा नहीं था, तो हमलावरों पर हमला करने वाले वैक्टरों की संख्या कम से कम हो सकती है।

यही है, हमलावरों के लिए न केवल इन अद्वितीय कोर में पैर जमाना मुश्किल है, बल्कि उनका प्रभाव भी एक मूल उदाहरण तक सीमित है। चूंकि यूनिकबर्न छवियों का आकार केवल कुछ मेगाबाइट है, वे दसियों मिलीसेकंड में डाउनलोड किए जाते हैं, और शाब्दिक रूप से सैकड़ों उदाहरण एक ही होस्ट पर चल सकते हैं। मल्टीलेवल पेज टेबल के बजाय एक ही एड्रेस स्पेस में मेमोरी एलोकेशन का उपयोग करना, जैसा कि अधिकांश आधुनिक ऑपरेटिंग सिस्टमों में होता है, नियमित वर्चुअल मशीन पर चलने वाले एक ही एप्लिकेशन की तुलना में अनिकेर्नल एप्लिकेशन में मेमोरी की पहुंच कम होती है। क्योंकि छवि के निर्माण के दौरान अनुप्रयोग कर्नेल के साथ एक साथ आते हैं, कंपाइलर केवल बाइनरी फ़ाइलों को अनुकूलित करने के लिए स्थैतिक प्रकार की जाँच कर सकते हैं।

Unikernel.org, अनीकबर्न प्रोजेक्ट्स की एक सूची रखता है। लेकिन इसकी सभी विशिष्ट विशेषताओं और गुणों के साथ, यूनिकबर्न का व्यापक रूप से उपयोग नहीं किया जाता है। जब डॉकर ने 2016 में यूनिकबर्न सिस्टम का अधिग्रहण किया, तो समुदाय ने फैसला किया कि कंपनी अब उनमें कंटेनर पैक करेगी। लेकिन तीन साल बीत चुके हैं, और अभी भी एकीकरण के कोई संकेत नहीं हैं। इस धीमे कार्यान्वयन के मुख्य कारणों में से एक यह है कि अभी भी यूनिकबर्न एप्लिकेशन बनाने के लिए कोई परिपक्व उपकरण नहीं है, और इनमें से अधिकांश एप्लिकेशन केवल कुछ हाइपरवाइज़र पर काम कर सकते हैं। इसके अलावा, एक अनुप्रयोग को अनिकबर्न में पोर्ट करने के लिए अन्य भाषाओं में मैन्युअल रूप से पुनर्लेखन कोड की आवश्यकता हो सकती है, जिसमें आश्रित कर्नेल लाइब्रेरीज़ को फिर से लिखना शामिल है। यह भी महत्वपूर्ण है कि अनइकर्नल्स में निगरानी या डिबगिंग या तो असंभव है या प्रदर्शन पर महत्वपूर्ण प्रभाव पड़ता है।

ये सभी प्रतिबंध डेवलपर्स को इस तकनीक पर स्विच करने से रोकते हैं। यह ध्यान दिया जाना चाहिए कि अनीकबर्न और कंटेनरों में कई समान गुण हैं। पहले और दूसरे दोनों अत्यधिक केंद्रित अपरिवर्तनीय छवियां हैं, जिसका अर्थ है कि उनके अंदर के घटकों को अपडेट या तय नहीं किया जा सकता है, अर्थात, आपको एप्लिकेशन पैच के लिए हमेशा एक नई छवि बनानी होगी। आज, यूनिकबर्न डॉकर के पूर्वज के समान है: तब कंटेनर रनटाइम उपलब्ध नहीं था, और डेवलपर्स को एक पृथक अनुप्रयोग वातावरण (चेरोट, अनशेयर और सीग्रुप्स) के निर्माण के लिए बुनियादी उपकरणों का उपयोग करना पड़ता था।

इब्म नबला

एक बार, आईबीएम के शोधकर्ताओं ने "यूनिकबर्न को एक प्रक्रिया के रूप में" की अवधारणा का प्रस्ताव दिया - अर्थात्, अनीकबर्न एप्लिकेशन जो एक विशेष हाइपरवाइजर पर एक प्रक्रिया के रूप में चलेगा। आईबीएम परियोजना "नबला कंटेनर" ने यूनिवर्सल हाइपरवाइजर (उदाहरण के लिए, क्यूईएमयू) की जगह नबला टेंडर नामक अपने स्वयं के विकास के साथ, अनीकबर्न की सुरक्षा परिधि को मजबूत किया। इस दृष्टिकोण के पीछे तर्क यह है कि अनइक्युलर और हाइपरविजर के बीच कॉल अभी भी सबसे अधिक हमला करने वाले वैक्टर प्रदान करते हैं। यही कारण है कि कम अनुमत प्रणाली कॉल के साथ अनिक्रीब को समर्पित हाइपरविजर का उपयोग सुरक्षा परिधि को काफी मजबूत कर सकता है। नबला निविदा हाइपरविजर के लिए अनधिकृत मार्गों पर कॉल को स्वीकार करती है, और पहले से ही सिस्टम अनुरोधों में उनका अनुवाद करती है। उसी समय, seccomp Linux नीति अन्य सभी सिस्टम कॉल को ब्लॉक कर देती है जो काम करने के लिए Tender की आवश्यकता नहीं होती हैं। इस प्रकार, नबला निविदा के साथ संयोजन के रूप में यूनिकबर्न मेजबान के उपयोगकर्ता स्थान में एक प्रक्रिया के रूप में चलता है। नीचे, आंकड़ा # 3 में, यह दिखाया गया है कि नाबला कैसे अनकिनल और होस्ट के बीच एक पतली इंटरफ़ेस बनाता है।


चित्रा 3. नबला को मौजूदा कंटेनर रनटाइम प्लेटफार्मों के साथ जोड़ने के लिए, नबला एक ओसीआई-संगत वातावरण का उपयोग करता है, जो बदले में डोकर या कुबेरनेट्स से जुड़ा हो सकता है।

डेवलपर्स का दावा है कि होस्ट के साथ बातचीत करने के लिए नबला टेंडर अपने काम में सात से कम सिस्टम कॉल का उपयोग करता है। चूंकि सिस्टम कॉल उपयोगकर्ता स्पेस में प्रक्रियाओं और ऑपरेटिंग सिस्टम के कर्नेल के बीच एक तरह के पुल के रूप में काम करते हैं, कम सिस्टम कॉल हमें उपलब्ध हैं, कर्नेल पर हमला करने के लिए उपलब्ध वैक्टर की संख्या जितनी कम है। एक प्रक्रिया के रूप में अनिकबर्न को चलाने का एक और फायदा यह है कि आप बड़ी संख्या में टूल का उपयोग करके ऐसे एप्लिकेशन को डीबग कर सकते हैं, उदाहरण के लिए, जीडीबी का उपयोग करना।

कंटेनर ऑर्केस्ट्रेशन प्लेटफार्मों के साथ काम करने के लिए, नबला एक समर्पित runnc प्रदान करता है जो ओपन कंटेनर इनिशिएटिव (OCI) मानक का उपयोग करके कार्यान्वित किया जाता है। उत्तरार्द्ध ग्राहकों (जैसे डोकर, Kubectl) और रनटाइम वातावरण (जैसे, रनवे) के बीच एक एपीआई को परिभाषित करता है। नबला भी एक छवि निर्माणकर्ता के साथ आता है जो बाद में runnc को चलाने में सक्षम होगा। हालांकि, अनिकर्नेल और पारंपरिक कंटेनरों के बीच फाइल सिस्टम में अंतर के कारण, नबला छवियां ओसीआई छवि विनिर्देशों को पूरा नहीं करती हैं और इसलिए, डॉकर छवियां runnc के साथ संगत नहीं हैं। लेखन के समय, परियोजना अभी भी विकास के प्रारंभिक चरण में है। अन्य प्रतिबंध हैं, उदाहरण के लिए, होस्ट फ़ाइल सिस्टम को माउंट / एक्सेस करने के लिए समर्थन की कमी, कई नेटवर्क इंटरफेस (कुबेरनेट्स के लिए आवश्यक) को जोड़ना, या अन्य अनीकबर्न छवियों से छवियों का उपयोग करना (उदाहरण के लिए, मिराजओएस)।

Google जीवीज़र

Google क्लाउड, Google क्लाउड प्लेटफ़ॉर्म एप्लिकेशन इंजन (GCP), क्लाउड सुविधाओं और क्लाउडएलएम का उपयोग करके सैंडबॉक्स तकनीक है। कुछ बिंदु पर, Google को सार्वजनिक क्लाउड इन्फ्रास्ट्रक्चर में अविशिष्ट एप्लिकेशन चलाने का जोखिम और आभासी मशीनों का उपयोग करके सैंडबॉक्स अनुप्रयोगों की अक्षमता का एहसास हुआ। नतीजतन, इस तरह के अविश्वसनीय अनुप्रयोगों के एक अलग वातावरण के लिए एक उपयोगकर्ता-अंतरिक्ष कर्नेल विकसित किया गया था। gVisor इन एप्लिकेशन को सैंडबॉक्स में रखता है, सभी सिस्टम कॉल को होस्ट कर्नेल से इंटरसेप्ट करता है और उन्हें GVITIT संतरी कर्नेल का उपयोग करके उपयोगकर्ता वातावरण में संसाधित करता है। संक्षेप में, यह एक अतिथि कोर और एक हाइपरविजर के संयोजन के रूप में कार्य करता है। चित्रा 4 जीवीज़र वास्तुकला को दर्शाता है।


चित्रा 4. gVisor कर्नेल का कार्यान्वयन // संतरी और gVisor गोफर फ़ाइल सिस्टम होस्ट के साथ बातचीत करने के लिए कम संख्या में सिस्टम कॉल का उपयोग करते हैं

जीवीज़र एप्लिकेशन और इसके होस्ट के बीच एक मजबूत सुरक्षा परिधि बनाता है। यह सिस्टम कॉल को सीमित करता है जिसका उपयोग उपयोगकर्ता अंतरिक्ष में कर सकते हैं। वर्चुअलाइजेशन पर भरोसा किए बिना, जीवीज़र एक मेजबान प्रक्रिया के रूप में काम करता है जो एक स्टैंड-अलोन एप्लिकेशन और एक होस्ट के बीच बातचीत करता है। संतरी ज्यादातर लिनक्स सिस्टम कॉल और कोर कर्नेल सुविधाओं जैसे सिग्नल डिलीवरी, मेमोरी मैनेजमेंट, नेटवर्क स्टैक और स्ट्रीम मॉडल का समर्थन करता है। सैंडबॉक्स वाले एप्लिकेशन का समर्थन करने के लिए 319 लिनक्स सिस्टम कॉल के 70% से अधिक संतरी औजार। हालाँकि, संतरी होस्ट कर्नेल के साथ बातचीत करने के लिए 20 से कम लिनक्स सिस्टम कॉल का उपयोग करता है। यह ध्यान देने योग्य है कि जीवीज़र और नबला की एक समान रणनीति है: होस्ट ओएस की रक्षा करना और ये दोनों समाधान कर्नेल के साथ बातचीत करने के लिए 10% से कम लिनक्स सिस्टम कॉल का उपयोग करते हैं। लेकिन आपको यह समझने की आवश्यकता है कि जीवीज़र एक बहुउद्देश्यीय कर्नेल बनाता है, और, उदाहरण के लिए, नाबला अद्वितीय गुठली पर निर्भर करता है। एक ही समय में, दोनों समाधान उपयोगकर्ता स्पेस में एक विशिष्ट अतिथि कर्नेल को उनके द्वारा भरोसा किए गए पृथक अनुप्रयोगों का समर्थन करने के लिए लॉन्च करते हैं।

किसी को आश्चर्य हो सकता है कि क्यों जीवीज़र को अपनी कर्नेल की आवश्यकता होती है, जब लिनक्स कर्नेल पहले से ही खुला स्रोत और आसानी से सुलभ है। , gVisor, Golang, , ​​Linux, C. Golang. gVisor — Docker, Kubernetes OCI. Docker gVisor, gVisor runsc. Kubernetes «» gVisor «»-.

gVisor , . gVisor , , , . ( , Nabla , unikernel . Nabla hypercall). gVisor (passthrough), , , , GPU, . , gVisor 70% Linux, , , gVisor.

Amazon Firecracker

Amazon Firecracker — , AWS Lambda AWS Fargate. , « » (MicroVM) multi-tenant . Firecracker Lambda Fargate EC2 , . , , . Firecracker , , . Firecracker , . Linux ext4 . Amazon Firecracker 2017 , 2018 .

unikernel, Firecracker . micro-VM , . , micro-VM Firecracker 5 ~125 2 CPU + 256 RAM. 5 Firecracker .


5. Firecracker

Firecracker KVM, . Firecracker seccomp, cgroups namespaces, , , . Firecracker . , API microVM. virtIO ( ). Firecracker microVM: virtio-block, virtio-net, serial console 1-button , microVM. . , , microVM File Block Devices, . , cgroups. , .

Firecracker Docker Kubernetes. Firecracker , , , . . , , OCI .

OpenStack Kata

, 2015 Intel Clear Containers. Clear Containers Intel VT QEMU-KVM qemu-lite . 2017 Clear Containers Hyper RunV, OCI, Kata. Clear Containers, Kata .

Kata OCI, (CRI) (CNI). (, passthrough, MacVTap, bridge, tc mirroring) , , . 6 , Kata .


6. Kata Docker Kubernetes

Kata . Kata Kata Shim, API (, docker kubectl) VSock. Kata . NEMU — QEMU ~80% . VM-Templating Kata VM . , , , CVE-2015-2877. « » (, , , virtio), .

Kata Firecracker — «» , . , . Firecracker — , , Kata — , . Kata Firecracker. , .

निष्कर्ष

, — .

IBM Nabla — unikernel, .

Google gVisor — , .

Amazon Firecracker — , .

OpenStack Kata — , .

, , . . Nabla , , unikernel-, MirageOS IncludeOS. gVisor Docker Kubernetes, - . Firecracker , . Kata OCI KVM, Xen. .



, , , , .