2.5الأمان الأساسي : غير root والأسرار والفحص
الأساسي في 30 ثانية
- غير root منهجيا : تعمل الحاوية root افتراضيا — فسطران (مستخدم مخصص) يغيّران كل شيء.
- صفر سر في الصورة : COPY أو ENV المجمّد يبقى مقروءا في السجل ويرحل مع push — احقن عند التشغيل، أبدا أثناء البناء.
- قواعد رسمية + فحص منتظم : slim محدثة، وCVE مفحوصة، وإعادة بناء منتظمة — فالأمان إيقاع، لا حالة.
حالة مستمرة — إدير والصورة التي كانت تعمل root
الفصل الأخير : صورة إدير القابلة للإعداد (2.4) جاهزة، لكنها تعمل root، وكان ملف متغيرات يتسكع في السياق، ولم يفحص أحد الطبقات أبدا. قوّى إدير : قاعدة slim رسمية، ومستخدم مخصص (الذي توفره الصورة الرسمية)، وملكية مضبوطة أثناء البناء، وتحقق عبر exec + whoami — فلم يعد root. واستبعد الملفات الحساسة من السياق (.dockerignore)، وحقن الإعداد عند التشغيل، ثم فحص وحدّث القاعدة. وسُلِّم المستوى 2 : مغلف، ومحسّن، ومرقّم، وقابل للإعداد، ومقوّى.
خاتمة الخيط الرابط 2.1-2.4 : تطبيق إدير يعمل غير root، ودون سر، ومفحوص — جاهز لـ Compose (المستوى 3).
1. لا تعمل root بعد اليوم
افتراضيا، عملية الحاوية root : فعند ثغرة يكون الأثر أعظميا. ننشئ مستخدما مخصصا (المستخدم الذي توفره الصورة الرسمية مثل node، مع ضبط الملكية أثناء البناء) ونعلن USER قبل CMD : سطران، وعالم من الفرق. ونتحقق عبر exec … whoami : فيجب أن نرى المستخدم المخصص، لا root. أضاف إدير USER وراقب : وانتهى root « للتبسيط ».
2. صفر سر في الصورة
سر COPY أو ENV في Dockerfile يبقى مقروءا في السجل للطبقات ويرحل مع push الصورة. نحقنه عند التشغيل (متغير -e، أو ملف مُركَّب، أو سر مُدار) ونستبعده من السياق (.dockerignore). فما لم يُصدَّر أو يُضمَّن أبدا لن يتسرب أبدا من السجل. أزال إدير كل سر من Dockerfile والسياق : فالإعداد الحساس يسافر خارج الصورة.
3. افحص قبل النشر
يسرد docker scout (أو Trivy/Grype) CVE الطبقات مع خطورتها. والمنعكس : الانطلاق من قواعد slim رسمية، وتحديث الأوسمة، وإعادة البناء بانتظام — فصورة عمرها 6 أشهر تكدّس الثغرات. وفي الإنتاج، يبقى متغير عند التشغيل ظاهرا عبر inspect : فنفضّل الأسرار المُدارة (ملفات، والمنسّق، والخزنة). فحص إدير، وحدّث، وأعاد البناء، وأعاد الفحص : فالأمان إيقاع.
🔎 مثال ملموس — 🔎 مثال ملموس — تقوية تطبيق Node
تطبيق إدير، بنسخة مقواة ومُتحقق منها :
FROM node:20-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
RUN chown -R node:node /app
USER node
EXPOSE 3000
CMD ["node", "server.js"]
docker scout quickview mon-app:1.0
docker exec -it app whoami # ← node، ليس rootالقراءة : يعمل التطبيق في « node »، والطبقات مفحوصة، والمنفذ يبقى معلَنا ومنشورا عند التشغيل.
الدرس : استبعد .dockerignore الملفات الحساسة قبل البناء نفسه — دون أي سر مضمّن.
مفردات القسم
- USER
- مستخدم التنفيذ المعلَن في Dockerfile (قبل CMD) : فلا تعمل الحاوية root بعدها.
مثال بسيط: أعلن إدير USER node قبل بدء تطبيقه.
ما ليس كذلك: مالك مستودع الكود.
رد فعل: مستخدم مخصص قبل CMD، دائما.
- السر (Secret)
- كلمة مرور أو مفتاح أو رمز : معلومة حساسة يجب ألا تدخل الصورة ولا المستودع أبدا.
مثال بسيط: حقن إدير الإعداد الحساس عند التشغيل، أبدا أثناء البناء.
ما ليس كذلك: مجرد ضبط مثل المنفذ.
رد فعل: الحساس = خارج الصورة وخارج git.
- CVE
- مرجع علني لثغرة معروفة، مع خطورتها : وهو ما تسرده الفاحصات طبقة بطبقة.
مثال بسيط: دوّن إدير CVE الحرجة من فحصه وحدّث القاعدة.
ما ليس كذلك: خطأ إعداد في Dockerfile.
رد فعل: الفحص = سرد CVE.
- سطح الهجوم
- كل ما هو مضمّن وقابل للهجوم في الصورة : نقلّله (slim ومتعدد المراحل وإعادة البناء).
مثال بسيط: سلّم إدير في slim دون عدة : أقل تضمينا، وأقل تعرضا.
ما ليس كذلك: عدد الحاويات المشغَّلة.
رد فعل: أقل تضمينا = أقل تعرضا.
في التطبيق — عمليا — قوِّ صورتك
- أضف USER غير root إلى Dockerfile (قبل CMD) وأعد البناء.
- تحقق عبر exec + whoami (مستخدم مخصص، لا root).
- افحص الصورة ودوّن CVE الحرجة.
- حدّث القاعدة، وأعد البناء، وأعد الفحص : وقارن.
نص جاهز — أعلن صورة مقواة (30 ثانية)
« تعمل الصورة بمستخدم مخصص، مُتحقق منه عبر whoami — فلا root بعدها. ودون أي سر داخلها : فالإعداد الحساس محقون عند التشغيل ومستبعد من السياق. قاعدة رسمية محدثة، وفحص دون حرج، وإعادة بناء منتظمة متوقعة. ويمكن دفعها ونشرها باطمئنان. »
يُقال مع عرض whoami غير root الخاص بإدير ثم تقرير الفحص.
قالب جاهز للنسخ — Dockerfile مقوّى غير root
FROM node:20-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
RUN chown -R node:node /app
USER node
EXPOSE 3000
CMD ["node", "server.js"]صلاحية مكسورة
USER يكسر الكتابة على مجلد : فيضبط إدير الملكية أثناء البناء بدلا من العودة إلى root.
ملف حساس مضمّن
متغيرات مدفوعة مع الصورة : فيزيلها إدير، .dockerignore + حقن عند التشغيل.
فحص منسي
صورة عمرها 6 أشهر لم تُعَد فحصها أبدا : فيحدّث إدير القاعدة، ويعيد البناء، ويعيد الفحص — ويستعيد الإيقاع.
سر ظاهر عند التشغيل
متغير حساس مقروء عبر inspect : فينتقل إدير إلى الأسرار المُدارة (ملفات، والمنسّق) في الإنتاج.
✓ ممارسات جيدة
- مستخدم مخصص منهجي، مُتحقق منه عبر whoami.
- قواعد slim رسمية محدثة.
- إعادة بناء منتظمة (CVE = إيقاع).
✗ أخطاء شائعة
- البقاء root « للتبسيط ».
- تصدير ملف متغيرات فيه أسرار.
- الفحص مرة ثم النسيان.
النقاط الأساسية
- غير root : مستخدم مخصص قبل CMD، سطران، وأثر هائل.
- صفر سر مُصدَر أو مضمّن (محقون عند التشغيل، ومستبعد من السياق).
- نفحص (CVE)، ونحدّث، ونعيد البناء بانتظام.
- أدنى قاعدة رسمية = أدنى سطح هجوم.
تحدي 48 ساعة — طبِّق غدا
قوِّ صورتك 1.0 : مستخدم غير root + whoami مُتحقق منه، و.dockerignore دون ملفات حساسة، وفحص + تحديث + إعادة بناء مقارَنة.
- أستطيع تشغيل صورة غير root (مستخدم + whoami مُتحقق منه).
- أعرف استبعاد كل سر من الصورة والسياق (محقون عند التشغيل).
- أفحص، وأحدّث، وأعيد البناء بإيقاع منتظم.
أسئلة شائعة
USER يكسر صلاحياتي، ماذا أفعل؟
غالبا مجلد مُركَّب في root : اضبط الملكية (chown) أثناء البناء أو وائم UID عند التشغيل. ولا تعد إلى root تسهيلا : أصلح الصلاحية بنظافة وأعد التحقق عبر whoami.
ENV بكلمة مرور عند التشغيل، هل هو آمن؟
أفضل من داخل الصورة، لكنه ظاهر عبر inspect : وفي الإنتاج نفضّل الأسرار المُدارة (ملفات مُركَّبة، والمنسّق، والخزنة). فالتشغيل خطوة فقط، لا حماية.
أي صورة ستسرّب سرا عند push؟