كيفية جعل الحاويات أكثر عزلًا: مراجعة لتقنيات صندوق حماية الحاويات

على الرغم من أن معظم صناعة تكنولوجيا المعلومات تنفذ حلول البنية التحتية القائمة على الحاويات والحلول السحابية ، فمن الضروري أن نفهم القيود المفروضة على هذه التقنيات. تقليديًا ، لا يتم عزل Docker و Linux Containers (LXC) و Rocket (rkt) حقًا لأنهما يشتركان في جوهر نظام التشغيل الأصل في عملهما. نعم ، فهي فعالة من حيث الموارد ، ولكن العدد الإجمالي لمتجهات الهجوم المقدرة والخسائر المحتملة من القرصنة لا تزال كبيرة ، لا سيما في حالة البيئة السحابية متعددة المستأجرين التي توجد فيها الحاويات.



يكمن جذر مشكلتنا في ضعف تحديد الحاويات في الوقت الذي يقوم فيه نظام التشغيل المضيف بإنشاء منطقة مستخدم افتراضية لكل منها. نعم ، تم إجراء البحث والتطوير بهدف إنشاء "حاويات" حقيقية مع صندوق رمل كامل. ومعظم الحلول الناتجة تؤدي إلى إعادة هيكلة الحدود بين الحاويات لتعزيز عزلتها. في هذه المقالة ، سننظر في أربعة مشاريع فريدة من IBM و Google و Amazon و OpenStack على التوالي ، والتي تستخدم طرقًا مختلفة لتحقيق نفس الهدف: إنشاء عزلة يمكن الاعتماد عليها. لذلك ، يقوم IBM Nabla بنشر حاويات أعلى Unikernel ، حيث ينشئ Google gVisor نواة ضيف متخصصة ، ويستخدم Amazon Firecracker برنامج Hypervisor خفيف الوزن للغاية لتطبيقات الصندوق الرمل ، وتضع حاويات OpenStack في آلة افتراضية متخصصة مُحسّنة لأدوات التنسيق.

نظرة عامة على تكنولوجيا الحاويات الحديثة

الحاويات هي وسيلة حديثة لحزم ومشاركة ونشر التطبيق. على عكس التطبيق المترابط ، حيث يتم تجميع جميع الوظائف في برنامج واحد ، فإن تطبيقات الحاوية أو الخدمات المصغرة مخصصة للاستخدام الضيق المستهدف وتتخصص في مهمة واحدة فقط.

تتضمن الحاوية كل التبعيات (على سبيل المثال ، الحزم والمكتبات والثنائيات) التي يحتاجها التطبيق لإكمال مهمته المحددة. نتيجة لذلك ، تكون التطبيقات التي يتم تخزينها في حاويات مستقلة عن النظام الأساسي ويمكن تشغيلها على أي نظام تشغيل ، بغض النظر عن الإصدار أو الحزم المثبتة. هذه الراحة تنقذ المطورين من مجموعة كبيرة من العمل على تكييف إصدارات مختلفة من البرامج لأنظمة مختلفة أو عملاء. على الرغم من أن المفهوم ليس دقيقًا تمامًا ، إلا أن العديد من الأشخاص يفضلون التفكير في الحاويات باعتبارها "أجهزة افتراضية خفيفة الوزن".

عندما يتم نشر حاوية على مضيف ، يتم وضع موارد كل حاوية ، مثل نظام الملفات ، والعملية ، ومكدس الشبكة ، في بيئة معزولة فعليًا ولا يمكن للحاويات الأخرى الوصول إليها. تسمح هذه البنية لمئات وآلاف الحاويات بالعمل في وقت واحد في كتلة واحدة ، ويمكن بعد ذلك تحجيم كل تطبيق (أو خدمة microservice) بسهولة عن طريق تكرار عدد كبير من الحالات.

في هذه الحالة ، يعتمد تخطيط الحاوية على "لبنات بناء" رئيسية: مساحة اسم Linux ومجموعات تحكم Linux (cgroups).

