حاويات قفص الاتهام هي تقنية حاويات الأكثر شعبية. في البداية ، تم استخدامه بشكل أساسي لبيئات التطوير والاختبار ، وبمرور الوقت تحولت إلى الإنتاج. بدأت حاويات الإرساء في التكاثر في بيئة الإنتاج ، مثل الفطر بعد المطر ، ولكن قلة من أولئك الذين يستخدمون هذه التكنولوجيا فكروا في كيفية نشر حاويات الإرساء بأمان.
استنادًا إلى
OWASP ، قمنا بإعداد قائمة من القواعد ، والتي سيؤدي تنفيذها إلى حماية بيئتك بشكل كبير ، وهو مبني على حاويات Docker.
القاعدة 0
يجب أن يحتوي الجهاز المضيف و Docker على كافة التحديثات الحالية.
للحماية من الثغرات الأمنية المعروفة التي تؤدي إلى الهروب من بيئة الحاوية إلى النظام المضيف ، والتي تؤدي عادةً إلى تصعيد الامتيازات على النظام المضيف ، يعد تثبيت جميع تصحيحات نظام التشغيل المضيف و Docker Engine و Docker Machine في غاية الأهمية.
بالإضافة إلى ذلك ، تستخدم الحاويات (على عكس الأجهزة الافتراضية) النواة بالاقتران مع المضيف ، بحيث يتم تنفيذ النواة المستغلة التي تعمل داخل الحاوية مباشرة في النواة المضيفة. على سبيل المثال ، استغلال تصعيد امتياز kernel (مثل Dirty COW) الذي يعمل داخل حاوية معزولة جيدًا سيؤدي إلى الوصول إلى الجذر على المضيف.
القاعدة 1
لا تسمح بالوصول إلى مقبس برنامج Docker الخفي
تستخدم خدمة Docker (الخفي) مأخذ UNIX /var/run/docker.sock لاتصالات API الواردة.
يجب أن يكون مالك هذا المورد هو المستخدم الجذر. ولا طريقة أخرى. تغيير حقوق الوصول إلى هذا المقبس يكافئ بشكل أساسي منح حق الوصول إلى النظام المضيف.
أيضًا ، يجب ألا تتعثر على مقبس /var/run/docker.sock مع الحاويات ، حيث يمكنك الاستغناء عنها ، لأنه في هذه الحالة ، سيؤدي الإخلال بالخدمة في الحاوية إلى التحكم الكامل في النظام المضيف. إذا كان لديك حاويات تستخدم شيئًا كهذا:
-v /var/run/docker.sock://var/run/docker.sock
أو لرسو السفن:
volumes: - "/var/run/docker.sock:/var/run/docker.sock"
حاجة ملحة لتغيير هذا.
والأخير - لا تسمع
أبدًا - لا تستخدم مأخذ توصيل Docker TCP دون اليقين المطلق الذي تحتاجه ، لا سيما دون استخدام طرق حماية إضافية (على الأقل إذن). بشكل افتراضي ، يفتح مقبس Docker TCP منفذًا على الواجهة الخارجية 0.0.0.0:2375 (2376 ، في حالة HTTPs) ويسمح بالتحكم الكامل في الحاويات ، ومعه نظام المضيف المحتمل.
المادة 2
تكوين مستخدم غير محظوظ داخل الحاوية
إن تكوين حاوية لاستخدام مستخدم غير محتمل هو أفضل طريقة لتجنب هجوم تصعيد الامتياز. يمكن القيام بذلك بطرق مختلفة:
1. باستخدام خيار "-u" الخاص بأمر "عامل التشغيل":
docker run -u 4000 alpine
2. أثناء بناء الصورة:
FROM alpine RUN groupadd -r myuser && useradd -r -g myuser myuser < root-, , > USER myuser
3. تمكين الدعم لـ "مساحة اسم المستخدم" (بيئة المستخدم) في Docker daemon:
--userns-remap=default
اقرأ المزيد عن هذا في
الوثائق الرسمية .
في Kubernetes ، يتم تكوين الأخير في
سياق الأمان عبر خيار runAsNonRoot:
kind: ... apiVersion: ... metadata: name: ... spec: ... containers: - name: ... image: .... securityContext: ... runAsNonRoot: true ...
المادة 3
الحد من قدرات الحاوية
على نظام Linux ، بدءًا من kernel 2.2 ، هناك طريقة للتحكم في إمكانيات العمليات المميزة المسماة
Linux Kernel Capabilities (للحصول على التفاصيل ، انظر الرابط).
يستخدم عامل الميناء مجموعة محددة مسبقًا من ميزات kernel هذه افتراضيًا. ويتيح لك تغيير هذه المجموعة باستخدام الأوامر:
--cap-drop — --cap-add —
أفضل إعداد أمان هو أولاً تعطيل كافة الميزات (--cap-drop all) ، ثم توصيل الميزات الضرورية فقط. على سبيل المثال ، مثل هذا:
docker run --cap-drop all --cap-add CHOWN alpine
والأهم (!): تجنب تشغيل الحاويات بالعلم المميز !!!
في Kubernetes ، يتم تكوين قيد Linux Kernel Capabilities في سياق الأمان عبر خيار الإمكانيات:
kind: ... apiVersion: ... metadata: name: ... spec: ... containers: - name: ... image: .... securityContext: ... capabilities: drop: - all add: - CHOWN ...
المادة 4
استخدم علامة عدم الامتيازات الجديدة
عند بدء تشغيل الحاوية ، من المفيد استخدام علامة --security-opt = عدم الامتيازات الجديدة التي تمنع تصعيد الامتياز داخل الحاوية.
في Kubernetes ، يتم تكوين قيد Linux Kernel Capabilities في سياق الأمان عبر خيار allowPrivilegeEscalation:
kind: ... apiVersion: ... metadata: name: ... spec: ... containers: - name: ... image: .... securityContext: ... allowPrivilegeEscalation: false ...
المادة 5
قم بإيقاف الاتصال بين الحاويات
بشكل افتراضي ، يتم تمكين الاتصال بين الحاويات في Docker ، مما يعني أنه يمكن لجميع الحاويات التواصل مع بعضها البعض (باستخدام شبكة docker0). يمكن تعطيل هذه الميزة عن طريق تشغيل خدمة Docker بعلامة –icc = false.
المادة 6
استخدام Linux Security Modules (وحدة أمان Linux - seccomp و AppArmor و SELinux)
بشكل افتراضي ، يستخدم Docker بالفعل ملفات تعريف لوحدات أمان Linux. لذلك ،
لا تقم أبدًا بتعطيل ملفات تعريف الأمان! الحد الأقصى الذي يمكن القيام به معهم هو تشديد القواعد.
ملف التعريف الافتراضي ل seccomp متاح
هنا .
يستخدم Docker أيضًا AppArmor للحماية ، ويقوم Docker Engine نفسه بإنشاء ملف تعريف افتراضي لـ AppArmor عند بدء تشغيل الحاوية. بمعنى آخر ، بدلاً من:
$ docker run --rm -it hello-world
يبدأ:
$ docker run --rm -it --security-opt apparmor=docker-default hello-world
توفر
الوثائق أيضًا مثالًا لملف تعريف AppArmor لـ nginx ، وهو أمر ممكن تمامًا (ضروري!) لاستخدام:
المادة 7
الحد من موارد الحاوية
هذه القاعدة بسيطة للغاية: من أجل منع الحاويات من التهام جميع موارد الخادم أثناء هجوم DoS / DDoS التالي ، يمكننا تعيين حدود استخدام الذاكرة لكل حاوية على حدة. يمكنك الحد: مقدار الذاكرة ، وحدة المعالجة المركزية ، عدد مرات إعادة تشغيل الحاوية.
لذلك دعونا نذهب بالترتيب.
الذاكرةالخيار -m أو - الذاكرةالحد الأقصى لمقدار الذاكرة الذي يمكن أن تستخدمه الحاوية. الحد الأدنى للقيمة هو 4 أمتار (4 ميجابايت).
الخيار - الذاكرة المبادلةالخيار لتكوين مبادلة (ملف المبادلة). تكوين الماكرة:
- إذا كانت --memory-swap> 0 ، فيجب أيضًا تعيين علامة الذاكرة. في هذه الحالة ، يُظهر مبادلة الذاكرة مقدار إجمالي الذاكرة المتوفرة للحاوية مع المبادلة.
- مثال أبسط. إذا كان --memory = "300m" ، و --memory-swap = "1g" ، فيمكن للحاوية استخدام 300 ميجابايت من الذاكرة و 700 ميجابايت من المقايضة (1g - 300m).
- إذا كان --memory-swap = 0 ، فسيتم تجاهل الإعداد.
- إذا تم ضبط --memory-swap على نفس قيمة --memory ، فلن يكون للحاوية مقايضة.
- إذا لم يتم تحديد - مبادلة الذاكرة ، ولكن - تم تحديد الذاكرة ، فإن عدد المبادلة يساوي ضعف مقدار الذاكرة المحددة. على سبيل المثال ، إذا لم يتم تعيين --memory = "300m" ، و --memory-swap ، فستستخدم الحاوية 300 ميجابايت من الذاكرة و 600 ميجابايت من المقايضة.
- إذا كانت --memory-swap = -1 ، فستستخدم الحاوية جميع المبادلات الممكنة على النظام المضيف.
ملاحظة للمضيفة: الأداة المجانية التي يتم إطلاقها داخل الحاوية لا تُظهر القيمة الحقيقية للتبادل المتاح للحاوية ، ولكن عدد مبادلة المضيف.
الخيار - أم-قتل-تعطيليسمح لك بتمكين أو تعطيل القاتل OOM (نفاد الذاكرة).
تحذير! لا يمكنك إيقاف تشغيل OOM Killer إلا من خلال مجموعة الخيار --memory ، وإلا فقد يحدث أنه مع نفاد الذاكرة داخل الحاوية ، ستبدأ النواة في قتل عمليات النظام المضيف.
خيارات تكوين إدارة الذاكرة الأخرى ، مثل - الذاكرة التبادلية ، و - الذاكرة الاحتياطية ، و - ذاكرة kernel ، هي أكثر لضبط أداء الحاوية.
معالجالخيار - نسخةيحدد الخيار مقدار موارد المعالج المتاحة التي يمكن أن تستخدمها الحاوية. على سبيل المثال ، إذا كان لدينا مضيف به وحدتان من وحدات المعالجة المركزية وقمنا بتعيين - cpus = "1.5" ، فإن الحاوية مضمونة لاستخدام معالج واحد ونصف.
الخيار - cpuset-cpusلتكوين استخدام النوى أو وحدات المعالجة المركزية المحددة. يمكن تحديد القيمة باستخدام واصلة أو فاصلة. في الحالة الأولى ، سيتم الإشارة إلى نطاق النوى المسموح بها ، في النوى المحددة الثانية.
عدد مرات إعادة تشغيل الحاوية --restart=on-failure:<number_of_restarts>
يحدد هذا الإعداد عدد مرات محاولة Docker لإعادة تشغيل الحاوية في حالة تعطلها بشكل غير متوقع. تتم إعادة تعيين العداد إذا تغيرت حالة الحاوية إلى التشغيل.
يوصى بتعيين رقم موجب صغير ، على سبيل المثال ، 5 ، والذي سيتجنب إعادة تشغيل لا نهاية لها من خدمة غير عاملة.
المادة 8
استخدم أنظمة الملفات للقراءة فقط ووحدة التخزين
إذا كان يجب ألا تكتب الحاوية أي شيء في مكان ما ، فأنت بحاجة إلى استخدام نظام الملفات للقراءة فقط قدر الإمكان. هذا سوف يعقد إلى حد كبير حياة متسلل محتمل.
مثال لبدء حاوية مع نظام الملفات للقراءة فقط:
docker run --read-only alpine
مثال على توصيل وحدة التخزين في وضع القراءة فقط:
docker run -v volume-name:/path/in/container:ro alpine
المادة 9
استخدم أدوات تحليل أمان الحاوية
يجب استخدام الأدوات لاكتشاف الحاويات ذات الثغرات الأمنية المعروفة. لا يوجد الكثير منهم حتى الآن ، لكنهم:
• مجاني:
• تجاري:
وبالنسبة إلى Kubernetes ، هناك أدوات لاكتشاف أخطاء التكوين: