في 2024 فشلت image لـ Skylane في مراجعة أمنية أجراها أحد العملاء، مع 140 نتيجة. أقل من خمس منها كانت في كود كتبناه أو استدعيناه. والباقي في حزم صادف أن الـ base image تتضمّنها: مكتبة XML، ومحوّل صور، ووكيل لنقل البريد. لا شيء منها كان يعمل، وكلها كانت مشكلتنا. الـ base image اعتمادية ترثها بالجملة، فاخترها عن قصد.
\n| الـ Base | \nما بداخلها | \nمناسبة لـ | \nانتبه إلى | \n
|---|---|---|---|
node:24 | \nDebian كاملة، ومترجِمات، ومكتبات كثيرة | \nمراحل البناء التي تترجم إضافات أصلية | \nكبيرة؛ وفيها الكثير ليُفحص | \n
node:24-slim | \nDebian مصغّرة + Node | \nمعظم images التشغيل | \nما زال فيها shell وapt | \n
node:24-alpine | \nAlpine Linux (musl) + Node | \nimages صغيرة جدًا | \nالفروق بين musl وglibc | \n
gcr.io/distroless/nodejs24-debian13 | \nNode ومكتبات تشغيله فقط | \nimages إنتاج محصّنة | \nلا shell ولا مدير حزم | \n
خياري الافتراضي لفريق جديد على الـ containers هو slim: صغيرة، ومبنية على glibc فتعمل الوحدات الأصلية الجاهزة، وما زلت تستطيع الدخول إليها بـ docker exec وفتح shell فيها حين تقع أزمة في الإنتاج.
تعطيك Alpine images أصغر، لكنها تستخدم مكتبة C musl بدلًا من glibc. الإضافات الأصلية الجاهزة المترجَمة لـ glibc تفشل في التحميل، أما الفروق الدقيقة في تحليل أسماء DNS وفي حجز الذاكرة فقد سبّبت لفرق كثيرة متاعب في الإنتاج. اخترها حين تكون قد اختبرت شجرة اعتمادياتك كاملة عليها، لا لأن الرقم في صفحة الـ tags أصغر.
\nالـ images من نوع Distroless تحتوي على Node.js والمكتبات التي يحتاج إليها، ولا شيء غير ذلك: لا shell، ولا apt، ولا curl. المهاجم الذي يحصل على تنفيذ كود يجد القليل جدًا ليعمل به، والماسح يجد القليل جدًا ليُبلغ عنه. الثمن هو صعوبة التشخيص. لا تستطيع فتح shell داخلها بـ exec، وستتعلّم طريقة Kubernetes للالتفاف على ذلك، kubectl debug، في الدرس الأخير من هذه الدورة.
افتراضيًا، تعمل العملية داخل الـ container كـ root، أي UID 0. الـ namespaces تحدّ ما يستطيع هذا الـ root رؤيته، لكنه يبقى root في نظر النواة. وإذا اجتمع ذلك مع خلل في النواة أو mount مضبوط خطأً، فهكذا يتحوّل اختراق الـ container إلى اختراق للمضيف. التشغيل كمستخدم بلا صلاحيات يحوّل كثيرًا من تلك الثغرات إلى طرق مسدودة.
\nتأتي الـ images الرسمية لـ Node.js بمستخدم اسمه node رقمه UID 1000. انتقل إليه في مرحلة التشغيل، بعد كل ما يحتاج إلى root:
# …build and deps stages from the previous lesson\n\nFROM node:24-slim AS runtime\nENV NODE_ENV=production\nWORKDIR /app\nCOPY package.json ./\nCOPY --from=deps /app/node_modules ./node_modules\nCOPY --from=build /app/dist ./dist\nUSER node\nEXPOSE 3000\nCMD [\"node\", \"dist/server.js\"]لاحظ ما ليس موجودًا: لا --chown=node:node على عمليات النسخ. تبقى الملفات مملوكة لـ root وقابلة للقراءة من الجميع، فيستطيع التطبيق قراءة كوده لكنه لا يستطيع تغييره. إذا وجد مهاجم ثغرة تنفيذ كود عن بُعد، فلن يستطيع إعادة كتابة dist/server.js ليبقى داخل النظام. امنح التطبيق صلاحية الكتابة فقط حيث يحتاج إليها حقًا، وفضّل /tmp أو volume مُركّبًا لذلك.
هذه مرحلة التشغيل نفسها على distroless. الـ tag :nonroot يعمل بـ UID 65532 دون أي إعداد إضافي، ونقطة الدخول في الـ image هي node أصلًا، لذا لا تذكر CMD إلا السكربت:
FROM gcr.io/distroless/nodejs24-debian13:nonroot AS runtime\nENV NODE_ENV=production\nWORKDIR /app\nCOPY package.json ./\nCOPY --from=deps /app/node_modules ./node_modules\nCOPY --from=build /app/dist ./dist\nEXPOSE 3000\nCMD [\"dist/server.js\"]ما زالت مرحلتا build وdeps تستخدمان node:24-slim؛ وحدها المرحلة المشحونة تتغيّر. أبقِ الإصدار الرئيسي لـ Node متطابقًا عبر المراحل؛ وإلا فإن الوحدات الأصلية (native modules) المترجَمة وفق الـ ABI الخاص بإصدار معيّن من Node ستُحمَّل في إصدار آخر وتفشل عند بدء التشغيل.
تستطيع التأكّد من المستخدم الذي سيعمل به الـ container دون تشغيله:
\ndocker image inspect notes-api:1.0.0 --format '{{.Config.User}}'الـ image تضبط القيم الافتراضية؛ والـ runtime يستطيع تشديدها أكثر:
\ndocker run --rm -p 8080:3000 \\\n --read-only --tmpfs /tmp \\\n --cap-drop ALL \\\n --security-opt no-new-privileges \\\n notes-api:1.0.0الخيار --read-only يجعل نظام الملفات الجذري للـ container غير قابل للتعديل، ولا يبقى قابلًا للكتابة إلا /tmp بوصفه mount صغيرًا في الذاكرة. والخيار --cap-drop ALL يزيل صلاحيات Linux (capabilities) التي تحتاج إليها العمليات المميّزة الخاصة بالـ root. وno-new-privileges يمنع العملية من اكتساب صلاحيات عبر ملفات setuid التنفيذية. في القسم الخامس ستضبط الأشياء نفسها في securityContext ضمن Kubernetes، حيث تصبح سياسة لكل Pod.
الـ image لديك الآن صغيرة وبلا صلاحيات. التالي: كيف تسمّيها بحيث يكون ما تنشره هو بالضبط ما اختبرته.
\n","toc":[{"id":"sec-1","text":"اختيار الـ base","level":2},{"id":"sec-2","text":"توقّف عن التشغيل بصلاحيات root","level":2},{"id":"sec-3","text":"نسخة distroless","level":2},{"id":"sec-4","text":"أحكِم الإغلاق وقت التشغيل","level":2}],"takeaways":["كل حزمة في الـ base image شيء عليك ترقيعه وفحصه والدفاع عنه، لذا ابدأ من أصغر base يعمل عليه تطبيقك فعلًا.","الـ image node:24-slim خيار افتراضي متين؛ وAlpine تستخدم musl بدلًا من glibc، وdistroless تزيل الـ shell ومدير الحزم كليًا.","الـ images الرسمية لـ Node.js تتضمّن مستخدمًا اسمه node (UID 1000)؛ انتقل إليه بـ USER node بعد الخطوات التي تحتاج إلى root.","اترك ملفات التطبيق مملوكة لـ root وللقراءة فقط بالنسبة إلى مستخدم التطبيق، حتى لا تستطيع عملية مخترَقة إعادة كتابة كودها.","أضف تحصينات وقت التشغيل مثل --read-only و--cap-drop ALL وno-new-privileges؛ ولـ Kubernetes الضوابط نفسها في securityContext."],"further":[{"title":"Dockerfile reference: USER","url":"https://docs.docker.com/reference/dockerfile/#user"},{"title":"Docker Engine security","url":"https://docs.docker.com/engine/security/"},{"title":"Building best practices","url":"https://docs.docker.com/build/building/best-practices/"}],"quiz":[{"q":"يعتمد notes-api على حزمة فيها إضافة أصلية (native addon). بعد تغيير الـ base من node:24-slim إلى node:24-alpine، ينهار الـ container عند البدء بخطأ في تحميل ملف .node. ما السبب المرجّح؟
node:24-alpine موجودة وتشغّل Node 24 دون مشاكل. المشكلة في مكتبة C، لا في إصدار Node."},{"text":"الـ image تحتاج إلى EXPOSE حتى تُحمَّل الوحدات الأصلية.","why":"التعليمة EXPOSE توثيق للمنافذ. لا علاقة لها بتحميل المكتبات المشتركة."},{"text":"Alpine تعمل افتراضيًا كمستخدم غير root، وهذا يمنع الوحدات الأصلية.","why":"images Node المبنية على Alpine تعمل كـ root افتراضيًا، مثل images Debian. الصلاحيات ليست المشكلة هنا."},{"text":"الإضافة مترجَمة لتعمل مع glibc، وAlpine تستخدم musl، فلا يمكن تحميل الملف التنفيذي.","why":"صحيح. الملفات التنفيذية الجاهزة تستهدف glibc غالبًا. أعِد بناء الإضافة داخل مرحلة بناء على Alpine، أو ابقَ على base يستخدم glibc مثل slim."}],"answer":3},{"q":"أي تغيير يجعل notes-api يعمل بمستخدم غير root في الـ image الرسمية لـ Node.js؟
","options":[{"text":"أضفUSER node في مرحلة التشغيل بعد الخطوات التي تحتاج إلى root.","why":"صحيح. الـ image الرسمية تنشئ المستخدم node (UID 1000). والتعليمات وعملية الـ container بعد USER تعمل بهذا المستخدم."},{"text":"أضف RUN su node قبل CMD.","why":"الأمر su داخل خطوة RUN لا يؤثّر إلا في shell تلك الخطوة. الـ container ما زال يبدأ كـ root."},{"text":"أضف ENV USER=node.","why":"هذا يضبط متغيّر بيئة اسمه USER. لا يغيّر المستخدم الذي تعمل به العملية."},{"text":"انشر الـ container على منفذ أعلى من 1024.","why":"رقم المنفذ لا يغيّر المستخدم. سيبقى الـ container يعمل كـ root."}],"answer":0},{"q":"تنقل notes-api إلى gcr.io/distroless/nodejs24-debian13:nonroot. أي CMD صحيحة؟
CMD ["node", "dist/server.js"]","why":"نقطة الدخول في image Node من distroless هي node أصلًا، فهذا سيشغّل node node dist/server.js ويفشل في العثور على وحدة اسمها node."},{"text":"CMD node dist/server.js","why":"صيغة shell تحتاج إلى /bin/sh، والـ images من نوع distroless لا تحتوي على shell، فلا يستطيع الـ container البدء."},{"text":"CMD ["dist/server.js"]","why":"صحيح. نقطة الدخول هي node، فتقدّم CMD مسار السكربت وسيطًا (argument) لها."},{"text":"CMD ["npm", "start"]","why":"الـ images الخاصة بـ Node من distroless تشحن الـ runtime الخاص بـ Node، لا npm. وأنت تريد تجنّب npm في موقع PID 1 على أي حال."}],"answer":2},{"q":"لماذا نترك ملفات dist/ في notes-api مملوكة لـ root مع أن العملية تعمل كمستخدم node؟
node، يستطيع قراءة الكود لكنه لا يستطيع تعديله أو زرع ملفات فيه.","why":"صحيح. جعل الملفات للقراءة فقط بالنسبة إلى مستخدم التطبيق يقلّص ما يستطيع الاستغلال تغييره. امنح صلاحية الكتابة فقط للمجلدات التي يجب على التطبيق الكتابة فيها."},{"text":"لأن الملفات المملوكة لـ root أصغر حجمًا في الـ image.","why":"ملكية الملف بضعة بايتات من البيانات الوصفية في الحالتين."},{"text":"لأن Kubernetes يرفض الـ images التي ملفاتها مملوكة لمستخدم غير root.","why":"لا يوجد في Kubernetes قاعدة كهذه. يستطيع أن يشترط أن تكون العملية غير root، وهذا ما تفعله أصلًا."}],"answer":1}],"exercise":{"kind":"spot-bug","language":"dockerfile","code":"# syntax=docker/dockerfile:1\n# (build and deps stages as in the previous lesson)\nFROM node:24-slim AS runtime\nENV NODE_ENV=production\nWORKDIR /app\nCOPY package.json ./\nCOPY --from=deps /app/node_modules ./node_modules\nCOPY --from=build /app/dist ./dist\nUSER node\n# temporary: fixes EACCES writing /app/tmp\nUSER root\nEXPOSE 3000\nCMD [\"node\", \"dist/server.js\"]","bugLines":[11],"title":"الإصلاح المؤقت الذي وصل إلى الإنتاج","prompt":"رصدت مراجعة أمنية في هذه الـ image الملاحظة التالية: “container process runs as UID 0”. كاتب الملف يصرّ على أنه انتقل إلى المستخدم node. اختر السطر الذي يجعل الـ container يعمل بصلاحيات root، وفكّر في الإصلاح الصحيح للخطأ الأصلي.
USER قبل CMD هي التي تحدّد المستخدم الذي يعمل به الـ container.","الحاجة الحقيقية كانت مجلدًا واحدًا قابلًا للكتابة، لا root للعملية كلها."],"explanation":"السطر 11 يعود إلى root بعد USER node، فتبدأ العملية بـ UID 0. أما خطأ EACCES الأصلي فسببه أن /app مملوك لـ root. أنشئ المجلد الوحيد الذي يكتب فيه التطبيق، وسلّمه إلى مستخدم التطبيق، وابقَ غير root:
RUN mkdir -p /app/tmp && chown node:node /app/tmp\nUSER node\nEXPOSE 3000\nCMD [\"node\", \"dist/server.js\"]والأفضل من ذلك أن تجعل التطبيق يكتب في /tmp، القابل للكتابة من كل المستخدمين، والذي يمكن أن يكون mount من نوع tmpfs حين يكون نظام الملفات الجذري للقراءة فقط.