تنشئ مساحة الاسم مساحة مستخدم معزولة فعليًا وتزود التطبيق بموارد نظام مخصصة مثل نظام الملفات ومكدس الشبكة ومعرف العملية ومعرّف المستخدم. في مساحة المستخدم المعزولة هذه ، يتحكم التطبيق في الدليل الجذر لنظام الملفات ويمكن تشغيله كجذر. تسمح هذه المساحة المجردة لكل تطبيق بالعمل بشكل مستقل ، دون التدخل في التطبيقات الأخرى التي تعيش على نفس المضيف. تتوفر ستة مساحات أسماء حاليًا: التحميل ، والتواصل بين العمليات (ipc) ، ونظام UNIX لمشاركة الوقت (uts) ، ومعرف العملية (pid) ، والشبكة والمستخدم. يُقترح استكمال هذه القائمة بمساحتين إضافيتين: الوقت و syslog ، لكن مجتمع Linux لم يقرر بعد المواصفات النهائية.

توفر Cgroups قيود موارد الأجهزة وتحديد الأولويات ومراقبة التطبيق والتحكم فيه. مثال على موارد الأجهزة التي يمكنهم التحكم فيها هي المعالج والذاكرة والجهاز والشبكة. عند الجمع بين مساحة الاسم والمجموعات cgroups ، يمكننا تشغيل تطبيقات متعددة بأمان على نفس المضيف ، مع كل تطبيق في بيئته المعزولة - وهي الخاصية الأساسية للحاوية.

يتمثل الاختلاف الرئيسي بين جهاز ظاهري (VM) وحاوية في أن الجهاز الظاهري هو المحاكاة الافتراضية على مستوى الأجهزة ، والحاوية هي المحاكاة الافتراضية على مستوى نظام التشغيل. يحاكي برنامج Hypervisor VM بيئة الأجهزة لكل جهاز ، حيث يحاكي وقت تشغيل الحاوية بدوره نظام التشغيل لكل كائن. تشترك الأجهزة الافتراضية في الأجهزة الفعلية للمضيف ، وتتشارك الحاويات في كل من الجهاز ونظام التشغيل الأساسي. نظرًا لأن الحاويات تشترك بشكل عام مع المزيد من الموارد مع المضيف ، فإن عملها مع دورات التخزين والذاكرة ووحدة المعالجة المركزية يكون أكثر فاعلية من الجهاز الظاهري. ومع ذلك ، فإن العيب في هذا الوصول المشترك هو المشاكل في مستوى أمن المعلومات ، حيث يتم إنشاء الكثير من الثقة بين الحاويات والمضيف. يوضح الشكل 1 الفرق المعماري بين الحاوية والجهاز الظاهري.



بشكل عام ، يؤدي عزل المعدات الافتراضية إلى إنشاء محيط أمان أقوى بكثير من مجرد عزل مساحة الاسم. يعد خطر مغادرة المهاجم لعملية معزولة بنجاح أكبر بكثير من فرصة ترك الجهاز الظاهري بنجاح. سبب زيادة خطر تجاوز بيئة الحاوية المحدودة هو العزل السيئ الذي تم إنشاؤه بواسطة مساحة الاسم والمجموعات cgroups. يقوم نظام Linux بتنفيذها عن طريق ربط حقول الخصائص الجديدة بكل عملية. تشير هذه الحقول في نظام الملفات /proc إلى نظام التشغيل المضيف ما إذا كانت إحدى العمليات يمكنها رؤية أخرى ، أو مقدار موارد المعالج / الذاكرة التي يمكن أن تستخدمها عملية معينة. عند عرض العمليات قيد التشغيل والخيوط من نظام التشغيل الأصل (على سبيل المثال ، الأمر العلوي أو الأمر ps) ، تبدو عملية الحاوية تمامًا مثل أي عملية أخرى. عادة ، لا تعتبر الحلول التقليدية ، مثل LXC أو Docker ، معزولة تمامًا لأنها تستخدم نفس النواة داخل نفس المضيف. لذلك ، ليس من المستغرب أن تحتوي الحاويات على عدد كافٍ من نقاط الضعف. على سبيل المثال ، قد ينتج عن CVE-2014-3519 و CVE-2016-5195 و CVE-2016-9962 و CVE-2017-5123 و CVE-2019-5736 حصول مهاجم على إمكانية الوصول إلى البيانات خارج الحاوية.

