كيفية تعيين قدرات لينكس على استدعاء خدمة وضع سرب عامل الميناء

العربية
#1

أنا أبحث في مفهوم قبو يعمل تحت سرب (1.12.س).

سيتم بدء حاوية واحدة مع:docker run -d --cap-add IPC_LOCK -p 8200:8200 -p 8215:8125 --name vault --volume /vagrant/vault:/vagrant/vault vault server -config=/path/to/vault.hcl

ولكن عندما أريد تشغيل هذا في سرب كخدمة ، يبدو أن هناك أي وسيلة لتحديد IPC_LOCK القدرة ، من أجل تأمين مبادلة مشفرة لخدمة قبو في هذه الحالة.

كيف يمكنني تعيين cap كاب-إضافة الأعلام عند بدء خدمة وضع سرب مع docker service create قيادة?

#2

اعتبارا من 20.10 ، هذا متاح من docker service create مع --cap-add:

$ docker service create --help...      --cap-add list                       Add Linux capabilities      --cap-drop list                      Drop Linux capabilities

أو في ملف إنشاء يستخدم مع docker stack deploy مع نفس بناء الجملة من ملف الإصدار 2:

version: "3.9"services:  app:    image: your-image:tag    cap_add:    - CAP_NAME1    - CAP_NAME2    cap_drop:    - CAP_NAME3    - CAP_NAME4

[الجواب الأصلي من قبل 20.10 ]

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

المناقشة حول هذا الموضوع قد انتهت على جيثب في:

https://github.com/docker/docker/pull/26849#issuecomment-252704844

https://github.com/docker/swarmkit/issues/1030

https://github.com/docker/swarmkit/pull/1722

https://github.com/moby/moby/issues/25885#issuecomment-557790402 و https://github.com/docker/cli/pull/2199

#3

جميع الإجابات الأخرى هنا قديمة. عامل الميناء 20.10.0 وأحدث الآن يدعم تحديد قدرات لخدمات سرب عبر docker service سطر الأوامر و ال دوكر ستاك يمل تنسيق الملف.

في سطر الأوامر ، يمكنك فقط تحديد --cap-add [capability] أو --cap-drop [capability].

وهنا مثال لإضافة القدرة في ملف يمل كومة عامل الميناء:

version: "3.9"services:  your-service:    cap_add:      - CAP_SYS_ADMIN
#4

لقد وجدت حلا لحل المشكلة ويمكنني استخدام cap_net_admin في وضع سرب.

يمكنك تعديل التعليمات البرمجية المصدر وقت التشغيل لإضافة القدرات التي تحتاج إليها (سيكون الإعداد الافتراضي المحلي).

على سبيل المثال أضفت CAP_NET_ADMIN إلى وقت التشغيل الخاص بي (مستعمل nvidia-container-runtime)وانيفيك / نفيديا-حاوية-وقت التشغيل.

بعد ذلك أعيد بناؤها ، بدأت حاوية (استخدام وضع سرب) ، المدخلات: capsh --print و كاب نت أدمين يمكن العثور عليها:

root@25303a54ebb3:/# capsh --printCurrent:=cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_admin,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap+eipBounding set =cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_admin,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcapSecurebits: 00/0x0/1'b0 secure-noroot: no (unlocked) secure-no-suid-fixup: no (unlocked) secure-keep-caps: no (unlocked)uid=0(root)gid=0(root)groups=

لكن هذه الطريقة ليست جيدة.

أنا أيضا لا يمكن تعيين cap_add أو cap_drop في docker-compose.yml، لكن لا يمكنني إيجاد طريقة لحلها.

#5

انظر https://hub.docker.com/r/ixdotai/swarm-launcher

ويستند هذا الريبو على هذا التعليق / الفكرة: https://github.com/moby/moby/issues/25885#issuecomment-573355530

اعتمادا على حالة الاستخدام ، الحل هو ربط جبل /var/run/docker.sock من مضيف (مضيف) السرب إلى الخدمة، ثم قم بتشغيل docker run --privileged ... أو docker run --cap-add ... من الخدمة لتنفيذ الأوامر المميزة الفعلية الخاصة بك. (سيكون لديك لتثبيت عامل الميناء كلي في الصورة للخدمة.) الحاوية الأعمق التي تقوم بتشغيل عامل الميناء بهذه الطريقة سيكون لها امتيازات / قدرات المضيف سرب بدلا من الخدمة ، والخدمة يصبح مجرد طبقة حاوية رقيقة.