Docker User Namespace: Balancing Security and Volume Access

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

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

تُعد الحلول المؤقتة النموذجية هي:

1. فرض هويات المستخدمين (uIDs) أثناء إنشاء الحاويات في ملفات Dockerfile (غير قابلة للنقل).
2. تمرير مُعرِّف المستخدم (UID) لمستخدم الجهاز الأصلي إلى أمر docker run كمتغير بيئي ثم تشغيل بعض أوامر chown على الحجوم في نص تنفيذي.

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

كان من المأمول أن تكون فضاءات المستخدمين (user namespaces) هي الحلاقة النهائية لهذه المشكلة. وقد قمت بتشغيل بعض الاختبارات باستخدام الإصدار الأخير الذي تم إصداره حديثًا (1.10) مع --userns-remap المعين على حساب سطح المكتب الخاص بي. ومع ذلك، لست متأكدًا مما إذا كان يمكن أن يجعل ملكية الملفات على الحجوم المُرَفَقة أسهل في التعامل معها، وأخشى أن تكون العكس.

لنفترض أني بدأت حاوية بسيطة مع الأمر التالي:

bashCopy code
docker run -ti -v /data debian:jessie /bin/bash
echo 'hello' > /data/test.txt
exit

ثم قمت بفحص المحتوى من الجهاز الأصلي:

bashCopy code
ls -lh /var/lib/docker/100000.100000/volumes//_data/

-rw-r--r-- 1 100000 100000 6 Feb  8 19:43 test.txt

هذا الرقم “100000” هو معرّف فرعي (sub-UID) لمستخدم الجهاز الأصلي، ولكن نظرًا لأنه لا يتطابق مع معرّف المستخدم (UID) الخاص بي، لا يمكنني تحرير test.txt بدون امتيازات. يبدو أن هذا الفرع الفرعي ليس له أي تناغم مع مستخدم النظام العادي خارج Docker. إنه لا يتميز إلى الوراء.

إذا، هل هناك طريقة لتشغيل Docker بتمكين فضاءات المستخدمين (user namespace) (لتحسين الأمان)، مع السماح لمستخدم الجهاز الأصلي الذي يقوم بتشغيل Docker بامتلاك الملفات التي تم إنشاؤها على الحجوم؟

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

في المحاولة السابقة للتحقق من ملكية الملفات، تبين أن الفرع الفرعي (sub-UID) المُعين لـ Docker لا يتمتع بالتطابق مع المستخدم العادي على مستوى النظام. ولذلك، تصبح الحلول التقليدية التي تتضمن محاولة تحقيق التناغم بين مُعرِّفات المستخدمين على الجهاز الأصلي وداخل الحاوية تقريبًا غير فعَّالة.

في سياق استخدام فضاءات المستخدمين، يمكنك أن تفكر في استخدام خاصية --userns-remap لإعادة تعيين المُعرِّفات للمستخدمين داخل الحاويات. ولكن يجب الانتباه إلى أن هذا قد يؤدي إلى تحديات جديدة فيما يتعلق بالوصول إلى الملفات على الحجوم.

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

بشكل عام، قد تحتاج إلى النظر في إعدادات فضاءات المستخدمين بعناية، والبحث عن حلول تقنية تمكن من الوصول السهل لملفات الحجوم دون التضحية بمستوى الأمان. قد تشمل هذه الحلول استخدام أوامر معينة مثل chown داخل الحاوية بعد إطلاقها، أو تحديد خيارات الحجوم بطريقة تسمح بتوافق المُعرِّفات بشكل أفضل.

إن فهم التفاعل بين فضاءات المستخدمين وإدارة الحجوم في Docker يعد أمرًا أساسيًا لضمان تجربة استخدام فعَّالة وآمنة.