تقوم معظم عمليات استغلال kernel بإنشاء ناقل لهجوم ناجح ، لأنها تؤدي عادةً إلى تصعيد الامتياز وتسمح لعملية شبهة بالتحكم خارج مساحة الاسم المقصودة. بالإضافة إلى متجهات الهجوم في سياق الثغرات الأمنية في البرامج ، يمكن أن يلعب التكوين غير الصحيح أيضًا دورًا. على سبيل المثال ، نشر الصور ذات الامتيازات المفرطة (CAP_SYS_ADMIN ، الوصول المميز) أو نقاط التحميل المهمة ( /var/run/docker.sock ) قد يؤدي إلى حدوث تسرب. بالنظر إلى هذه العواقب الكارثية المحتملة ، يجب أن تفهم الخطر الذي تتعرض له عند نشر النظام في مساحة متعددة المستأجرين أو عند استخدام الحاويات لتخزين البيانات الحساسة.

هذه المشاكل تحفز الباحثين على إنشاء محيط أمان أقوى. تتمثل الفكرة في إنشاء حاوية رمل حقيقية معزولة قدر الإمكان عن نظام التشغيل الرئيسي. تشتمل معظم هذه الحلول على تطوير بنية هجينة تستخدم تمييزًا صارمًا بين التطبيق والجهاز الظاهري ، وتركز على تحسين كفاءة حلول الحاويات.

في وقت كتابة هذا التقرير ، لم يكن هناك مشروع واحد يمكن أن يطلق عليه نضجًا بدرجة كافية ليتم قبوله كمعيار ، ولكن في المستقبل ، سيقبل المطورين بلا شك بعضًا من هذه المفاهيم كمفاهيم رئيسية.

نبدأ مراجعتنا مع Unikernel ، أقدم نظام متخصص للغاية والذي يحزم تطبيق ما في صورة واحدة باستخدام مجموعة من مكتبات نظام التشغيل بحد أدنى. أثبت مفهوم Unikernel نفسه أنه أساسي للعديد من المشاريع التي تهدف إلى إنشاء صور آمنة وصغيرة ومثالية. بعد ذلك ، سننتقل إلى النظر في IBM Nabla ، وهو مشروع لإطلاق تطبيقات Unikernel ، بما في ذلك الحاويات. بالإضافة إلى ذلك ، لدينا Google gVisor ، وهو مشروع لإطلاق الحاويات في مساحة نواة المستخدم. بعد ذلك ، سننتقل إلى حلول الحاويات القائمة على الأجهزة الافتراضية - Amazon Firecracker و OpenStack Kata. لتلخيص هذه المشاركة عن طريق مقارنة جميع الحلول المذكورة أعلاه.

Unikernel

لقد أتاح لنا تطوير تقنيات المحاكاة الافتراضية الانتقال إلى الحوسبة السحابية. وضع Hypervisors مثل Xen و KVM الأساس لما نعرفه الآن باسم Amazon Web Services (AWS) و Google Cloud Platform (GCP). على الرغم من أن برامج Hypervisor الحديثة قادرة على العمل مع مئات الأجهزة الظاهرية المدمجة في مجموعة واحدة ، إلا أن أنظمة التشغيل التقليدية متعددة الأغراض لم يتم تكييفها وتحسينها للعمل في مثل هذه البيئة. الغرض من نظام التشغيل للأغراض العامة هو ، أولاً وقبل كل شيء ، دعم والعمل مع أكبر عدد ممكن من التطبيقات المختلفة ، وبالتالي فإن نواة هذه الأجهزة تشمل جميع أنواع برامج التشغيل والمكتبات والبروتوكولات وأجهزة الجدولة وما إلى ذلك. ومع ذلك ، يتم استخدام معظم الأجهزة الظاهرية التي يتم نشرها الآن في مكان ما في السحابة لتشغيل تطبيق واحد ، على سبيل المثال ، لتوفير DNS أو وكيل أو نوع من قاعدة البيانات. نظرًا لأن هذا التطبيق الفردي يعتمد في عمله فقط على جزء محدد وصغير من نواة OS ، فإن كل "التنانير" الأخرى الخاصة به ببساطة تهدر موارد النظام ، وحقيقة وجودها تزيد من عدد المتجهات للهجوم المحتمل. في الواقع ، كلما زاد حجم قاعدة الشفرات ، زاد صعوبة إزالة جميع أوجه القصور والمزيد من نقاط الضعف المحتملة والأخطاء ونقاط الضعف الأخرى. تشجع هذه المشكلة المتخصصين على تطوير أنظمة تشغيل عالية التخصص مع الحد الأدنى من وظائف kernel ، أي لإنشاء أدوات لدعم تطبيق معين.

لأول مرة ، ولدت فكرة Unikernel مرة أخرى في 90s. ثم أخذ شكله كصورة متخصصة لآلة بها مساحة عنوان واحدة يمكنها العمل مباشرة على برامج Hypervisor. يحزم التطبيقات والوظائف الأساسية والمعتمدة على النواة في صورة واحدة. تعد Nemesis و Exokernel أول إصدارين بحثيين من مشروع Unikernel. تظهر التعبئة والتغليف وعملية النشر في الشكل 2.


الشكل 2. أنظمة التشغيل متعددة الأغراض المصممة لدعم جميع أنواع التطبيقات ، بحيث يتم تحميل العديد من المكتبات وبرامج التشغيل مسبقًا. Unikernels هي أنظمة تشغيل متخصصة للغاية مصممة لدعم تطبيق معين.

يقوم Unikernel بتقسيم kernel إلى عدة مكتبات ووضع المكونات الضرورية فقط في الصورة. مثل الأجهزة الافتراضية المعتادة ، ينشر unikernel ويعمل على برنامج VM hypervisor. نظرًا لصغر حجمها ، يمكن أن يتم التحميل بسرعة وأيضًا بسرعة. تتمثل أهم ميزات Unikernel في زيادة الأمان ومساحة صغيرة ودرجة عالية من التحسين والتحميل السريع. نظرًا لأن هذه الصور لا تحتوي إلا على مكتبات تعتمد على التطبيق ، ولا يتوفر غلاف نظام التشغيل إذا لم يكن متصلاً بشكل مقصود ، فإن عدد متجهات الهجوم التي يمكن للمهاجمين استخدامها عليها ضئيل.

وهذا يعني أنه ليس من الصعب على المهاجمين الحصول على موطئ قدم في هذه النوى الفريدة ، ولكن تأثيرهم يقتصر أيضًا على مثيل واحد أساسي. نظرًا لأن حجم صور Unikernel لا يتجاوز بضع ميغابايت ، يتم تنزيلها في عشرات المللي ثانية ، ويمكن أن تعمل المئات من الحالات حرفيًا على مضيف واحد. باستخدام تخصيص الذاكرة في نفس مساحة العنوان بدلاً من جدول صفحات متعدد المستويات ، كما هو الحال في معظم أنظمة التشغيل الحديثة ، يكون لتطبيقات unikernel تأخير وصول أقل للذاكرة مقارنة بالتطبيق نفسه الذي يعمل على جهاز افتراضي افتراضي. نظرًا لأن التطبيقات تأتي مع kernel عند إنشاء الصورة ، يمكن للمترجمين ببساطة إجراء فحص ثابت للكتابة لتحسين الملفات الثنائية.

تحتفظ Unikernel.org بقائمة بمشاريع unikernel. ولكن مع كل ميزاتها وخصائصها المميزة ، لا يتم استخدام unikernel على نطاق واسع. عندما استحوذت Docker على Unikernel Systems في عام 2016 ، قرر المجتمع أن الشركة ستقوم الآن بتعبئة الحاويات فيها. ولكن مرت ثلاث سنوات ، وما زالت لا توجد علامات تكامل. أحد الأسباب الرئيسية لهذا التطبيق البطيء هو أنه لا يوجد حتى الآن أداة ناضجة لإنشاء تطبيقات Unikernel ، ويمكن لمعظم هذه التطبيقات العمل فقط على بعض برامج Hypervisor. بالإضافة إلى ذلك ، قد يتطلب نقل تطبيق إلى unikernel رمز إعادة كتابة يدويًا بلغات أخرى ، بما في ذلك إعادة كتابة مكتبات kernel التابعة. من المهم أيضًا أن تكون المراقبة أو تصحيح الأخطاء في unikernels إما مستحيلة أو يكون لها تأثير كبير على الأداء.

جميع هذه القيود تمنع المطورين من التحول إلى هذه التكنولوجيا. تجدر الإشارة إلى أن unikernel والحاويات لها العديد من الخصائص المتشابهة. كل من الأول والثاني عبارة عن صور غير قابلة للتركيز بدرجة عالية ، مما يعني أنه لا يمكن تحديث المكونات الموجودة فيها أو إصلاحها ، أي أنه يتعين عليك دائمًا إنشاء صورة جديدة لتصحيح التطبيق. اليوم ، يشبه Unikernel سلف Docker: ثم لم يكن وقت تشغيل الحاوية متاحًا ، وكان على المطورين استخدام الأدوات الأساسية لبناء بيئة تطبيق معزولة (chroot و unhare و cgroups).

إب نبلة

مرة واحدة ، اقترح باحثون من IBM مفهوم "Unikernel كعملية" - أي تطبيق unikernel الذي سيتم تشغيله كعملية على برنامج مراقبة متخصص. عزز مشروع IBM "حاويات Nabla" محيط أمان unikernel ، واستبدل برنامج Hypervisor الشامل (على سبيل المثال ، QEMU) بتطويره الخاص المسمى Nabla Tender. الأساس المنطقي وراء هذا النهج هو أن المكالمات بين unikernel و hypervisor لا تزال توفر أكثر متجهات الهجوم. هذا هو السبب في أن استخدام برنامج Hypervisor مخصص لـ unikernel مع عدد أقل من مكالمات النظام المسموح بها يمكن أن يعزز محيط الأمان بشكل كبير. تقوم Nabla Tender باعتراض المكالمات التي توجه unikernel إلى برنامج hypervisor ، وترجمتها بالفعل إلى طلبات النظام. في الوقت نفسه ، تحظر سياسة لينكس الخاصة بـ seccomp جميع استدعاءات النظام الأخرى التي ليست ضرورية لكي يعمل Tender. وبالتالي ، تعمل Unikernel بالاشتراك مع Nabla Tender كعملية في مساحة المستخدم الخاصة بالمضيف. أدناه ، في الشكل رقم 3 ، يظهر كيف أن نبلة تنشئ واجهة رقيقة بين unikernel والمضيف.


الشكل 3. لربط Nabla بمنصات تشغيل الحاويات الحالية ، تستخدم Nabla بيئة متوافقة مع OCI ، والتي بدورها يمكن أن تكون متصلاً بـ Docker أو Kubernetes.

يدعي المطورون أن Nabla Tender يستخدم أقل من سبعة مكالمات نظام في عمله للتفاعل مع المضيف. نظرًا لأن مكالمات النظام تعمل كنوع من الجسر بين العمليات في مساحة المستخدم ونواة نظام التشغيل ، فكلما قل عدد مكالمات النظام المتاحة لنا ، قل عدد المتجهات المتاحة لمهاجمة النواة. ميزة أخرى لتشغيل unikernel كعملية هي أنه يمكنك تصحيح هذه التطبيقات باستخدام عدد كبير من الأدوات ، على سبيل المثال ، استخدام gdb.

