تقوية تشغيل Docker: ‏Rootless وseccomp وأقل الصلاحيات

تقوية تشغيل Docker لا تعتمد على Flag سحرية واحدة. ضع الـDaemon خلف أصغر حدود صلاحية عملية، وشغّل التطبيق بهوية غير Root، وأسقط كل Linux Capability لا يحتاجها، وأبقِ seccomp وAppArmor أوSELinux مفعّلة، وامنع اكتساب صلاحيات جديدة، واجعل Root Filesystem للقراءة فقط مع مسارات كتابة صريحة. يناسب هذا الدفاع متعدد الطبقات الخدمات الدائمة وCI Workers التي تنفذ مدخلات غير موثوقة؛ لكنه ليس بديلًا عن VM أوSandbox أقوى عندما يكون المستأجر أوالكود عدائيًا فعلًا.

تم التحقق من وثائق Docker الرسمية ووثائق Linux Kernel المرجعية في 6 أكتوبر 2026. توثق المصادر الآليات والإعدادات الافتراضية؛ أما نموذج التهديد وترتيب الإطلاق وبوابات التحقق أدناه فهي توصيات هندسية.

ابدأ من نموذج التهديد لا من قائمة إعدادات

تشترك الحاويات في Kernel المضيف. تعزل Namespaces رؤية العمليات والشبكات وMounts والمستخدمين، وتقيد Cgroups الموارد؛ لكن أيًا منهما لا يمنح الحاوية Kernel منفصلة. حدّد ما يسيطر عليه المهاجم: بيانات الطلب فقط، أوحزمة تنفذ عند الإقلاع، أوكود عشوائي داخل الحاوية، أوالصورة، أوDocker API نفسها. كلما اقتربت السيطرة من صلاحيات المشغّل احتجت حدًا أقوى.

غالبًا تكفي حاوية عادية بخدمة عامة مع Non-root User وملفات Docker الأمنية الافتراضية إذا كانت تعالج طلبات مألوفة. أما Code Runner متعدد العملاء فيحتاج Node Pool مخصصة وغالبًا VM أوSandbox لكل نطاق ثقة. والحاوية التي تصل إلى Docker Socket تستطيع مطالبة الـDaemon بإنشاء حاويات Privileged أوتركيب مسارات المضيف، لذلك عامل هذا الـSocket كصلاحية على مستوى المضيف لا كواجهة تطبيق مريحة.

اختر حد الـDaemon: Rootless أوuserns-remap أوVM

يشغّل Docker Rootless الـDaemon والحاويات معًا دون Root داخل User Namespace. تميزه Docker عن `userns-remap` حيث تُعاد خريطة هويات الحاوية لكن يبقى الـDaemon بصلاحية Root. يقلل Rootless أثر اختراق الـDaemon أوRuntime، لكنه يحتاج نطاقات UID/GID فرعية ويغير افتراضات الشبكات والتخزين وBind Mounts والعمليات المميزة.

تعيد User Namespace Remapping ربط Container Root بـUID مرتفع وغير مميز على المضيف. تفيد عندما يتوقع التطبيق UID 0 داخل الحاوية لكن لا يجب أن يكون Root على المضيف. تضيف تعقيدًا في ملكية مسارات المضيف، وتنصح Docker بتجنب Bind Mounts التي تتطلب وصول المستخدم المعاد ربطه إلى موارد لا يملكها بأمان.

مصفوفة القرار العملية: اختر Rootless لمحطات التطوير والخدمات وBuilders المعزولة التي لا تحتاج خصائص المضيف المميزة؛ واختر Rootful Docker مع `userns-remap` عندما تحتاج توافق الـDaemon لكن تريد نزع امتياز Container Root؛ واختر VM أوSandbox مخصصة عندما يكون الكود غير موثوق بين العملاء، أوتعرض Kernel غير مقبول، أوتفرض الأجهزة والخصائص صلاحيات واسعة. تقلل Rootless وUser Namespaces العواقب؛ لكنها لا تلغي مشاركة Kernel.

