
Container Snitch يتحقق من العمليات الجارية تحت محرك Docker وينبه إذا تم العثور على أي منها يعمل كـ root.
cnitch (snitch أو container snitch) هو إطار عمل بسيط وأداة سطر أوامر لمراقبة حاويات Docker لتحديد أي عمليات تعمل كمستخدم root.
لماذا هذا أمر سيء؟ إذا لم تكن قد زرت can I haz non-privileged containers? بقلم mhausenblas من قبل، فإنني أوصيك بالذهاب إلى هناك الآن للحصول على جميع المعلومات.
عندما كنت أطور cnitch، صادفت ما اعتقدت أنه خطأ في التطبيق، حيث كان cnitch يبلغ عن نفسه كعملية root داخل حاوية Docker. لم أكن متأكدًا كيف يمكن أن يحدث هذا لأن ملف Dockerfile كان ينص صراحةً على أنني أنشئ مستخدمًا لا يعمل كـ root. بعد الكثير من التصحيح والتحقق، قررت مراجعة ملف Dockerfile مرة أخرى ووجدت هذا:
FROM alpine
RUN adduser -h /home/cnitch -D cnitch cnitch
COPY ./cmd/cnitch /home/cnitch/
RUN chmod +x /home/cnitch/cnitch
#USER cnitch
ENTRYPOINT ["/home/cnitch/cnitch"]
عندما كنت أختبر حاوية التطبيق لمعرفة مشكلة في صلاحيات مقبس Docker، لا بد أنني علقت الأمر USER. يا للروعة! ساعد cnitch في العثور على مشكلة في cnitch نفسه، وهذا سيتم إدراجه بالتأكيد في اختبارات التكامل.
يتصل cnitch بمحرك Docker باستخدام API ويستعلم عن الحاويات قيد التشغيل حاليًا، ثم يفحص العمليات التي تعمل داخل هذه الحاوية ويحدد أيًا منها يعمل كمستخدم root. عند العثور على عملية root، يتم إرسال هذه المعلومات إلى وحدات الإبلاغ القابلة للتكوين، مما يسمح لك بمراجعة هذه المعلومات أو اتخاذ إجراء بشأنها.
2017/07/29 16:04:27 بدء تشغيل Cnitch: مراقبة عمليات Docker على: tcp://172.16.255.128:2376
2017/07/29 16:04:27 التحقق من عمليات root كل: 10s
2017/07/29 16:05:08 فحص الصورة: ubuntu، المعرّف: 7bd489560a310343c39186500daa680290289c27f7a730524a31355a3aaf0430
2017/07/29 16:05:08 >> تحذير: تم العثور على عملية تعمل كـ root: tail -f /dev/null pid: 365
حاليًا، لدى cnitch القدرة على الإبلاغ إلى StatsD و StdOut. خلفيات الإبلاغ قابلة للتوسعة لتسهيل دعم أي خلفية، على سبيل المثال سيكون من السهل نسبيًا بناء خلفية لدعم log stash أو أداة أخرى لتجميع ملفات السجل.
يتم إرسال الاستثناءات إلى نقطة نهاية statsD كعدد باستخدام مقياس cnitch.exception.root_process. يتم أيضًا وضع علامات على المقاييس باسم host لمثيل cnitch واسم container.
مسجل StdOut هو مسجل إخراج بسيط يرسل الاستثناءات المبلغ عنها إلى StdOut.
سواء قمت بتشغيل cnitch في حاوية Docker أو كملف ثنائي، فإنه يحتاج إلى الوصول إلى Docker API عن طريق تعيين عنوان URL للخادم أو مسار المقبس باستخدام متغير البيئة DOCKER_HOST
--hostname=[hostname] الاسم أو عنوان IP الذي سيتم استخدامه لتجميع المقاييس--statsd-server=[hostname:port] URI لمجمع statsd، إذا تم حذفه سيتم تعطيل الإبلاغ إلى statsd--check=[duration مثلاً 10s (10 ثوانٍ)، 1m (دقيقة واحدة)] ، تكرار الفحص الذي سيقوم به snitch لفحص عمليات rootقم بتعيين متغير البيئة DOCKER_HOST إلى API محرك Docker الخاص بك ثم قم بتشغيل snitch مع العلامات المطلوبة.
$ cnitch --hostname=myhost --statsd-server=127.0.0.1:8125 --check=10s
يعمل cnitch في حاوية غير مميزة (non-privileged) وإذا كنت ترغب في استخدام مقبس Docker للوصول إلى API، فأنت بحاجة إلى إضافة مستخدم cnitch إلى مجموعة docker. يمكن تحقيق ذلك من خلال العلامة --group-add، قم بتعيينها إلى معرف المجموعة لمجموعة مستخدمي docker.
على سبيل المثال:
--group-add=$(stat -f "%g" /var/run/docker.sock
مثال باستخدام ملف مقبس Docker للوصول إلى API
$ docker run -i -t --rm \
-v /var/run/docker.sock:/var/run/docker.sock \
--group-add=$(stat -f "%g" /var/run/docker.sock) \
-e "DOCKER_HOST:unix:///var/run/docker.sock" \
quay.io/nicholasjackson/cnitch [options]
إذا كنت تعمل على Mac وتستخدم Docker Machine، فإن مقبس Docker موجود داخل VM مما يعني أنك لا تستطيع استخدام أمر stat لاكتشاف معرف المجموعة.
يوجد مثال على مجموعة Docker Compose داخل مجلد ./example يوضح كيفية تصدير cnitch للبيانات إلى statsd. لتشغيل هذا المثال:
$ cd ./example
$ docker-compose up
بمجرد بدء تشغيل كل شيء، افتح http://[docker host ip]:3000 في متصفح الويب الخاص بك وسترى شاشة تسجيل الدخول إلى Grafana.

سجل الدخول إلى Grafana باستخدام بيانات الاعتماد التالية:
ثم حدد لوحة معلومات cnitch. تظهر هذه اللوحة عمليات root الجاري تشغيلها حاليًا.

إذا كنت لا تستخدم /var/run/docker.sock للتواصل مع مضيف Docker، فستحتاج إلى تغيير بعض الإعدادات داخل ملف ./example/docker-compose.yml لتتناسب مع إعداداتك.
تنفيذ الميزات من Docker Bench Security Script https://github.com/docker/docker-bench-security
[ ] 1.1 التأكد من إنشاء قسم منفصل للحاويات
[ ] 1.2 التأكد من تعزيز أمان مضيف الحاوية
[ ] 1.3 التأكد من أن Docker محدث
[ ] 1.4 التأكد من أن المستخدمين الموثوقين فقط هم من يُسمح لهم بالتحكم في برنامج Docker الخفي
[ ] 1.5 التأكد من تكوين التدقيق لبرنامج Docker الخفي
[ ] 1.6 التأكد من تكوين التدقيق لملفات وأدلة Docker - /var/lib/docker
[ ] 1.7 التأكد من تكوين التدقيق لملفات وأدلة Docker - /etc/docker
[ ] 1.8 التأكد من تكوين التدقيق لملفات وأدلة Docker - docker.service
[ ] 1.9 التأكد من تكوين التدقيق لملفات وأدلة Docker - docker.socket
[ ] 1.10 التأكد من تكوين التدقيق لملفات وأدلة Docker - /etc/default/docker
[ ] 1.11 التأكد من تكوين التدقيق لملفات وأدلة Docker - /etc/docker/daemon.json
[ ] 1.12 التأكد من تكوين التدقيق لملفات وأدلة Docker - /usr/bin/docker-containerd
[ ] 1.13 التأكد من تكوين التدقيق لملفات وأدلة Docker - /usr/bin/docker-runc
[ ] 2.1 التأكد من تقييد حركة مرور الشبكة بين الحاويات على الجسر الافتراضي
[ ] 2.2 التأكد من ضبط مستوى التسجيل على 'info'
[ ] 2.3 التأكد من السماح لـ Docker بإجراء تغييرات على iptables
[ ] 2.4 التأكد من عدم استخدام سجلات غير آمنة
[ ] 2.5 التأكد من عدم استخدام برنامج تشغيل التخزين aufs
[ ] 2.6 التأكد من تكوين مصادقة TLS لبرنامج Docker الخفي
[ ] 2.7 التأكد من تكوين ulimit الافتراضي بشكل مناسب
[ ] 2.8 تمكين دعم مساحة اسم المستخدم
[ ] 2.9 التأكد من تأكيد استخدام cgroup الافتراضي
[ ] 2.10 التأكد من عدم تغيير حجم الجهاز الأساسي إلا عند الحاجة
[ ] 2.11 التأكد من تفعيل التفويض لأوامر عميل Docker
[ ] 2.12 التأكد من تكوين التسجيل المركزي والبعيد
[ ] 2.13 التأكد من تعطيل العمليات على السجل القديم (v1)
[ ] 2.14 التأكد من تفعيل الاستعادة الحية
[ ] 2.15 التأكد من تعطيل البروكسي على مستوى المستخدم
[ ] 2.16 التأكد من تطبيق ملف تعريف seccomp مخصص على مستوى الخفي، إذا لزم الأمر
[ ] 2.17 التأكد من تجنب الميزات التجريبية في الإنتاج
[ ] 2.18 التأكد من تقييد الحاويات من اكتساب صلاحيات جديدة
[ ] 3.x ...
[x] 4.1 التأكد من إنشاء مستخدم للحاوية
[ ] 4.2 التأكد من أن الحاويات تستخدم صورًا أساسية موثوقة
[ ] 4.3 التأكد من عدم تثبيت حزم غير ضرورية في الحاوية
[ ] 4.4 التأكد من فحص الصور وإعادة بنائها لتضمين تصحيحات الأمان
[ ] 4.5 التأكد من تفعيل Content trust لـ Docker
[ ] 4.6 التأكد من إضافة تعليمات HEALTHCHECK إلى صورة الحاوية
[ ] 4.7 التأكد من عدم استخدام تعليمات التحديث منفردة في Dockerfile
[ ] 4.8 التأكد من إزالة أذونات setuid و setgid من الصور
[ ] 4.9 التأكد من استخدام COPY بدلاً من ADD في Dockerfile
[ ] 4.10 التأكد من عدم تخزين الأسرار في Dockerfiles
[ ] 4.11 التأكد من تثبيت الحزم الموثقة فقط
[ ] 5.x ...
[ ] 6.x ...
[ ] 7.x ...