للعمل مع منصات تزامن الحاوية ، توفر runnc مخصص يتم تنفيذه باستخدام معيار Open Container Initiative (OCI). يحدد الأخير واجهة برمجة التطبيقات (API) بين العملاء (مثل Docker و Kubectl) وبيئة وقت التشغيل (على سبيل المثال ، runc). تأتي runnc أيضًا مع مُنشئ للصور يمكن runnc لاحقًا. ومع ذلك ، نظرًا للاختلافات في نظام الملفات بين الأحاديات والحاويات التقليدية ، لا تتوافق صور runnc مع مواصفات صور OCI ، وبالتالي فإن صور Docker غير متوافقة مع runnc . في وقت كتابة هذا التقرير ، كان المشروع لا يزال في المراحل الأولى من التطوير. هناك قيود أخرى ، على سبيل المثال ، عدم وجود دعم لتركيب / الوصول إلى أنظمة الملفات المضيفة ، وإضافة عدة واجهات شبكة (ضرورية ل Kubernetes) ، أو استخدام صور من صور أحادية unikernel (على سبيل المثال ، MirageOS).

جوجل gVisor

Google gVisor هي تقنية الصندوق الرمل باستخدام Google Cloud Platform Engine (GCP) وميزات السحابة و CloudML. في مرحلة ما ، أدركت Google مخاطر تشغيل تطبيقات غير موثوق بها في البنية التحتية السحابية العامة وعدم كفاءة تطبيقات الصندوق باستخدام الأجهزة الافتراضية. نتيجة لذلك ، تم تطوير نواة مساحة المستخدم لبيئة معزولة من هذه التطبيقات غير الموثوقة. يضع gVisor هذه التطبيقات في صندوق الحماية ، ويعترض جميع مكالمات النظام منها إلى kernel المضيف ويعالجها في بيئة المستخدم باستخدام kernel gVisor. في جوهره ، فإنه يعمل كمزيج من مجموعة الضيف والمراقب الفائق. يوضح الشكل 4 بنية gVisor.


الشكل 4. تطبيق أنظمة ملفات gVisor kernel // Sentry و gVisor Gofer تستخدم عددًا صغيرًا من مكالمات النظام للتفاعل مع المضيف

ينشئ gVisor محيط أمان قوي بين التطبيق والمضيف الخاص به. وهو يحد من مكالمات النظام التي يمكن أن تستخدمها التطبيقات في مساحة المستخدم. بدون الاعتماد على المحاكاة الافتراضية ، يعمل gVisor كعملية مضيفة تتفاعل بين تطبيق قائم بذاته ومضيف. يدعم Sentry معظم مكالمات نظام Linux وميزات kernel الأساسية مثل تسليم الإشارات ، وإدارة الذاكرة ، ومكدس الشبكة ، وطراز التدفق. يقوم Sentry بتنفيذ أكثر من 70٪ من مكالمات نظام Linux 319 لدعم التطبيقات المحددة في وضع الحماية. ومع ذلك ، يستخدم Sentry أقل من 20 من مكالمات نظام Linux للتفاعل مع kernel المضيف. تجدر الإشارة إلى أن لدى gVisor و Nabla استراتيجية متشابهة للغاية: حماية نظام التشغيل المضيف وكلا هذين الحلين يستخدمان أقل من 10 ٪ من مكالمات نظام Linux للتفاعل مع kernel. لكن عليك أن تفهم أن برنامج gVisor ينشئ نواة متعددة الأغراض ، وعلى سبيل المثال ، تعتمد نبلة على حبات فريدة من نوعها. في الوقت نفسه ، يطلق كلا الحلين نواة ضيف متخصصة في مساحة المستخدم لدعم التطبيقات المعزولة الموثوق بها من قبلهم.

قد يتساءل أحدهم عن سبب حاجة gVisor إلى kernel الخاص به ، عندما يكون Linux kernel مفتوحًا بالفعل ويمكن الوصول إليه بسهولة. , 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. .



, , , , .