اجعل ملكية UID وBind Mounts صريحة

حدد `USER` رقمية في الصورة أوقيمة `user` عند التشغيل، وأنشئ أدلة التطبيق بملكية مطابقة أثناء البناء. تجعل الهويات الرقمية العقد واضحًا حتى في Minimal Images التي لا تحتوي إدخالات `/etc/passwd` نفسها. لا ترجع إلى Root لمجرد أن Bind Mount أعاد `EACCES`؛ أصلح ملكية المضيف، أواستخدم Named Volume مع مرحلة تهيئة، أوأعد تصميم الـMount.

يجب ألا تتداخل نطاقات الهويات الفرعية. توثق Docker أن `/etc/subuid` و`/etc/subgid` توفر النطاقات المستخدمة في Rootless والحاويات المعاد ربطها. تعامل معها كمورد بنية تحتية، وتحقق منها بعد Provisioning الحسابات، واختبر أدوات النسخ والاستعادة مع الملكية المترجمة. قد يعيد Backup كتابة UIDs العالية بصمت فيجعل Volume المستعاد غير قابل للوصول أويمنح البيانات لنطاق ثقة خاطئ.

فضّل Bind Mount للقراءة فقط للإعدادات والبيانات المرجعية. لا تركب `/` أو`/etc` أوDocker Socket أوContainer Runtime Socket أومجلدات مضيف واسعة داخل حاوية التطبيق. وإذا احتاج Workload جهازًا واحدًا فاكشف هذا الجهاز فقط وبأضيق صلاحية بدل `--privileged`.

أسقط Capabilities قبل إضافة الاستثناءات

تقسم Linux Capabilities صلاحيات Root التقليدية إلى قدرات أضيق. تحتفظ Docker بمجموعة افتراضية للتوافق، وتتيح الإزالة والإضافة عبر `--cap-drop` و`--cap-add`. تحذر وثائق Runtime Privilege من أن `--privileged` يمنح كل القدرات ويكشف أجهزة المضيف ويرخي AppArmor أوSELinux. ليست هذه Flag تصحيح أخطاء صالحة للإنتاج.

ابدأ بـ`cap_drop: [ALL]`. شغّل الخدمة ثم أعد فقط Capability مرتبطة بعملية موثقة. خدمة HTTP على المنفذ 8080 لا تحتاج غالبًا أيًا منها. وقد تحتاج عملية تربط منفذًا منخفضًا إلى `NET_BIND_SERVICE`، مع أن Host حديثًا أوReverse Proxy قد يلغي الحاجة. لا تضف `SYS_ADMIN` كحل عام؛ فهي تغطي عمليات Kernel واسعة وإشارة قوية إلى ضرورة مراجعة المعمارية.

اختبر Process Tree النهائية بما فيها Entrypoint Scripts وإعادة تحميل الشهادات وHealth Probes وShutdown Hooks. قد يبدأ الأب بنجاح ثم يفشل Child لاحقًا لأنه يحاول `chown` أويفتح Raw Socket أويغير الهوية. التقط المنع بدقة، وحدد هل العملية أساسية، ثم عدّل أصغر طبقة.

أبقِ seccomp وHost Security Module في وضع Enforce

ملف seccomp الافتراضي في Docker هو Allowlist؛ تعود الاستدعاءات غير المسموحة بخطأ. تقول الوثائق إنه مهم لمبدأ Least Privilege ولا تنصح بتعطيله. يحجب الملف الافتراضي عمليات حساسة مثل تحميل Kernel Modules وتغيير ساعة المضيف وإنشاء بعض Namespaces وفحص عمليات أخرى.

لا ترد على خطأ `EPERM` واحد بضبط `seccomp=unconfined`. أعد إنتاج Syscall الفاشلة في Staging، وتحقق هل يحتاجها التطبيق فعلًا، وحدّث Libraries قديمة إن أمكن، وأنشئ استثناء صغيرًا خاضعًا للمراجعة فقط عندما تتطلبه الوظيفة. ضع Custom Profile تحت Version Control واختبرها عند تغيير Runtime أوBase Image أوArchitecture.

