قائمة تحقق عملية لأمان عزل Docker لاستضافة متعددة المستأجرين

ملخص

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

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

1. تشغيل الحاويات كمستخدم غير جذر

افتراضياً، تعمل الحاويات كجذر داخل الحاوية. إذا حصل المهاجم على صلاحيات الجذر في الحاوية، فسيكون لديه بداية جيدة للهروب. حدد دائماً مستخدماً غير جذر في Dockerfile الخاص بك.

FROM alpine:3.18
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser

في Compose، يمكنك أيضاً تعيين المستخدم مباشرة:

services:
  app:
    image: myapp
    user: "1000:1000"

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

2. إسقاط جميع الصلاحيات وإضافة ما هو مطلوب فقط

تمنح صلاحيات Linux الحاويات امتيازات دقيقة. افتراضياً، تمنح Docker مجموعة من الصلاحيات. أسقط كل شيء وامنح فقط ما هو مطلوب.

services:
  app:
    image: myapp
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE  # if needed

تحذير: صلاحيات مثل SYS_ADMIN أو NET_RAW نادراً ما تكون مطلوبة. قم بتدقيق تطبيقك لتحديد الحد الأدنى من المجموعة. إسقاط جميع الصلاحيات يمنع العديد من نواقل الهروب.

3. تطبيق ملف تعريف Seccomp

يقوم Seccomp (وضع الحوسبة الآمن) بتصفية استدعاءات النظام المتاحة للحاوية. تأتي Docker مع ملف تعريف seccomp افتراضي يحظر استدعاءات النظام الخطيرة مثل clone مع بعض الأعلام. يمكنك تخصيصه بشكل أكبر.

services:
  app:
    image: myapp
    security_opt:
      - seccomp=/path/to/custom-profile.json

قد يحظر ملف التعريف المحسن unshare و ptrace و mount. ابدأ بملف Docker الافتراضي وزد من التقييد. تحذير: يمكن للملفات المقيدة بشدة أن تعطل التطبيقات. اختبر جيداً في بيئة اختبارية. لمزيد من المعلومات حول دفاعات هروب الحاويات، اقرأ الدفاع ضد هروب الحاويات.

4. تمكين إعادة تعيين مساحة اسم المستخدم

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

قم بتمكينه على برنامج Docker الخفي عن طريق تحرير /etc/docker/daemon.json:

{
  "userns-remap": "default"
}

ثم أعد تشغيل Docker. تحذير: لإعادة تعيين مساحة اسم المستخدم عيبان: فهو يكسر تركيبات الحجم عندما لا يتم تكوينها بعناية (الملفات مملوكة للمستخدم المعاد تعيينه) وهو غير متوافق مع بعض برامج تشغيل التخزين مثل overlay2 على النوى القديمة. اختبر جيداً.

5. تعيين حدود الموارد باستخدام Cgroups

تمنع حدود الموارد الحاوية المخترقة من شن هجوم حجب الخدمة ضد المضيف. استخدم cgroups للحد من وحدة المعالجة المركزية والذاكرة وإدخال/إخراج القرص.

services:
  app:
    image: myapp
    deploy:
      resources:
        limits:
          cpus: '0.5'
          memory: 512M

بالنسبة لـ Docker Compose v3، استخدم قسم deploy (يعمل مع swarm أو compose v2). بالنسبة لـ Docker العادي، استخدم --memory و --cpus. تحذير: تعيين حدود منخفضة جداً يمكن أن يسبب عمليات قتل OOM. راقب الاستخدام واضبط وفقاً لذلك.

6. استخدام نظام ملفات الجذر للقراءة فقط

نظام ملفات الجذر للقراءة فقط يمنع المهاجمين من كتابة برامج ضارة أو تعديل ملفات التكوين داخل الحاوية.

services:
  app:
    image: myapp
    read_only: true
    tmpfs:
      - /tmp:noexec,nosuid,size=64m

قم بتركيب tmpfs على الدلائل التي تحتاج إلى إذن الكتابة (مثل /tmp). هذا يجبر جميع البيانات القابلة للكتابة على أن تكون مؤقتة. تحذير: تتطلب بعض التطبيقات تخزيناً مستمراً؛ استخدم الأحجام المسماة لذلك.

المخاطر الشائعة

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

للحصول على نظرة أوسع لأنماط التنسيق، راجع دليلنا حول تصميم بنية Docker متعددة المستأجرين.

الاستنتاج

لا يتطلب مضيف Docker متعدد المستأجرين الآمن أدوات غريبة - فقط الاستخدام الصحيح للميزات المضمنة في Docker. ابدأ بمستخدم غير جذر، وأسقط جميع الصلاحيات، وقم بتطبيق ملف تعريف seccomp، وتمكين إعادة تعيين مساحة اسم المستخدم، وتعيين حدود الموارد، واستخدام نظام ملفات للقراءة فقط. تشكل قائمة التحقق هذه أساساً قوياً يمنع تقنيات الهروب الأكثر شيوعاً. بعد التنفيذ، قم بتشغيل أدوات أمان مثل docker-bench-security للتحقق من تكوينك. تذكر: الأمان عملية وليس منتجاً. مع ظهور ثغرات جديدة في النواة، أعد النظر في إعداداتك. للحصول على صفحات هبوط آلية تعرض خدمة الاستضافة الخاصة بك، استخدم Pagenza ليصبح موقعك مباشراً في دقائق.