إدارة الحاويات محدودة الصلاحية Rootless Containers باستخدام Podman

ستتعلم في هذا المقال كيفية التعامل مع الحاويات محدودة الصلاحية Rootless Containers باستخدام أداة بودمان. إن كنت تستخدم الحاويات لنشر البرمجيات، أو تستخدم أداة بودمان، أو أنك ترغب في رفع مستوى الأمان عن طريق تشغيل الحاويات محدودة الصلاحية rootless containers، فهذا المقال مناسب لك.

ما هي أداة بودمان Podman

إن أداة بودمان Podman هي أحد منتجات شركة Red Hat طُرِحَت كبديل فعّال عن أداة دوكر Docker ويمكنها أداء 99% من المهام التي تؤديها أداة دوكر. بعض ميزات بودمان هي دعم الحاويات محدودة الصلاحية rootless containers، واستخدام نموذج fork/exec لتشغيل الحاويات، وأنه لا يعمل وفق مبدأ البرنامج الخفي أي إنه daemon-less، وثمة كثير من الميزات الأخرى. أما مزايا الحاويات محدودة الصلاحية فهي واضحة، فهي لا تحتاج لصلاحيات الجذر الذي يملك وصولًا كاملًا إلى جميع موارد وملفات النظام كي تعمل، لذلك فإن تشغيلها أكثر أمانًا.

تشغيل حاويات بودمان محدودة الصلاحية Rootless Containers

إذا كنت متمرسًا في مجال تقنية المعلومات، فمن المحتمل أنك وقعت في أحد الخطأين التاليين:

تشغيل الأمر docker باستخدام Sudo، وبالتالي زيادة امتيازاته.
إضافة مستخدم محدود الصلاحيات non-root إلى مجموعة دوكر docker group. تلك أخطاء تُضِر بأمان النظام بصورة كبيرة؛ لأنك تسمح لبرنامج دوكر الخفي Docker daemon بالوصول إلى جهازك. وهذا يعرضك للخطر بطريقتين:
يعمل برنامج دوكر الخفي (dockerd) كجذر، فإذا كانت ثمة ثغرة أمنية فيه، سيكون نظامك بكامله عرضةً للخطر لأن dockerd هي عملية تابعة للمستخدم الجذر.
قد تحتوي الصورة التي تستخدمها على ثغرات أمنية. تخيّل ماذا سيحدث عند استخدام هذه الصورة بواسطة حاوية تعمل كعملية للمستخدم الجذر root process. يمكن لأحد المخترقين استخدام هذه الصورة للوصول إلى كافة موراد النظام.

الحل بسيط، عليك الامتناع عن تشغيل البرامج بصلاحيات الجذر، حتى لو كنت تثق بها. تذكر أنه لا يوجد شيء آمن بنسبة 100%. وهنا تأتي ميزة بودمان في إدارة الحاويات دون الحاجة إلى الوصول إلى الجذر. فعند تشغيل حاوية باستخدام بودمان كمستخدم غير جذر، لن تحصل تلك الحاوية على امتيازات إضافية، ولن يطلب منك بودمان كلمة مرور sudo.

إليك المزايا التي توفرها أداة بودمان عند إدارة الحاويات محدودة الصلاحية root-less containers:

يمكنك تخصيص مجموعة من الحاويات المشتركة لكل مستخدم محلي. (على سبيل المثال، بإمكانك تشغيل Nextcloud وMariaDB لدى المستخدم nextcloud_user وتشغيل الحاويات Gitea وPostgreSQL لدى المستخدم gitea_user).
حتى لو اختُرِقَت الحاوية، فلا يمكن التحكم بالنظام المضيف بكامله، لأن المستخدم المسؤول عن الحاوية ليس جذرًا. لكنه لن يعود صالحًا للاستخدام.

قيود استخدام حاويات بودمان محدودة الصلاحية

عند استخدام أداتي بودمان ودوكر مع صلاحيات المستخدم الجذر أي بنمط عمل root-full، فأنت تمنحها امتيازات على مستوى المستخدم المسؤول أو المميز super-user. وهذا ليس أمرًا محمودًا، ولكنه يضمن أن جميع الوظائف تعمل على النحو المطلوب. ومن الناحية الأخرى، ثمة بعض القيود على تشغيل حاويات بودمان بدون امتيازات الجذر، إليك أهمها:

لا يمكن تشارك صور الحاويات بين المستخدمين إذا سحب المستخدم user0 صورة الحاوية nginx:stable-alpine فيجب على المستخدم user1 سحبها بنفسه مرةً أخرى. لا توجد لحد الآن طريقة تسمح تشارك الصور بين المستخدمين، لكن يمكنك نسخ الصور من مستخدم لآخر باتباع هذا الدليل من شركة ريد هات Red Hat.
لا يمكن ربط المنافذ ports binding ذوات الأرقام الأدنى من 1024، لكن ثمة طريقة لحل هذه المشكلة.
لا يمكن للحاوية محدودة الصلاحية إرسال الطلب ping لأي من المضيفين hosts. لكن ثمة طريقة لحل هذه المشكلة.
إذا عيّنت معرّفًا مميزًا UID لحاوية بودمان محدودة الصلاحية، فقد يفشل ذلك إن لم تسند المعرّف المميز UID إلى حاوية موجودة مسبقًا. إذًا، من الأفضل تشغيل بودمان من صدفة طرفية (shell) مستخدم موجود، والخيار الأفضل هو إنشاء خدمة systemd لتشغيلها تلقائيًا.

تشغيل حاويات محدودة الصلاحية Rootless Containers باستخدام بودمان

قبل أن تبدأ بتشغيل الحاويات محدودة الصلاحية، ثمة بعض المتطلبات التي عليك توفيرها.

تثبيت حزمة slirp4netns

تُستخدم الحزمة slirp4netns لتوفير خيارات الشبكة لوضع المستخدم user-mode networking لفضاءات أسماء الشبكة. يعد هذا الأمر ضروريًا كي تتفاعل الحاوية محدودة الصلاحية مع أي شبكة وبدونها لا يمكن للحاويات محدودة الصلاحية الاتصال بالإنترنت أو الشبكات الداخلية، مما يحد من فائدتها بشكل كبير. يمكنك تثبيت حزمة slirp4netns على التوزيعات المعتمدة على نظامي ديبيان Debian وأوبنتو Ubuntu باستخدام مدير الحزم apt:

sudo apt install slirp4netns

أما في التوزيعات المعتمدة على نظامي فيدورا Fedora وريد هات Red Hat فاستخدم مدير الحزم dnf لتثبيت الحزمة، على النحو التالي:

sudo dnf install slirp4netns

بالنسبة لمستخدمي Arch Linux فعليك استخدام الأمر pacman على النحو التالي:

sudo pacman -Sy slirp4netns

ضبط subuid و subgid على النحو الصحيح

نظرًا لأن حاويات بودمان محدودة الصلاحية تُشَغّل بواسطة مستخدم موجود على النظام، فإن المستخدم يحتاج إلى إذن لتشغيل هذه الحاوية بمعرّف مميز UID مختلف عن معرف المستخدم. وهذا ينطبق أيضًا على معرّف المجموعة GID. يُمنح كل مستخدم نطاقًا من المعرفات التي يُسمح له باستخدامها، تذكر المعرفات الفريدة UID في الملف ‎‎/etc/subuid‎‎‎‎‎‎، أما معرفات المجموعات GID فتذكر في الملف ‎‎‎‎‎‎‎/etc/subgid‎. وصيغة الملف هي على النحو التالي:

username:initial UID/GID allocated to user:range/size of allowed UIDs/GIDs

فلنفرض أن اسم المستخدم pratham يريد مئة معرّف مميز، والمستخدم krishna يريد ألفًا، إذًا ستكون صيغة الملف ‎/etc/subuid على النحو التالي:

pratham:100000:100
Krishna:100100:1000

يعني هذا أن المستخدم pratham يمكنه استخدام المعرّفات UID من المعرّف 100000 إلى 100100، والمستخدم krishna يمكنه استخدامها بدءً من المعرّف 100100 إلى 101100. يكون هذا عادةً مُعَدًا مسبقًا لكل مستخدم تنشئه، ويُحَدد للنطاق 65536 معرفًا قابلًا للاستخدام سواء كان معرفًا مميزًا UID أم معرّف مجموعة GID. ولكن، يجب أن تضبطه يدويًا في بعض الحالات. ولكن ليس عليك ضبط ذلك يدويًا لكل مستخدم، إذ يمكنك استخدام الأمر usermod لهذا الغرض. إليك صيغة الأمر المطلوبة:

sudo usermod --add-subuids START-RANGE --add-subgids START-RANGE USERNAME