يتحكم AppArmor أوSELinux بموارد مثل الملفات والإشارات وسلوك الشبكة خارج قائمة Syscalls. يوضح دليل AppArmor في Docker أن الحاويات تستخدم `docker-default` المولدة ما لم تُستبدل، بينما قد تكون الحاوية Privileged بلا Profile صريح في وضع Unconfined. أبقِ الملف الافتراضي Enforcing، وابنِ Custom Profile من الاحتياجات المرصودة، وتحقق من Denials في Audit Logs، ولا تشحن سياسة واسعة بوضع Complain وكأنها حماية.

امنع نمو الصلاحيات وجمّد Root Filesystem

فعّل `no-new-privileges`. يعرضها مرجع Docker run من خلال `--security-opt`، وتشرح وثائق Linux Kernel أن العلم يمنع انتقال `execve` من منح صلاحيات عبر setuid أوsetgid أوFile Capabilities. يكمل Non-root UID لكنه لا يستبدل ضبط Capabilities وSyscalls.

اجعل Root Filesystem للحاوية للقراءة فقط. ثم صرّح بمواقع الكتابة بدقة: Named Volume للبيانات الدائمة و`tmpfs` صغيرة لـ`/tmp` أو`/run`. استخدم `noexec` و`nosuid` وحدًا للحجم وMode مناسبًا عندما يسمح التطبيق. تحول Read-only Root محاولات الاستمرار والكتابة العرضية إلى فشل مباشر، وتكشف المسارات القابلة للكتابة قرارات Backup وQuota وRetention.

لا تجعل `/tmp` Memory Sink بلا حد؛ تستهلك tmpfs الذاكرة ويجب إدخالها في Capacity Planning. أرسل Logs إلى stdout أومسار مخصص بدل Root قابلة للكتابة. ويجب أن تصل Secrets عبر آلية الأسرار في المنصة أوRead-only Mount، لا أن تُنسخ إلى الصورة أوتُكتب في Shared Volume.

خدمة Compose مقواة

يستخدم الخط الأساسي التالي ضوابط متاحة في Docker Compose وDocker Engine. عدّل UID وImage Digest ومسارات الكتابة والموارد وHealthcheck بما يلائم التطبيق، واختبر الصورة نفسها التي ستنشرها.

services:
  api:
    image: registry.example.com/api@sha256:<reviewed-digest>
    user: "10001:10001"
    read_only: true
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
      - seccomp=builtin
      - apparmor=docker-default
    tmpfs:
      - /tmp:rw,noexec,nosuid,size=64m,mode=1777
      - /run:rw,noexec,nosuid,size=16m,mode=0755
    volumes:
      - api-data:/var/lib/api
      - ./config:/etc/api:ro
    pids_limit: 256
    mem_limit: 512m
    cpus: 1.0
    stop_grace_period: 30s
    init: true
    healthcheck:
      test: ["CMD", "/app/healthcheck"]
      interval: 30s
      timeout: 3s
      retries: 3

volumes:
  api-data:

تطلب `seccomp=builtin` ملف Docker المدمج صراحة. أما `apparmor=docker-default` فخاصة بـLinux وAppArmor؛ استخدم LSM المدعوم على المضيف وتحقق أنه في وضع Enforce. لا تصنع حدود الموارد عزلة أمنية وحدها، لكن حدود PID والذاكرة تقلل Blast Radius لهجمات حجب الخدمة. لا تنسخ هذا المثال إلى Windows Containers أوRuntime غير متوافقة قبل ربط كل خيار ببديله.

تحقق باختبارات سلبية وإيجابية

