سؤال كيفية التعامل مع التحديثات الأمنية داخل حاويات Docker؟


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

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

الأفكار حول بعض الخيارات:

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

لذلك لا يبدو أي من هذه الأساليب مرضياً.


103
2017-07-08 21:54


الأصل


أفضل فكرة لهذا رأيت حتى الآن مشروع ذرية. لا أظن ذلك الى حد كبير على استعداد لوقت الذروة على الرغم من. - Michael Hampton♦
Valko ، ما هو سير العمل الذي انتهى به المطاف؟ أنا أعمل حاويات طويلة الأجل (استضافة php-cgi ، على سبيل المثال) وما وجدته حتى الآن هو: docker pull debian/jessie لتحديث الصورة ، ثم إعادة بناء الصورة (الصور) الموجودة ، ثم إيقاف الحاويات وتشغيلها مرة أخرى (مع الصورة الجديدة). الصور التي أنشأتها لها نفس الاسم مثل الصور السابقة ، لذا يتم البدء عبر البرنامج النصي. أقوم بعد ذلك بإزالة الصور "غير المسماة". أنا أقدر بالتأكيد سير عمل أفضل. - miha
ميكا: يبدو ذلك مشابها لما انتهى بي الأمر. في الأساس تحديث مستمر وإعادة بناء جميع الصور كجزء من صنع إصدارات جديدة. وإعادة تشغيل الحاويات باستخدام الصور الجديدة. - Markus Hallmann
أفضل إجابة هنا يساعد كثيرًا لأن هناك نصًا يحتوي على أوامر رئيسية للقيام بما قاله يوهانس زيمكه تمامًا: - Hudson Santos


الأجوبة:


تطبيق Docker لحزم الصور و "النظام الأساسي" ، هذا صحيح. ولكن عادة ما تتكون الصورة من صورة أساسية والتطبيق الفعلي.

وبالتالي ، فإن الطريقة الأساسية للتعامل مع تحديثات الأمان هي تحديث الصورة الأساسية ، ثم إعادة إنشاء صورة التطبيق.


43
2017-08-12 11:41



شكرا ، هذا يبدو معقولا. مازلت فقط أرغب في تحديث المنصة إذا لم يكن من الضروري أن تتسبب في إعادة تجميع التطبيق بالكامل (على سبيل المثال الحاجة إلى إعادة بناء 100 صورة تطبيق مختلفة بسبب الحصول على تحديث في صورة أساسية واحدة). ولكن ربما يكون هذا أمرًا لا مفر منه مع فلسفة دوكر في تجميع كل شيء معًا داخل صورة واحدة. - Markus Hallmann
ValkoSipuli يمكنك دائمًا كتابة برنامج نصي لأتمتة العملية. - dsljanus
لماذا لا apt-get الترقية ، ترقية dnf ، pacman -syu ، إلخ المكافئ داخل الحاوية؟ يمكنك حتى إنشاء برنامج نصي شل يفعل ذلك وثم تشغيل التطبيق ، ثم استخدم ذلك كنقطة إدخال حاوية بحيث عند تشغيل / إعادة تشغيل الحاوية يقوم بترقية جميع حزمها. - Arthur Kay
ArthurKay سببين: 1) تقوم بتفجير حجم الحاوية ، حيث ستتم إضافة كل الحزم التي تتم ترقيتها إلى طبقة الحاوية مع الاحتفاظ بالحزمة القديمة في الصورة. 2) هزيمة أكبر ميزة للصور (الحاوية): الصورة التي تقوم بها ليست هي نفسها التي تقوم ببناءها / اختباراتها لأنك تقوم بتغيير الحزم في وقت التشغيل. - Johannes 'fish' Ziemke
هناك شيء واحد لا أفهمه: إذا كنت شركة تشتري جزءًا من برنامج يتم شحنه كحاوية رصيف ، فلابد أن تنتظر الشركة المصنعة للبرنامج لإعادة بناء حزمة التطبيق في كل مرة تظهر فيها مشكلة أمنية ؟ ما هي الشركة التي ستتخلى عن السيطرة على نقاط ضعفها المفتوحة بهذه الطريقة؟ - Sentenza


من المفترض أن تكون الحاويات خفيفة الوزن وقابلة للتبادل. إذا كانت الحاوية تحتوي على مشكلة أمان ، فأنت تقوم بإعادة إنشاء نسخة من الحاوية التي تم تصحيحها ونشر الحاوية الجديدة. (تستخدم العديد من الحاويات صورة أساسية قياسية تستخدم أدوات إدارة الحزم القياسية مثل apt-get لتثبيت اعتمادياتها ، وستسحب عملية إعادة البناء التحديثات من المستودعات)

في حين يمكنك تصحيح داخل حاويات ، وهذا لن الحجم بشكل جيد.


6
2017-10-03 19:44





يتم التعامل مع هذا تلقائيا في SUSE Enterprise Linux باستخدام zypper-docker (1)

SUSE / zypper-عامل ميناء

عامل السرعة شركة دوكر


1
2018-05-08 17:05





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


0
2017-07-08 23:23