والآن استبدل كل من السلسلة START و RANGE و USERNAME بما يناسبك. ** تنبيه:** احرص على ضبط سماحيات الملفين ‎/etc/subuid و‎/etc/subgid على القيمة 644 وأن يكونا تابعين للمستخدم الجذر root:root.

ربط المنافذ ذات الأرقام الأدنى من 1024

إن استخدمت وكيلًا عكسيًا reverse proxy لبروتوكول SSL، فأنت تعلم أن المنفذين 80 و443 يجب أن يكونا متاحين لمزود الشهادات مثلLet's Encrypt. إذا حاولت ربط المنافذ الأقل من 1024 بحاوية بودمان محدودة الصلاحية، فستلاحظ أن ذلك غير متاح كميّزة جاهزة out of the box. إذ لا يُسمح للمستخدم غير الجذر بربط أي شيء على المنافذ الأدنى من المنفذ 1024. إذًا، كيف يمكن ربط المنافذ الأدنى بحاويات بودمان محدودة الصلاحية؟ عليك أولاً تحديد المنفذ الأدنى الذي تحتاجه. في حالتنا، تحتاج إلى المنفذين 80 و443 لنشر بروتوكول SSL، لذا فإن أقل منفذ تحتاجه هو المنفذ 80. والآن، أضف السطر التالي إلى الملف ‎/etc/sysctl.conf:

net.ipv4.ip_unprivileged_port_start=YOUR_PORT_NUMBER

ما ستفعله هو تغيير قيمة net.ipv4.ip_unprivileged_port_start إلى قيمة أدنى منفذ تحتاجه، إذًا عليك استبدال YOUR_PORT_NUMBER بالقيمة 80 كي تربط المنفذ 80 بحاوية محدودة الصلاحية.

أين توجد صور الحاويات

كما ذكرنا سابقًا فأحد قيود عمل أداة بودمان هي أنها لا تتيح مشاركة الصور بين المستخدمين. فيجب أن يسحب كل مستخدم الصورة، أو يجب نسخ الصورة من مستخدم لآخر. كلا الخيارين سيحجز ضعف أو أضعاف المساحة، حسب عدد نسخ الصور.حيث تُخَزّن صور حاويات المستخدم في المجلد الرئيسي، وبالتحديد داخل المجلد‎ ~/local/share/containers/storage/‎‎

والآن، بعد أن تحققتَ من توفر المتطلبات السابقة، يمكنك تشغيل الأمر podman run من صدفة خارجية non-root user's shell وإنشاء حاوية. سنستخدم خادم Caddy في مثالنا لنشر بروتوكول SSL. شغّل خادم Caddy في حاوية محدودة الصلاحية واربطه بمنفذ أدنى من المنفذ 1024 على النحو التالي:

$ whoami
pratham

$ podman run -d --name=prathams-caddy -p 80:80 -p 443:443 caddy:alpine
e6ed67eb90e6d0f3475d78b287af941bc873f6d62db60d5c13b1106af80dc5ff

$ podman ps
CONTAINER ID  IMAGE                           COMMAND               CREATED        STATUS            PORTS                                     NAMES
e6ed67eb90e6  docker.io/library/caddy:alpine  caddy run --confi...  2 seconds ago  Up 2 seconds ago  0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp  prathams-caddy

$ ps aux | grep caddy
pratham     3022  0.0  0.0  85672  2140 ?        Ssl  06:53   0:00 /usr/bin/conmon --api-version 1 -c e6ed67eb90e6d0f3475d78b287af941bc873f6d62db60d5c13b1106af80dc5ff [...]
pratham     3025  0.1  0.3 753060 32320 ?        Ssl  06:53   0:00 caddy run --config /etc/caddy/Caddyfile --adapter caddyfile

لاحظ أن المستخدم pratham ليس جذرًا وأنه لا حاجة لاستخدام الأمر sudo لزيادة صلاحيات المستخدم. إذ استطعت تشغيل حاوية خادم Caddy محدودة الصلاحية باستخدام أداة بودمان. يُظهِر خرج الأمر ps أن رمز العملية PID ذو الرقم 3022هو عملية تابعة للمستخدم pratham وهي حاوية خادم Caddy (لكننا لم نُظهِر الخرج كاملًا في مثالنا). أما العملية 3025 فهي تابعة child process للعملية 3022 وهما تابعتان للمستخدم نفسه.

الخلاصة

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

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

ترجمة -وبتصرّف- للمقال Getting Started With Rootless Container Using Podman من Linux Handbook.

اقرأ أيضًا