تحتاج الإعدادات الآمنة اختبارات تثبت أن العمليات الممنوعة تفشل. على Staging مطابق للإنتاج، تحقق أن UID ليست صفرًا، وأن Effective Capabilities فارغة أوموثقة، وأن Root Filesystem ترفض الكتابة، وأن tmpfs أوVolumes المعلنة وحدها تقبلها. جرّب انتقال setuid وتأكد أن `no-new-privileges` يمنع اكتساب الصلاحية. وتحقق عبر `docker inspect` وAudit Logs من تطبيق seccomp وAppArmor أوSELinux المتوقع.

اختبر السلوك المطلوب أيضًا: Startup وMigrations وتحميل الشهادات وDNS وOutbound TLS وHealthchecks وMetrics ومعالجة SIGTERM واستعادة Volume. أمن يكسر Shutdown قد يسبب فقد بيانات، وأمن يُعطّل عند الحوادث ليس مستدامًا. احتفظ بـContract Test آلي للصورة حتى لا يعيد تحديث Dependency أوEntrypoint تشغيل Root أويفرض `--privileged` بصمت.

افحص Digest المرفوعة وأرفق Attestations، لكن افصل Runtime Controls عن دليل الصورة. يشرح دليل بناء Docker الآمن Secret Mounts والمدخلات القابلة للتكرار وSBOM وProvenance. يقول دليل البناء ما هي Artifact؛ وتحد قيود التشغيل مما تستطيع فعله بعد الاختراق.

افهم الحدود وانشر تدريجيًا

لا يلائم Rootless خدمة تحتاج فعلًا إدارة أجهزة المضيف أوKernel Modules أوسلوك Host Networking أوعمليات مميزة لا يمكن إعادة تصميمها. وقد تعقد User Namespace Remapping ملكية Bind Mounts وVolumes الموجودة. كما تملك Custom Seccomp أوAppArmor تكلفة صيانة. في خدمة داخلية صغيرة قد تعطي Non-root وno-new-privileges وإسقاط Capabilities والملفات الافتراضية وRead-only Root معظم القيمة دون سياسة خاصة.

لا تضع مستأجرين عدائيين في حاويات عادية على Kernel واحدة وتسمّي Rootless استراتيجية عزل كاملة. استخدم Dedicated Hosts أوVMs أوSandbox للكود العدائي. ولا تعطل افتراضات Docker الأمنية على مستوى الـDaemon لتوافق خدمة Legacy واحدة؛ اعزل الاستثناء، وحدد مالكه وموعد انتهائه، وأضف حدًا تعويضيًا.

نفّذ الإطلاق كطبقات: راقب الكتابات وCapabilities الحالية؛ حوّل التطبيق إلى Non-root؛ أضف `no-new-privileges`؛ اجعل Root Filesystem للقراءة فقط مع Mounts صريحة؛ أسقط Capabilities؛ تحقق من seccomp الافتراضية وLSM المضيف؛ ثم قرر هل Rootless أوUser Namespace Remapping مناسبة للمضيف. استخدم Canary على Traffic ممثلة، واحتفظ بـRollback دقيق لا بوضع Privileged شامل.

قرار الإنتاج

أفضل ملف لتقوية Docker هو أصغر مجموعة صلاحيات تدعم السلوك الموثق للتطبيق. ابدأ بحد مضيف أقوى، وأبعد الـDaemon وContainer Root عن Host Root عندما يكون ذلك عمليًا، وامنع نمو الصلاحيات، وأزل Capabilities، وحافظ على Syscall وLSM Confinement، واكشف التخزين المطلوب فقط، واختبر المسارات المسموحة والممنوعة.

يناسب هذا النمط APIs وWorkers وSchedulers وBuild Agents التي تعمل دون تحكم بالمضيف. انتقل إلى VM أوSandbox متخصصة عندما يتجاوز خطر الكود أوالعميل أوKernel قدرة Shared-kernel Container. واربط خط Runtime بـهندسة السحابة والنشر وعقود Kubernetes Rollout حتى تستمر قواعد Least Privilege نفسها بعد الانتقال إلى Orchestrator.

إعداد: Noor Yasser