يمكنك تشغيل Docker في مرحلة الإنتاج لعدة أشهر دون حدوث مشكلة واضحة. تبدأ الحاويات، وتستجيب التطبيقات، ولا ينكسر أي شيء. ومن ثم، يؤدي منفذ واحد مكشوف أو إذن واحد تمت تهيئته بشكل خاطئ إلى إنشاء موطئ قدم لا يتعين على المهاجم كسبه. لا تبدو معظم الأخطاء الأمنية في Docker وكأنها أخطاء حتى يحدث خطأ ما.
تتناول هذه المقالة التكوينات المحددة التي تعرض بيئات الحاويات للخطر، وما تتيحه كل واحدة منها للمهاجم، وتختتم بقائمة مرجعية يمكنك تشغيلها مقابل الإعداد الخاص بك اليوم.
لماذا يعتبر Docker Security أصعب مما يبدو؟
تشعر الحاويات بالعزلة. عندما تبدأ واحدة، فإنها تدير مساحة العملية الخاصة بها، ومن داخلها، لا توجد الحاوية التالية. تحصل على العزلة، لكنها جزئية فقط. تتشارك الحاويات في نواة المضيف، مما يعني أن العملية داخل الحاوية يمكن، في ظل ظروف معينة، أن تصل إلى النظام المضيف بالكامل.
يتم تكوين سفن Docker لراحة المطورين، وليس لتقوية الإنتاج. الوصول إلى الجذر قيد التشغيل. جميع المنافذ قابلة للربط بجميع الواجهات. لا مراقبة وقت التشغيل. يقبل معظم المطورين هذه الإعدادات، ويشحنون الحاوية، ويستمرون. وهذا نهج معقول للبدء؛ إنه ليس وضعًا أمنيًا نهائيًا.
وفق تقرير ريد هات لحالة أمان Kubernetes لعام 2024، قامت 67% من المؤسسات بتأخير أو إبطاء نشر التطبيقات بسبب المخاوف الأمنية الخاصة بالحاويات أو Kubernetes. هذا الاحتكاك عادة لا يكون من الهجمات. إنه من الفرق التي تكتشف أن إعدادات الحاوية الخاصة بها تحتاج إلى تقوية لم يتم دمجها فيها.
غالبًا ما نرى حاويات تعمل في مرحلة الإنتاج بنفس التكوين الموجود على الجهاز المحلي للمطور. هذا هو المكان الذي تميل فيه الأخطاء الأمنية في Docker إلى التفاقم بهدوء، مع عدم وجود أعراض مرئية حتى يتم تدقيق شيء ما أو فشله.
الأخطاء التي تخلق هذه الفجوات محددة ويمكن التنبؤ بها ويمكن تجنبها في الغالب، بدءًا من مستوى التكوين.
الأخطاء الشائعة في تكوين عامل ميناء
لا تبدأ معظم خروقات الحاويات باستغلال يوم الصفر. يبدأون بإعداد التكوين في اليوم الأول، دون التفكير كثيرًا في التعرض للشبكة أو نطاق الامتيازات.
تم تصميم إعدادات Docker الافتراضية للعمل. الفجوة بين الوظيفية والآمنة هي المكان الذي تتراكم فيه المخاطر الأمنية لحاويات Docker، خاصة في الإعدادات ذاتية الاستضافة التي يتم نشرها ولا تتم إعادة النظر فيها أبدًا.
نرى هذا النمط في كثير من الأحيان: حاويات على خوادم IP عامة مع روابط المنافذ، وإعدادات المستخدم، وتكوينات الشبكة تمامًا كما كانت عند النشر الأولي.
تشغيل الحاويات كجذر
عند بدء تشغيل حاوية Docker دون تحديد مستخدم، فإنها تعمل كجذر. وهذا يعني أن أي عملية داخل الحاوية، بما في ذلك تطبيقك، تتمتع بامتيازات مستوى الجذر داخل مساحة اسم الحاوية.
الجذر الموجود داخل الحاوية ليس هو نفسه الجذر الموجود على المضيف، لكن الفصل ليس مطلقًا. غالبًا ما تتطلب عمليات استغلال تصعيد الامتيازات التي تستهدف وقت التشغيل، مثل التشغيل الموثق جيدًا CVE-2019-5736 وعيوب وقت التشغيل المماثلة، عملية حاوية جذر لتحقيق النجاح.
تعمل الحاويات غير الجذرية على إزالة متطلبات عملية الجذر التي تعتمد عليها تلك الثغرات، مما يؤدي إلى تضييق نطاق الهجوم بشكل كبير بالنسبة لهذه الفئة من الثغرات الأمنية، على الرغم من أنها لا تقضي على مخاطر الهروب من الحاوية بالكامل.
تؤدي إضافة توجيهات المستخدم إلى ملف Dockerfile الخاص بك إلى معالجة هذا الأمر. يتم شحن بعض الصور الرسمية مع مستخدم لا يتمتع بأي امتيازات، ويمكنك تنشيطه باستخدام توجيه المستخدم، ولكن لا يزال الكثير منها يعمل افتراضيًا على الوصول إلى الجذر بدون مستخدم تطبيق جاهز. في هذه الحالات، يمكنك إنشاء المستخدم في ملف Dockerfile قبل التبديل إليه. بالنسبة لمعظم عمليات الإعداد ذاتية الاستضافة، يزيل هذا التغيير الفردي فئة كاملة من مخاطر التصعيد.
تعريض عدد كبير جدًا من المنافذ للإنترنت العام
عند نشر منفذ باستخدام Docker، يكتب Docker قواعد iptables الخاصة به مباشرةً. يتم تشغيل هذه القواعد قبل قواعد جدار الحماية على مستوى المضيف. هذا هو سلوكيات معروفة ينشرها المجتمع و موثق في دليل تصفية حزم Docker، وليس تكوينًا خاطئًا، ويعني أن UFW والأدوات المشابهة لا تحظر ما فتحه Docker بالفعل.
يكتب Docker مباشرة إلى iptables، متجاوزًا الإعدادات الافتراضية لـ UFW وجدار الحماية على العديد من مضيفي Linux. وهذا يعني أن المنفذ المرتبط بـ 0.0.0.0 يمكن الوصول إليه بشكل عام حتى عندما يبدو أن جدار الحماية الخاص بك قد تم تكوينه. لا يزال بإمكان مجموعات الأمان السحابية وقواعد سلسلة DOCKER-USER حظر حركة المرور هذه، لذا يعتمد التعرض الفعلي على إعداد الشبكة المحدد لديك.
قم بربط الخدمات بـ 127.0.0.1 حيثما أمكن، وقم بتوجيه حركة المرور العامة من خلال وكيل عكسي، وانشر فقط ما يتطلب وصولاً خارجيًا حقيقيًا. يعد الوكيل العكسي الطريقة الأكثر موثوقية للتحكم في ما يتم كشفه من خارج المضيف.
تجاهل عزل الشبكة بين الحاويات
يمكن لأي حاوية على تلك الشبكة الوصول إلى أي حاوية أخرى عليها دون قيود. لا يطبق الجسر الافتراضي أي تصفية لحركة المرور بين الحاويات التي تشاركه، ولا تغير معظم الإعدادات هذا التكوين أبدًا.
إذا تم اختراق حاوية واحدة، يصبح هذا الاتصال المفتوح مسار حركة جانبي. يمكن لحاوية الواجهة الأمامية الوصول إلى قاعدة بيانات، أو واجهة برمجة تطبيقات داخلية، أو أي شيء آخر على نفس شبكة الجسر الافتراضية، حتى لو لم يكن هذا الوصول مقصودًا على الإطلاق.
تمنحك الشبكات المعرفة من قبل المستخدم تحكمًا واضحًا في أي الحاويات يمكنها الاتصال، ولكن شبكة مخصصة واحدة مشتركة بين جميع خدماتك لا تزال تسمح بحركة مرور مجانية بين الحاويات. يتطلب العزل الحقيقي وضع الخدمات التي لا ينبغي أن تتحدث مع بعضها البعض على شبكات منفصلة. إن إيقاف تشغيل الجسر الافتراضي هو نقطة البداية، وليس خط النهاية.
تطل على مقبس Docker
يعتبر مقبس Docker الموجود على /var/run/docker.sock واجهة التحكم لمحرك Docker بأكمله. يؤدي تثبيته في حاوية إلى منح تلك الحاوية وصولاً مباشرًا لواجهة برمجة التطبيقات (API) إلى البرنامج الخفي الذي يعمل على المضيف.
ومن خلال هذا الوصول، يمكن للحاوية بدء حاويات جديدة، وتركيب أدلة المضيف، وفحص وتعديل الحاويات قيد التشغيل، والتحكم بشكل فعال في الجهاز المضيف. سطح الهجوم يعادل الجذر على المضيف، ولهذا السبب فإن أي أداة تتطلب الوصول إلى المقبس تستحق تقييمًا دقيقًا.
بالنسبة لمعظم حالات الاستخدام، هناك بدائل أكثر أمانًا: واجهات برمجة التطبيقات المحددة النطاق أو أدوات إدارة عامل الميناء التي لا تتطلب الوصول إلى المقبس. يحمل Docker-in-Docker مقايضاته الأمنية والتشغيلية الخاصة به، وهو ليس بديلاً مباشرًا.
أخطاء التكوين تخلق التعرض الأولي. تحدد اختيارات الصورة والتبعية كيفية تفاقم هذا التعرض بمرور الوقت.
الصورة والأسرار الأخطاء التي تدوم الحاوية
عندما تقوم بإيقاف حاوية ما، فإن أخطاء التكوين بداخلها تتوقف معها. عند إعادة البناء من صورة تحتوي على ثغرة أمنية أو بيانات اعتماد مضمنة، تتم إعادة تشغيل المشكلة مع الحاوية. لا تتم إعادة ضبط الأخطاء على مستوى الصورة بين عمليات النشر.
إنهم يسافرون مع الصورة إلى كل بيئة تسحبها، وكل سجل يخزنها، وكل عضو في الفريق يقوم بتشغيلها. هذا الإصرار يجعل إدارة الصور والأسرار فئة متميزة من المخاطر، تستحق التدقيق بشكل منفصل عن التكوين.
نرى هذا النمط في كثير من الأحيان: صورة تم اختيارها بعناية في بداية المشروع ولم يتم إعادة بنائها مطلقًا منذ ذلك الحين، وهي تنحرف ببطء عن خط الأساس الأمني الذي كانت تمثله في البداية.
استخدام صور غير موثوقة أو قديمة
السجلات العامة مفتوحة لأي شخص. تم توزيع الصور الضارة من خلال Docker Hub التي تحمل أدوات تعدين العملات المشفرة والأبواب الخلفية المضمنة في سجل الطبقات الذي يستمر عبر عمليات إعادة تشغيل الحاوية. التحقق قبل السحب أمر مهم، خاصة بالنسبة للصور من ناشرين غير رسميين أو غير معروفين.
المشكلة المنفصلة هي الجمود. الصورة الرسمية التي قمت بسحبها منذ ستة أشهر ولم يتم إعادة بنائها مطلقًا منذ ذلك الحين تراكمت فيها ثغرات Docker غير المصححة مع كل CVE تم الكشف عنه مقابل حزمه. الصورة ليست مكسورة. انها لم تعد الحالية.
تقرير Sonatype لعام 2024 عن حالة سلسلة توريد البرمجيات وجدت أنه في 95% من الوقت يتم استهلاك أحد المكونات الضعيفة، ويكون الإصدار الثابت متاحًا بالفعل، وتبقى 80% من تبعيات التطبيق غير قابلة للترقية لأكثر من عام. هذا النمط ذو صلة بالصور الأساسية لـ Docker أيضًا، نظرًا لأنها تعتمد على نفس الحزم مفتوحة المصدر.
استخدم الصور الرسمية من الناشرين المعتمدين وقم بتثبيت علامات إصدار محددة بدلاً من الاعتماد على "الأحدث". أنشئ إيقاعًا منتظمًا لإعادة البناء للحفاظ على تحديث صورك.
أسرار الترميز الثابت في ملفات Dockerfiles وإنشاء الملفات
لا تختفي بيانات الاعتماد المكتوبة في تعليمات Dockerfile ENV أو ARG، أو المشفرة في كتلة بيئة Compose، أو التي تم تمريرها كوسائط بناء، أو المخزنة في ملف .env المخصص للتحكم في الإصدار عند إيقاف الحاوية. وتظل في سجل طبقة الصورة أو التحكم بالمصدر، ويمكن لأي شخص الوصول إليها.
يعد هذا أحد أكثر الأخطاء الأمنية التي يتم التغاضي عنها في Docker لأنه لا يسبب مشاكل واضحة أثناء التطوير. يعمل مفتاح API الموجود في تعليمات ENV بشكل صحيح. كما أنها موجودة في مستودعك، ومدمجة في صورتك، وموزعة أينما تنتقل تلك الصورة.
يدعم Modern Docker Compose آلية الأسرار الأصلية التي تقوم بتثبيت بيانات الاعتماد في وقت التشغيل دون دمجها في الصورة. تتبع واجهة برمجة تطبيقات أسرار Docker ومديرو الأسرار الخارجية نفس المبدأ. هذه هي الخيارات التي تحافظ على بيانات الاعتماد خارج عناصر البناء والملفات المخصصة بشكل كامل.
تعد متغيرات بيئة وقت التشغيل تحسينًا لبيانات الاعتماد المشفرة، لكنها لا تزال مكشوفة من خلال فحص Docker للمخرجات والسجلات وتفريغ الأعطال. إنها خطوة للأمام من الأسرار المخبوزة، وليست حلاً نهائيًا.
عدم تحديث صور الحاوية بانتظام
يعد تشغيل نفس الصورة لعدة أشهر عادة شائعة. كل يوم يمر بعد الكشف عن ثغرة أمنية جديدة، ولكن قبل إعادة البناء، تحمل حاوياتك نافذة تعرض تنمو دون أي تغيير مرئي.
قم ببناء جدول إعادة بناء ثابت. قم بأتمتة هذه العملية حيثما أمكن ذلك، وقم بتشغيل أداة فحص الثغرات بشكل دوري على صورك الحالية. الهدف ليس الكمال. إنه يضيق الوقت بين إصدار التصحيح ونشره.
يمكن تقليل أولوية التحكم في الوصول والمراقبة في عمليات النشر السريعة. إنها أيضًا الفئات التي لا يتم اكتشاف الحوادث فيها لفترة أطول.
التحكم في الوصول وفجوات الرؤية
بعد تشغيل الحاوية بتكوين ثابت وصور حالية، تبقى فئتان من الفشل. كلاهما غير مرئي بطبيعته: لن تلاحظ مشكلة ضعف التحكم في الوصول حتى يستخدمه شخص ما، ولن تلاحظ فجوة المراقبة حتى تحتاج إلى التحقق من النشاط الذي لم يتم تسجيله مطلقًا.
نفس الشيء بحث ريد هات 2024 وجدت أن 42% من الفرق تفتقر إلى القدرات الكافية لمعالجة أمن الحاويات والتهديدات ذات الصلة.
ونجد أن فجوات المراقبة تظهر عادةً أثناء التحقيقات في الحوادث، وليس قبلها. بحلول الوقت الذي تصبح فيه الرؤية أولوية، فإنها غالبًا ما تكون استجابة لشيء ما بدلاً من منعه.
مصادقة ضعيفة ولوحات معلومات الإدارة المكشوفة
لا تتطلب لوحة معلومات إدارة الحاوية على عنوان IP عام بدون مصادقة مهاجمًا متطورًا. ويتطلب منهم معرفة العنوان. وهذا مستوى أقل مما تدركه معظم الفرق.
تأتي أدوات المراقبة والإدارة ذاتية الاستضافة عادةً مع واجهة ويب يمكن الوصول إليها من جميع واجهات الشبكة. إن ترك هؤلاء على عنوان IP عام دون مصادقة أمامهم هو بمثابة حاوية مكافئة لترك لوحة الإدارة مفتوحة.
تعتبر المصادقة والوكيل العكسي ووضع الشبكة الخاصة هي الأساس. التحكم في الوصول هو خطوة تكوين تضيفها إلى أي واجهة إدارة، وليس شيئًا يتم تمكينه.
وينطبق نفس المبدأ على إدارة Docker CLI وواجهة المستخدم الرسومية; يحمل الوصول على مستوى المسؤول إلى البرنامج الخفي نفس المخاطر بغض النظر عن الواجهة.
عدم مراقبة ما تفعله حاوياتك
في حالة اختراق إحدى الحاويات، يؤدي نشاط المهاجم إلى إنشاء أثر: تغييرات في سلوك العملية، واتصالات شبكة غير عادية، وتعديلات غير متوقعة على الملفات. وبدون جمع السجلات، لن يكون هذا المسار موجودًا في نموذج يمكنك التصرف بناءً عليه.
تمنحك مجموعة السجلات المركزية، وتسجيل تدقيق الحاويات، وأدوات مراقبة وقت التشغيل البيانات اللازمة لاكتشاف النشاط غير الطبيعي قبل أن يتراكم. الهدف ليس تحليل كل سطر. إنها توفر البيانات عندما تحتاج إلى التحقيق.
إن إعدادات الحاوية التي تعمل بصمت في الإنتاج بدون مسار تسجيل أو تنبيهات لا تتطلب صيانة منخفضة. لم يتم تفتيشها. هاتان حالتان تشغيليتان مختلفتان.
لماذا تعتبر بيئة البنية التحتية مهمة أيضًا؟
يبدأ أمان الحاوية بالتكوين، ولكن التكوين يعمل على رأس البنية التحتية. يؤدي المضيف الذي يحتوي على شبكة تم تكوينها بشكل خاطئ أو موارد مشتركة أو لا توجد تصفية على مستوى الشبكة إلى إنشاء ظروف تؤثر على كل حاوية فوقه. إن الحصول على إعداد الحاوية بشكل صحيح وتكوين الخادم بشكل صحيح هما مهمتان منفصلتان.
يتم تضخيم العديد من الثغرات الأمنية في Docker من خلال الشروط التي ترثها الحاويات نفسها:
- خادم إيجار مشترك دون عزل الأجهزة بين المستأجرين
- نواة مضيفة تعمل دون إصلاح
- مضيف لا يحتوي على تصفية مدمجة على مستوى الشبكة
هذا لا يلغي الحاجة إلى خطوات التكوين المذكورة أعلاه، نظرًا لأن تقوية الحاوية المناسبة أمر مهم بغض النظر عن طبقة البنية التحتية. إن البدء ببنية تحتية معزولة يزيل طبقة واحدة من القلق من المعادلة.
في Cloudzy، نقدم مسارين اعتمادًا على ما يتطلبه الإعداد الخاص بك:
- لينكس فس: بيئة نظيفة لنشر Docker بنفسك وتطبيق خطوات التعزيز الواردة في هذه المقالة
- بورتينر VPS: خيار بنقرة واحدة مع تثبيت Portainer مسبقًا؛ يقوم الخادم بالتمهيد، وأنت بالفعل في لوحة المعلومات
يعمل كلا الخيارين على نفس البنية التحتية: محاكاة KVM الافتراضية، ووحدات المعالجة المركزية AMD Ryzen 9 بتردد يصل إلى 5.7 جيجا هرتز، وذاكرة DDR5، وتخزين NVMe SSD، وشبكة تصل سرعتها إلى 40 جيجابت في الثانية، وحماية DDoS المجانية عبر تصفية BuyVM، عبر 12 موقعًا عالميًا مع وقت تشغيل SLA بنسبة 99.95%.
لإلقاء نظرة أعمق على تشغيل Portainer على VPS، سنغطيه في مقالة مخصصة.
قائمة مرجعية أمنية عملية لعمليات نشر Docker
تأتي أخطاء Docker الأمنية المذكورة أعلاه في الغالب من قرارات التكوين الفردية التي تم اتخاذها مرة واحدة ولم تتم إعادة النظر فيها أبدًا. يؤدي تشغيل قائمة التحقق هذه مقابل إعداد موجود إلى اكتشاف تلك الفجوات. إنه يعمل بمثابة تدقيق، وليس دليل نشر.
تغطي أفضل ممارسات أمان Docker كيفية تأمين حاويات Docker ضد حالات فشل التكوين الأكثر شيوعًا الموضحة أعلاه.
مرجع سريع: جميع الأخطاء التسعة
| خطأ | فئة | إصلاح سطر واحد |
| تشغيل كجذر | إعدادات | يضيف مستخدم التوجيه إلى ملف Dockerfile الخاص بك |
| المنافذ المرتبطة بـ 0.0.0.0 | إعدادات | اربط بـ 127.0.0.1 وقم بالتوجيه عبر وكيل عكسي |
| لا يوجد عزل للشبكة | إعدادات | تقسيم الخدمات عبر شبكات منفصلة محددة من قبل المستخدم بناءً على احتياجات الوصول. |
| تم تركيب مقبس عامل الإرساء | إعدادات | إزالة جبل. استخدام واجهات برمجة التطبيقات أو البدائل ذات النطاق |
| صور غير موثوق بها أو قديمة | صورة | استخدم الصور الرسمية مع علامات الإصدار المثبتة |
| أسرار مشفرة | صورة | انقل بيانات الاعتماد إلى env vars في وقت التشغيل أو إلى مدير الأسرار |
| لا يوجد جدول زمني لإعادة بناء الصورة | صورة | ضبط إيقاع إعادة البناء شهريًا؛ أتمتة حيثما كان ذلك ممكنا |
| لوحات المعلومات غير المصادق عليها | وصول | إضافة المصادقة ونقل واجهات المستخدم الإدارية إلى الشبكات الخاصة |
| لا يوجد جمع سجل الحاوية | وصول | قم بإعداد التسجيل المركزي ومراقبة وقت التشغيل |
نوصي بتشغيله على الإعدادات الموجودة أولاً، حيث من المرجح أن تكون الفجوات موجودة بالفعل.
الحاويات التي تعمل كغير جذر: تحقق من ملفات Dockerfiles الخاصة بك للحصول على توجيهات المستخدم. في حالة عدم وجود أي منها، تعمل الحاوية كجذر.
تقتصر روابط المنفذ على المضيف المحلي أو الوكيل: قم بتشغيل docker ps ومراجعة روابط المنافذ. يمكن الوصول إلى إدخال 0.0.0.0:PORT بشكل عام على الأجهزة المضيفة حيث لا توجد مجموعة أمان أولية أو جدار حماية خارجي أو قاعدة سلسلة DOCKER-USER تحظره.
شبكات الجسر المخصصة المستخدمة: يمكن للحاويات الموجودة على الجسر الافتراضي لـ Docker الوصول إلى بعضها البعض بحرية. لا يزال بإمكان الحاويات الموجودة على نفس الجسر المحدد من قبل المستخدم التواصل مع بعضها البعض، لذا قم بتقسيم الخدمات عبر شبكات منفصلة حسب حدود الثقة للعزل الفعلي.
مقبس Docker غير مثبت في الحاويات: تحقق من إنشاء الملفات وتشغيل الوسائط. إذا ظهر /var/run/docker.sock كمجلد، فتأكد من أنه مطلوب ومقصود.
الصور الأساسية من الناشرين الذين تم التحقق منهم مع الإصدارات المثبتة: A FROM ubuntu:latest يسحب إصدارًا غير محدد ومن المحتمل أن يكون قديمًا. تثبيت على إصدار محدد.
لا توجد أسرار في Dockerfiles أو إنشاء الملفات أو إنشاء الوسائط: يحتفظ سجل طبقة الصورة ببيانات الاعتماد بعد حذف الحاوية. استخدم إنشاء الأسرار أو أسرار Swarm أو إنشاء حوامل سرية أو مدير أسرار خارجي. تعد متغيرات بيئة وقت التشغيل أفضل من القيم المضمنة، ولكنها لا تزال تظهر في فحص المخرجات والسجلات.
تم تحديد جدول إعادة بناء الصورة: الصور القديمة تتراكم نقاط الضعف. يحافظ إيقاع إعادة البناء الشهري على إمكانية التحكم في نافذة التعرض لمعظم الإعدادات.
واجهات الإدارة وراء المصادقة: تعتبر أي لوحة معلومات على عنوان IP عام بدون مصادقة بمثابة نقطة دخول مفتوحة. يفضل وضع الشبكة الخاصة حيثما أمكن ذلك.
سجلات الحاوية التي يتم جمعها: بدون مسار سجل، يعتمد اكتشاف الحوادث على تأثير النظام المرئي. هذه إشارة متأخرة للعمل عليها.
خاتمة
تم تصميم التكوين الافتراضي لـ Docker من أجل الراحة، وليس الأمان. تعود معظم الأخطاء التي تتناولها هذه المقالة إلى الإعدادات التي لم يتم تغييرها مطلقًا بعد النشر الأولي، وليس إلى الهجمات المعقدة.
تكون الإصلاحات في الغالب قرارات تكوين لمرة واحدة: توجيه المستخدم، وتغيير ربط المنفذ، وشبكة مخصصة، وجدولة إعادة البناء. لا يتطلب أي منها أدوات جديدة لمعظم الإعدادات.
الحصول على التكوين الصحيح للحاوية هو المهمة الأولى. البنية التحتية التي يعمل عليها هي الثانية. كلاهما مهم، ولا بديل عن الآخر.
