USER

تعليمة USER — المستخدم الذي تعمل به الحاوية USER

USER تحدّد باسم أو UID أي مستخدم تُنفَّذ به تعليمات RUN وCMD وENTRYPOINT التالية — بدونها تعمل الحاوية بصلاحيات root افتراضيًا، وهذا خطر أمني حقيقي.

الصور الرسمية تعمل غالبًا بمستخدم root ما لم تحدّد غيره صراحة — أي ثغرة داخل التطبيق تمنح المهاجم صلاحيات root كاملة داخل الحاوية. USER تحلّ هذا بتحويل التنفيذ لمستخدم محدود الصلاحيات، وهي من أهم خطوات تقوية أمان Dockerfile عمليًا.

تقبل اسم مستخدم أو UID رقمي، مع مجموعة اختيارية بعد نقطتين (:). لو المستخدم المحدَّد لا ينتمي لأي مجموعة معرَّفة، تعمل الحاوية بمجموعة root الافتراضية حتى لو المستخدم نفسه غير جذر — لذلك من الأفضل تحديد المجموعة صراحة أيضًا.

الصياغة

USER <user>[:<group>]
USER <UID>[:<GID>]

📄 مثال

FROM node:20-alpine
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
WORKDIR /app
COPY --chown=appuser:appgroup . .
USER appuser
CMD ["node", "server.js"]

أهم النقاط

الخيار	الوظيفة
USER name	يحوّل التنفيذ لاسم مستخدم موجود مسبقًا في الصورة
USER uid:gid	يقبل أرقامًا مباشرة، مفيد لو لا يوجد مستخدم باسم محدَّد بعد
بدون مجموعة	لو لا ينتمي المستخدم لمجموعة معرَّفة، تُستخدم مجموعة root الافتراضية

💡 نصائح عملية

أنشئ مستخدمًا ومجموعة مخصَّصين بـ addgroup/adduser (أو groupadd/useradd على صور Debian) قبل USER بدل الاعتماد على مستخدم جاهز قد لا يوجد
استخدم COPY --chown مع نفس المستخدم لضمان صلاحية القراءة/الكتابة الصحيحة على الملفّات قبل التبديل بـ USER

⚠️ أخطاء شائعة

نسيان USER تمامًا فتعمل الحاوية بصلاحيات root افتراضيًا حتى لو لا حاجة فعلية لها — أوسع سطح هجوم ممكن
وضع USER قبل COPY فتُنسخ الملفّات بملكية appuser لكنه لا يملك صلاحية كتابة على WORKDIR أصلًا لأنه أُنشئ بـ root قبل التبديل

🎓 تريد فهم الصورة الكاملة خطوة بخطوة؟ ابدأ من مسار DOCKER الكامل بالعربي.