Moby: - يجب أن يكون التسجيل غير الآمن على "Docker pull"

نحن ندير سجلات رصيف داخلية غير مؤمنة في جميع بيئات CI والإنتاج. يجب أن أقول أنه سيكون من المفيد جدًا تمكين الوصول إلى جميع السجلات غير الآمنة دون الحاجة إلى سردها واحدة تلو الأخرى. لدينا سجلات متعددة في كل بيئة لـ HA. لقد جعل هذا التغيير الأمور أكثر تعقيدًا بالنسبة لنا. سأقوم بفتح تذكرة مشكلات أخرى لمعالجة ذلك تحديدًا ، لأن هذه المشكلة تتعلق بنقل الخيار إلى السحب بدلاً من الخدمة الخفية.

وهناك القليل من مشكلة الدجاج والبيض عندما لا تستخدم منفذًا ثابتًا لتشغيل السجل.

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

: +1:

لذا أعتقد أن دعم --insecure على سطر الأوامر docker pull ، الذي يؤدي إلى تعطيل عمليات التحقق الأمنية بقوة ، من الواضح أنه بالنسبة لأمر السحب هذا ، من شأنه أيضًا أن يحل مشكلة proppy و octalthorpe ،

abourget ، يجب أيضًا دعمه في واجهة برمجة التطبيقات البعيدة.

يعرض docker-py حاليًا علامة insecure_registry على وظيفة pull ، لكنه يُستخدم فقط لحل نقطة النهاية: https://github.com/docker/docker-py/blob/master/ عامل ميناء / client.py # L794

يبدو أن الجاني هو https://github.com/docker/docker/commit/6a1ff022b0744213ed588d9c16dbb13ce055eda6

لكن لم أتمكن من العثور على العلاقات العامة المقابلة أو القضايا التي تمت مناقشة هذا التغيير فيها.

tiborvass أي أفكار؟

proppy - تم التعامل مع هذا باعتباره ثغرة أمنية

أحتاج إلى التفكير في الآثار المترتبة على مثل هذا التغيير على localhost / 127.0.0.1 ، لكنني لست مهتمًا به بشكل خاص. إنه تكوين غير قياسي وغير مألوف والحل موثق جيدًا.

ewindisch من ناحية أخرى ، هناك الكثير من برنامج Docker daemon قيد التشغيل بالفعل ، مع تشغيل حاوية التسجيل على localhost .

إذا احتاج جميع هؤلاء المستخدمين فعليًا إلى تمرير --insecure-registry localhost:5000 ، فيمكنك أيضًا جعله الخيار الافتراضي.

ewindisch هل لديكم وثائق أو إرشادات حول ما يشكل ثغرة أمنية من فئة الحظر؟ هذا ليس RCE بعيدًا وغير مصدق عليه. لا يبدو الخطر هنا حادًا بما يكفي لتبرير تغيير جذري في إصدار نقطة دون سابق إنذار.

mmdriley - ينطبق التعريف وفقًا لـ Mitre / NST بشكل عام. في هذه الحالة ، يكون هجوم man-in-the-middle قابلاً للتطبيق والذي يسمح بتنفيذ تعليمات برمجية عشوائية غير موثوق بها على الأنظمة المتأثرة ، لذلك نعم ، نحن نصنف هذا على أنه RCE. هذا يعني أنه إذا كنت ستستخدم Docker لسحب الصور من جهاز كمبيوتر محمول في مقهى ، على سبيل المثال ، يمكن لمستخدم آخر لنقطة وصول WiFi هذه تشغيل تطبيقات عشوائية يوفرها أحد المهاجمين. يمكنهم أيضًا الوصول إلى حساب DockerHub الخاص بك أو السجلات الأخرى التي ستصدق عليها.

تحرير: إضافة رابط لوصف CVE: https://groups.google.com/d/msg/docker-user/oYm0i3xShJU/0QbAw9eN9qkJ

نعم ، كنت مخطئًا عندما قلت إن هذا لم يكن RCE. إنه خطأ سيئ ، وشهادة عظيمة على سبب كون التوقيع القوي للصور فكرة رائعة. ومع ذلك ، فإن الاستغلال ليس أمرًا بسيطًا: فهو يتطلب مهاجمًا نشطًا للتسكع في ستاربكس على أمل أن يستخدم شخص قريب Docker عبر شبكة WiFi غير آمنة. لن يتم تسليح هذا بين عشية وضحاها - وبالتالي لا يستحق تغييرًا غير متوافق مع الوراء دون سابق إنذار.

كما تم اقتراحه أعلاه ، كانت هناك طرق واضحة لتحسين الأمان على الفور دون كسر التوافق. على سبيل المثال ، كان تعطيل HTTPS الاحتياطي لـ index.docker.io وعدد قليل من السجلات العامة الشائعة الأخرى من شأنه أن يحل المشكلة بشكل فعال بالنسبة لمعظم المستخدمين. إن إضافة تحذير إلى إخراج وحدة التحكم بأن احتياطي HTTP كان سيخفف من الحالة التفاعلية. سيتم وضع علامة على احتياطي HTTP على أنه مهمل وإزالته ، على سبيل المثال ، إصدار الشهر المقبل. أخيرًا ، من الواضح أن المضيف المحلي و :: 1 ليسا عرضة للخطر.

مرة أخرى ، لم يكن يجب أن أستبعد مدى الثغرة الأمنية ، لكنني قلق من أن عملية الاستجابة والإصلاح لم يضفيا قيمة كافية على عدم كسر العملاء.

نقوم حاليًا بإنشاء / تدمير سجلات عامل الإرساء ديناميكيًا في بيئة لا يتوفر بها FQDN للعديد من هذه الحالات. قد يؤدي دعم خيار مستودع التخزين الآمن للطلبات المتعلقة بالتسجيل (عبر واجهة برمجة التطبيقات البعيدة) إلى إزالة التعقيدات الكبيرة التي أنشأها إصلاح الأمان هذا لنا.

لدينا مشكلة مماثلة مع Docker 1.3.1. نستخدم سجل Docker المحلي (الخاص) على العنوان http: // docker : 5000 /. حتى Docker 1.3.0 كان يعمل بشكل جيد. مع الإصدار 1.3.1 من Docker ، لم يعد يعمل بعد الآن لأن عميل Docker يفترض تلقائيًا أنه يمكن الوصول إلى السجل على HTTPS. لكننا لا نستخدم HTTPS على الإطلاق.

سيكون من الجيد تنفيذ آلية احتياطية تستخدم HTTP إذا كان لا يمكن الوصول إلى خوادم Docker Registry عبر HTTPS.

kruxik إذا كنت تستخدم --insecure-registry docker:5000 عند بدء البرنامج الخفي ، فسيتم الرجوع إلى HTTP.

tiborvass شكرا لك على الاقتراح. انت على حق. ولكن إذا كان لديك الكثير من المطورين مع محطات العمل والدفاتر الخاصة بهم ، فإن تعيين --insecure-registry على كل محطة هو طريقة غير عملية. دعها على الأقل كمعامل اختياري لعمليات السحب / الدفع ستكون كافية بالنسبة لنا ؛)

+1

لقد نجح هذا بالنسبة لنا مع 1.3.0 ، ولكن مع 1.3.1

نسخة عامل ميناء
....
إصدار الخادم: 1.3.1
....
دفع عامل ميناء 10.121.4.236:5000/debian7/consul
-> .... إذا كان هذا التسجيل الخاص يدعم فقط HTTP أو HTTPS بشهادة CA غير معروفة ، فالرجاء إضافة --insecure-registry 10.121.4.236:5000 إلى وسيطات البرنامج الخفي. في حالة HTTPS ، إذا كان لديك حق الوصول إلى شهادة CA الخاصة بالسجل ، فلا داعي للعلامة ؛ ما عليك سوى وضع شهادة CA في

تخفيض
إصدار الخادم: 1.3.0
دفع عامل ميناء 10.121.4.236:5000/debian7/consul
-> تحميل الحاويات دون مشاكل.

بالنسبة للآخرين الذين لديهم مشكلات مع 1.3.0 إلى 1.3.1 ، كان علي إجراء التغييرات التالية لنظام التشغيل OS X باستخدام boot2docker:

$ boot2docker delete #removes old image
$ rm -f ~/.ssh/id_boot2docker* # remove old keys
$ boot2docker init #generates new keys, cert
$ boot2docker up
$ boot2docker ssh
$ # add EXTRA_ARGS="--insecure-registry <YOUR INSECURE HOST>" 
$ # to /var/lib/boot2docker/profile
$ sudo /etc/init.d/docker restart

ثم _يجب_ أن تكون قادرًا على القيام بسحب عامل الإرساء.

إذا كنت تستخدم التين ، فأنت بحاجة أيضًا إلى الشكل 1.0.1 وتقوم بما يلي:

$ fig up --allow-insecure-ssl

mhamrah شكرا! قضيت ساعات في محاولة إصلاح هذا ...

+1 على افتراض أن المضيف المحلي آمن. هل هناك من يعارض هذا فعلا؟

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

سيكون أيضًا استخدام علامة غير آمنة على السحب والدفع أمرًا رائعًا حتى أتمكن من استخدام عنوان IP الخاص بالمربع المتشرد إذا لزم الأمر.

thocking : le بافتراض أن المضيف https://github.com/docker/docker/issues/8898

لأكون صادقًا ، كنت أتساءل أيضًا عن سبب فشل Jenkins Containerbuilds الآلي في دفع ...
(من الجيد أن يكون لديك اختبار قبل طرحه في الإنتاج).
يجب أن أتحقق مما إذا كانت هذه "الميزة" قد تم الإعلان عنها حقًا - وإذا لم يكن الأمر كذلك ، فسوف أكون أكثر جنون العظمة في التغييرات الهائلة الشديدة في سلوك الشياطين.

ما افتقده في هذه المناقشة:
لماذا يجب أن أخبر البرنامج الخفي باستخدام الوضع الآمن / غير الآمن "الافتراضي" لكل مضيف؟

ألا يجب أن يكون إعداد السجل بهذا السلوك الافتراضي أكثر إنتاجية؟
بناءً على الإعداد ، إذا لم يتم إعطاء معلمة --secure أو --insecure ، يجب أن يطلب البرنامج الخفي
إذا كانت الطريقة الآمنة ممكنة وإذا لم يتم استخدام الرجوع إلى غير الآمن.

أحد الأشياء الرئيسية في عامل الإرساء هو أنه سهل الاستخدام تمامًا وإعداد بيئة كاملة. من فضلك لا تقتل هذا التأثير المذهل بمثل هذه "الإصدارات / القرارات" ...

فقط سنتان ...

توجد مشكلات مماثلة هنا لتلك المذكورة أعلاه بما في ذلكjwthomp. لقد أمضيت أكثر من 10 ساعات في محاولة حل هذه المشكلة وفي هذه الأثناء خفضت تصنيفي إلى عامل التحميل 1.3.0.

أقوم بتشغيل سجل عامل الإرساء ضمن Marathon and docker Registry حاليًا "يدعم SSL عن طريق تشغيل nginx كواجهة أمامية" (راجع https://github.com/docker/docker-registry/issues/697) ولكن استخدام nginx كواجهة أمامية هو معقدة من قبل ماراثون تشغيل سجل عامل ميناء على مختلف المضيفين / المنافذ التابعة.

يمكنني تمكين SSL مباشرة داخل السجل (باستخدام GUNICORN_OPTS) ولكن بعد ذلك _ فقط_ يتحدث SSL ولا يمكنه اجتياز اختبارات الصحة Marathon.

لقد قمت بتعديل نظام تكوين Bamboo HAProxy لتهيئة HAProxy أيضًا كواجهة https أمامية لجميع الخدمات بالطريقة التي كان من الممكن أن يكون بها nginx ، ولكن ما زلت أواجه مشكلات مع عامل الشحن في التحقق من صحة الشهادة في السجل الخاص بي ، لذلك لا يزال هذا غير ممكن. لي في هذا الوقت.

من الجيد جدًا الحماية من RCE ولكن يجب أيضًا أن يكون هناك بعض التوافق مع الإصدارات السابقة. علامة على الأقل لبرنامج عامل الإرساء لتحديد جميع السجلات على أنها غير آمنة. يجب أن تكون هناك طريقة لتحديد http أو https كجزء من اسم التسجيل في كل أمر سحب عامل ميناء. في الوقت الحالي ، يبدو أن 1.3.1 يمثل Catch-22 كبيرًا لأي شخص يستخدم سجلًا خاصًا.

@mhamrah https://github.com/boot2docker/boot2docker/pull/630

لطيف - جيد.
يوم الجمعة 14 نوفمبر 2014 الساعة 10:42 صباحًا Ilya Radchenko [email protected]
كتب:

mhamrah https://github.com/mhamrah boot2docker / boot2docker # 630
https://github.com/boot2docker/boot2docker/pull/630

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/docker/docker/issues/8887#issuecomment -63082089.

mhamrah لم أكن مضطرًا إلى إزالة مفاتيح ssh ، إلخ. لقد أضفت للتو السطر المطلوب في / var / lib / boot2docker / profile وأعدت تشغيل عامل الإرساء. شكرا على الاكرامية!

رائع. لقد واجهت مشكلة حتى في الدخول ، أفترض بسبب بعض الإصدارات
عدم التطابق بين عامل تشغيل السفن ISO. لقد تحولت بالفعل إلى استخدام المتشرد +
coreos لدعم عامل الإرساء ، وهو يعمل بشكل جيد. أنت فقط بحاجة إلى ضبط
DOCKER_HOST ، الذي يقوم boot2docker به تلقائيًا.

يوم الخميس 20 تشرين الثاني (نوفمبر) 2014 الساعة 1:52:21 صباحًا Kayvan Sylvan [email protected]
كتب:

mhamrah https://github.com/mhamrah لم يكن علي القيام بإزالة
مفاتيح ssh ، إلخ. لقد أضفت للتو السطر المطلوب
/ var / lib / boot2docker / profile وإعادة تشغيل عامل الإرساء. شكرا على الاكرامية!

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/docker/docker/issues/8887#issuecomment -63768043.

آسف يا شباب ، قصدت الرد في وقت سابق.

مثلما قال ewindisch بالفعل ، لا نريد تشجيع هذا السلوك من جانب العميل. يتمثل الألم الناجم عن طلب العلم كعلم خفي ، في قيام الأشخاص بالفعل بإعداد TLS في سجلهم. وإلا فلن يكون هناك حافز. شكرا لتفهمك.

هناك صورة "رسمية" قائمة على عامل الإرساء لسجل عامل الميناء في سجل عامل الميناء الرسمي. يوصى باستخدامه بدون TLS.

إذا كان Docker يرغب في أن يقوم المستخدمون بإعداد TLS في السجل الخاص بهم ، فلن يكون من المنطقي موازنة "الألم الناجم عن" مع "تقليل الألم" المساوي والعكس من خلال توفير صورة عامل إرساء رسمية يتم تعيينها افتراضيًا لتوفير TLS؟

تضمين التغريدة أنت تتجاهل حالة مطور البرامج الداخلية خلف الجدار الناري. لذا الآن يتعين علي إما إعداد وكيل عكسي مع تمكين SSL أمام السجل الخاص بي (ببساطة لا يوجد سبب للقيام بذلك) أو يجب أن أذهب إلى كل مطوري وتعديل الحجج إلى البرنامج الخفي الذي يعمل داخل boot2docker. هذا لا معنى له. هناك العديد من بيئات التطوير التي توفر أمانًا قابلاً للتكوين يتم فيها تعطيل الأمان غالبًا لبيئات المطورين. أنا مندهش لرؤيتك تغلق هذه المسألة عندما كان هناك الكثير من الأصوات لصالح الحل.

ماذا عن إدراج جميع IPS الخاصة في القائمة البيضاء؟ حل وسط؟

أو جعل اسم البروتوكول ، "http" أو "https" جزءًا من اسم الصورة للسحب.

tiborvass يحقق كل من sroebuck و blevine نقاطًا رائعة. سيصبح هذا بشكل متزايد سيناريو المتاجر التي تبني الحاويات داخل المنزل ، وسيزداد أيضًا الغضب بشأن كسر سير العمل السابق. نتفهم جميعًا الجانب الأمني ​​من هذا الأمر ، وربما لا يكون السحب هو المكان المناسب لحل المشكلة ، ولكن طالما أن صورة السجل الرسمية لا توفر طريقة بسيطة وغير تقليدية للتعامل مع هذا التغيير ، فيجب أن تعتبر مشكلة UX مهمة جدًا يجب حلها.

يا tiborvass ! هذه القضية تعضنا الآن أيضًا. أنا أفضل نهج nickandrew . سيكون أقرب قليلاً إلى استنساخ git ويفتح أيضًا إمكانية بروتوكولات مختلفة قابلة للتوصيل في المستقبل. فوز عامل الميناء لأنه سيقلل من الاقتران ويفوز المجتمع.

blevine لاحظ أنه اعتبارًا من 1.3.2 localhost مدرجًا في القائمة البيضاء افتراضيًا ، راجع: https://github.com/docker/docker/pull/9124

يمكنك جعل التسجيل يستمع إلى المضيف المحلي عن طريق تمرير: -p 127.0.0.0:5000:5000 إلى docker run

proppy ، لست متأكدًا تمامًا من أن الاستماع إلى المضيف

docker pull {http}myregistry.domain.com/myapp:latest

أم يجب أن يصبح عنوان URL فعليًا؟ لا أعرف أي شيء عن بروتوكول التسجيل ولكن لا يبدو أنه غير متوافق مع تمديد بناء الجملة الحالي لتحديد عنوان URL مناسب.

blevine فهذا يعني أنه يمكنك إعداد سجل نسخ محلي.

Arg ، الآن عليّ أن أقوم بفك تشفير التكوين السحابي الخاص بي من أجل coreos لبدء تشغيل أجهزتي

tiborvass واو ، هذا أمر مؤسف حقًا. :(

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

في هذا النوع من البيئة المعقدة والديناميكية ، فإن جعل TLS في السجل مطلبًا يمثل ألمًا هائلاً. إن الاضطرار إلى تعديل بدء تشغيل برنامج Docker daemon في كل مرة نقوم فيها بالإعداد نضيف شبكة جديدة يمكن أن يكون السجل قيد التشغيل هو نفس الألم.

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

tiborvass +1. +1000. وقد ولّد هذا تعقيدًا لا داعي له على الإطلاق لـ
لنا إلى سير عمل تطوير ديناميكي للغاية. كان الحاجز أمام الدخول
أثيرت بشكل ملحوظ هنا لشيء يحتاج فقط إلى تقديمه في
سياق الإنتاج. الرجاء إنهاء آلامنا.

يوم الثلاثاء ، 9 ديسمبر 2014 ، Jeff Thompson [email protected]
كتب:

tiborvass https://github.com/tiborvass واو ، هذا واحد من هؤلاء
الجدول الافتراضي لحظات تقليب للأسف. :(

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

في هذا النوع من البيئة المعقدة والديناميكية ، يتم إنشاء TLS على السجل
الشرط هو الألم الهائل. الحاجة إلى تعديل بدء تشغيل برنامج Docker daemon
في كل مرة نقوم فيها بالإعداد ، نضيف شبكة جديدة يمكن أن يكون السجل عليها
بنفس القدر من الألم.

لا تفهموني خطأ ، أنا أقدر التفكير وراء الرغبة في الدعم
TLS ، ومع ذلك ، هناك حالات تدعم فيها البيئة الإزالة بأمان
تعقيد TLS لتقليل الألم والبنية التحتية اللازمة
لدعمها.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/docker/docker/issues/8887#issuecomment -66367681.

justinclaytonjwthompmattwilliamsonnickandrewblevine

ألا يحل --insecure-registry 0.0.0.0/8 مشكلتك؟ بهذه الطريقة يمكنك الاستمرار في استخدام HTTP.

يمكن استخدام ترميز CIDR هذا بشكل أكثر دقة لتمكين التكوينات "خلف جدار الحماية" من خلال تحديد نطاقات مثل "--insecure-Registry 172.16.0.0/12". لا أنصح باستخدام هذا الخيار على الإطلاق ، لكني أوصي بأن يختار المستخدمون هذا الخيار لاستخدام نطاق أكثر انتقائية (مثل مساحة IP الخاصة بهم) بدلاً من جميع العناوين قدر الإمكان باستخدام 0.0.0.0/8.

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

إنه يعادل إخبارنا بتغيير ملف php.ini لمضيف php مشترك.

في 9 كانون الأول (ديسمبر) 2014 ، الساعة 22:18 ، كتب Tibor Vass [email protected] :

justinclaytonjwthompmattwilliamsonnickandrewblevine

ألا يحل --insecure-Registry 0.0.0.0/8 مشكلتك؟ بهذه الطريقة يمكنك الاستمرار في استخدام HTTP.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

mattwilliamson علامات التنفيذ قابلة للتكوين مع CoreOS. يمكنك تحرير ملف تكوين systemd لـ Docker. لتكوين هذا لمجموعة ، يمكنك استخدام cloud-config.

توجد أمثلة على تغيير تكوين Docker على موقع CoreOS على الويب. يمكن للمرء بسهولة تعديل التعليمات لإضافة علامة تصحيح لتحديد علامة سجل غير آمن بدلاً من ذلك.

https://coreos.com/docs/launching-containers/building/customizing-docker/

tiborvass يحتاج النظام البيئي للتهيئة بأكمله إلى دعم هذا للعمل بسهولة خارج الصندوق. لا يتوقع الأشخاص إجراء تخصيصات غير قياسية لبدء التشغيل الخفي في كل مكان قد يسحبونه (boot2docker ، coreos ، أي شيء مثبت مع وحدات الطاهي / الدمية ، إلخ) عندما ينتقلون إلى خطوة إعداد السجل الداخلي الخاص بهم. صورة حاوية التسجيل الرسمية نفسها _ لم تعد تعمل _ عند استخدام الخطوات التي تم وضع علامة "موصى بها" في الملف التمهيدي. لا يذكر التمهيدي TLS على الإطلاق ، في الواقع ، وإعداد هذا هو عملية غير تافهة. بالإضافة إلى ذلك ، كما ذكر mattwilliamson باختصار أعلاه ، هناك حالات لا تعد ولا تحصى مثل بيئات البناء المشتركة حيث لا يكون الشخص الذي يستخدم البرنامج الخفي لسحب الصورة هو نفسه الشخص الذي يقوم بتكوين البرنامج الخفي.

خلاصة القول هي أن جعل هذه الحجة من جانب العميل هو الحل الأقل اضطرابًا ، والأهم من ذلك ، الحل الأقل إلزامية. أصبح Docker بالفعل بدائيًا في العشرات إن لم يكن المئات من المشاريع ومهام سير العمل الأخرى ، وبالتالي لا ينبغي حقًا أن تملي أنماط الاستخدام في هذا النطاق. فقط لأن Git يقدم خيار تكوين وقت تشغيل بسيط لتعطيل http.sslverify لا يعني أن Linus Torvalds يشجع الناس على عدم تأمين بياناتهم الحساسة في السياقات التي يكون من المهم فيها القيام بذلك.

يعتبر تشبيه git مثالًا جيدًا على كيفية عمل ذلك. لا يجبرك Git على استخدام TLS ، وهو قرار المستخدم عند إعداد مضيف ما هو المستوى الذي يريد دعمه. إنه أيضًا قرار المستخدم عند سحب مستوى الأمان الذي يحتاجون إليه (أو يريدون تجاوزه). يعد التكوين خطوة بسيطة ، إما بشكل عام أو عن طريق الريبو. على الرغم من أن Docker لا يجبرنا على استخدام TLS ، من خلال جعل البديل البديل غير تافه ، فإنه لا يوفر خيارات أخرى معقولة.

يسمح ترميز CIDR باتباع نهج "المطرقة الثقيلة" ، و AFAIK ، لا يتم تعيينه لأسماء نظام أسماء النطاقات ، لذلك حتى إذا قمت بإخفاء 10.0.0.0/16 ، فسحب بعضًا. ر العمل. والأهم من ذلك ، أن التكوين ليس تافهاً.

يزدهر Docker في بساطته للتعبئة بالحاويات ، ويقلل بشكل كبير من حاجز نشر التطبيقات في مجموعة متنوعة من البيئات. كلنا نعرف الفوائد. لا يستطيع معظم المطورين الإجابة على أسئلة تدوين CIDR البسيطة ، وقد يكون ملف تكوين عامل ميناء في أماكن غير قياسية (كلا موقعي boot2docker و CoreOS مختلفان عن التوزيعات الأخرى) ، ومن السهل إلى حد ما العبث بملفات التكوين هذه بحلقات ملاحظات صعبة لـ النجاح. لا بد لي من ذيل سجل النظام؟ أوه انتظر أنا على RHEL وهي رسائل؟

يمكن للمطور الجديد نسخ مقتطف docker pull ولصقه بسهولة ، ولكن جعله ssh في مضيف boot2docker ، وتشغيل vi ، وتحرير ملف التكوين ، ثم تخصيص سجل نظام بحثًا عن أخطاء ... ليس كثيرًا. ونعم ، لقد نسيت إعادة تشغيل Docker daemon.

هذا ما أود رؤيته:

• يتم تطبيق إعدادات Docker daemon عن طريق أمر Docker
• إعدادات سحب Docker لتجاوزات TLS ، المحددة عبر أمر عامل الإرساء
• يتم الاحتفاظ بإعدادات سحب Docker عبر أوامر لسجلات معينة

نعم ، لكن أمازون لا يسمح لك بتغيير تهيئة مقياس تلقائي. سأضطر إلى عمل نسخة منه أو عمل نسخة جديدة بالكامل.

في 9 كانون الأول (ديسمبر) 2014 ، الساعة 23:55 ، كتب إريك وينديش [email protected] :

علامات التنفيذ قابلة للتكوين مع CoreOS. يمكنك تحرير ملف تكوين systemd لـ Docker. لتكوين هذا لمجموعة ، يمكنك استخدام cloud-config.

توجد أمثلة على تغيير تكوين Docker على موقع CoreOS على الويب. يمكن للمرء بسهولة تعديل التعليمات لإضافة علامة تصحيح لتحديد علامة سجل غير آمن بدلاً من ذلك.

https://coreos.com/docs/launching-containers/building/customizing-docker/

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

يتعين علي حاليًا حل هذه المشكلة في بيئة تطوير شركتي عن طريق تشغيل هذا الأمر الذي تم بحثه بشق الأنفس في كل مرة أقوم فيها بـ "boot2docker up"

boot2docker ssh 'sudo sh -c "echo \"EXTRA_ARGS=\\\"--insecure-registry 10.0.0.0/8\\\"\" > /var/lib/boot2docker/profile && sudo /etc/init.d/docker restart"'

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

CleanCut بشكل جيد للغاية. لقد أصبت بخيبة أمل حقًا لأن 1.4.0 جاء وذهب ولا تزال هذه القضية مفتوحة.

CleanCut رائع - ما أريده في boot2docker ، هو جعله يضيف مزيدًا من المعلومات إلى الحمولة الأولية boot2docker init ، والتي ستقوم بذلك من أجلك.

لا يحل المشكلات المحددة التي لا تعتمد على boot2docker ، ولكن --insecure-registry ليس التخصيص الوحيد للموقع الذي يريده المستخدمون b2d.

هل يمكنك تقديم طلب سحب أو إصدار لهذا في boo2docker repo من فضلك؟

يرفع حقًا الحاجز أمام شخص ما لاستخدام مشروع تم الترحيب به لخفض الحواجز.

في 13 كانون الأول (ديسمبر) 2014 ، الساعة 02:10 ، كتب جاستن كلايتون [email protected] :

CleanCut بشكل جيد للغاية. لقد أصبت بخيبة أمل حقًا لأن 1.4.0 جاء وذهب ولا تزال هذه القضية مفتوحة.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

تضمين التغريدة ها هو

يبدو أن هناك إجماعًا في هذا الموضوع على أن هذه ليست مشكلة محلولة ؛ هل يمكننا إعادة فتح هذه المشكلة من فضلك؟

نعم من فضلك!
Le 2014-12-15 15:05، "Justin Clayton" [email protected] بريد إلكتروني:

يبدو أن هناك إجماعًا في هذا الموضوع على أن هذا ليس حلًا
مشكلة؛ هل يمكننا إعادة فتح هذه المشكلة من فضلك؟

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/docker/docker/issues/8887#issuecomment -67055878.

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

bfirsh - هذا أحد الأمثلة التي يكون فيها ملف تكوين Docker daemon و kill -HUP <dockerdaemonpid> رائعًا - قم بتشغيله لإعادة قراءة cfg ، دون الحاجة إلى إعادة تشغيله - وبالتالي تجنب إعادة تشغيل الحاوية

SvenDowideit +1 لميزة إعادة التحميل ، من المزعج حقًا إعادة تشغيل الخادم عن طريق التكوين البسيط.

+1

سامحني إذا لم أفهم الأشياء بشكل صحيح ، ولكن يبدو أن هذه المشكلة هي أصل السيناريو الخاص بي (على غرار السيناريو الذي حدده blevine حيث

http://stackoverflow.com/questions/27536180/docker-on-mac-behind-proxy-that-changes-ssl-certificate

+1 لإعادة فتح هذه المناقشة ، لأنه يبدو أن المجتمع ليس سعيدًا حقًا بالحل الحالي.

https://twitter.com/justinclayton42/status/550143834705780737

مجرد محاولة الوصول إلى هذا من جميع الزوايا حتى نسمع إجابة نهائية حول هذا الموضوع.

+1 ، يصعب حاليًا تكوين هذا الأمر والعمل به.

mhamrah يحقق نقاطًا رائعة. لا تجبر الأشياء ، دع المستخدمين يقررون ويكوّنون احتياجاتهم الخاصة.

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

أعتقد أن كل شخص تم نشره في هذا الموضوع يرى القيمة والفائدة
من عامل الميناء ، يستخدمونه يوميًا ، يحاولون الترويج له في
المنظمات ، ولكنهم يعانون من مشكلة مؤلمة وغير ضرورية
يعيق التبني.

بقدر ما نعلم جميعًا عامل الرصيف ، فإنه لا يزال غير معروف لكثير من الأشخاص في مجال التكنولوجيا-
خاصة داخل المؤسسة. التوثيق يساعد ، لكننا ما زلنا
القفز من خلال الأطواق ، وهو مانع كبير مع سلبي بشكل عام
تأثير.
في الأحد ، 25 يناير 2015 الساعة 5:54 مساءً ، كتب جاي تايلور [email protected] :

+1 ، يصعب حاليًا تكوين هذا الأمر والعمل به.

mhamrah https://github.com/mhamrah يحقق نقاطًا رائعة. لا تجبر
الأشياء ، دع المستخدم يقرر ويهيئ لاحتياجاته الخاصة.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/docker/docker/issues/8887#issuecomment -71398193.

1+ جيد لتجربة الأشياء بسرعة

: +1:

: +1:

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

+1

بعض الأفكار:

1. هل يمكننا الحصول على أحرف البدل لاسم المضيف؟ على سبيل المثال ، --insecure-registry=*.internal
2. هل يمكن معاملة الشهادات الموقعة ذاتيًا بشكل مختلف عن http؟
3. ذات الصلة بـ 2 ، هل يمكن أن يقوم عامل الإرساء بشيء مشابه لـ SSH ويحث المستخدم على قبول شهادة موقعة ذاتيًا عندما يرى واحدة جديدة / يشتكي بصوت عالٍ إذا كان هناك غير متطابق؟

وبينما أقوم بتقديم اقتراحات ، لماذا لا نتعامل مع المضيف المحلي على أنه آمن دائمًا؟ (كما يفعل Chrome)

تحرير: آه ، أرى أنه بالفعل.

+1000 في هذا .. و +1 على ميزة إعادة تحميل التهيئة ، وهذا ما يجعل هذا الأمر سيئًا مرتين. بقيت مع v1.2 لأنني اعتقدت بالتأكيد أن المشرف سيدرك مدى إزعاج علامة --insecure-Registry على البرنامج الخفي للنشر وإصلاحه ، ولكن بطريقة ما تستمر الإصدارات الثانوية في تجاهلها.

على سبيل المثال ، إذا اضطررت إلى تغيير عنوان IP الخاص بالسجل الخاص بي لأي سبب كان ، فسأضطر إلى إعادة تشغيل كل برنامج خفي من عامل ميناء واحد على كل جهاز افتراضي - فقط لأن السجل الخاص بي قد تغير !؟ لا ينبغي أن يقترن هذان الشيئين بإحكام. وإخبار الأشخاص بإضافة 0.0.0.0/8 فقط ، يتعارض هذا مع الغرض الكامل من تنفيذ الأمان في المقام الأول.

تبدو إضافة هذا العلم إلى أوامر الدفع / السحب واضحة جدًا كاحتياطي للعلامة الخفية ، يرجى من أحدهم أن يشرح لي سبب استمرار محاربته مع إضافة ميزات "من الجيد أن يكون لديك" في هذه الأثناء.

تعليق agquick على الفور ، ولا سيما

إدراكًا أن هذا يمثل ألمًا مستمرًا لعدد كبير من المستخدمين ، فإننا نعيد النظر في إضافة --insecure إلى pull . ewindisch وسأعمل على العلاقات العامة التي

أعتذر عن طول الانتظار وشكراً للتعبير عن آرائك والإشارة إلى نقاط الألم لديك.

يمكنني أن أتخيل tiborvass أن هناك عددًا كبيرًا بنفس القدر من المستخدمين الذين _ لا يريدون_ السماح بعمليات السحب من السجلات غير الآمنة. أدرك أن Docker لا يمتلك حاليًا تحكمًا دقيقًا في الأذونات / التكوين ، ولكن إذا كانت هناك فرصة لتكون قادرًا على "قفل" هذا ، أعتقد أن ذلك سيكون لمسة لطيفة.

أوه ، اجعلها هكذا! كنت على وشك تنفيذه بنفسي.

مُرسَل من هاتفي الذكي BlackBerry 10 المتصل بشبكة Bell.
من: Sebastiaan van Stijn
تاريخ الإرسال: الاثنين ، 23 فبراير 2015 ، الساعة 4:53 مساءً
إلى: عامل ميناء / عامل إرساء
الرد على: عامل ميناء / عامل إرساء
نسخة إلى: كريستوفر سيبلاك
الموضوع: Re: [عامل الإرساء] - يجب أن يكون التسجيل الآمن على "Docker pull" (# 8887)

tibor vasshttps: //github.com/tiborvass يمكنني أن أتخيل أن هناك عددًا كبيرًا بنفس القدر من المستخدمين الذين لا يريدون السماح بعمليات السحب من السجلات غير الآمنة. أدرك أن Docker لا يمتلك حاليًا تحكمًا دقيقًا في الأذونات / التكوين ، ولكن إذا كانت هناك فرصة لتكون قادرًا على "قفل" هذا ، أعتقد أن ذلك سيكون لمسة لطيفة.

-
قم بالرد على هذه الرسالة الإلكترونية مباشرة أو tHubhttps: //github.com/docker/docker/issues/8887#issuecomment -75644600.

thaJeztah أحاول معرفة حالة الاستخدام التي تفكر فيها والتي تعني أنه لا يمكننا الحصول على علامة --insecure-registry إلى docker pull .

• إذا كان المستخدم لا يريد أن يكون MITMed عن طريق الخطأ في سجل آمن ، فيمكنه فقط تجنب تجاوز --insecure-registry
• إذا أراد المستخدم أن يفرض على المستخدمين أن جميع الصور تأتي من سجلات آمنة (أي سيناريو "الشركة") ، فلا يمكنهم في الواقع فرض هذا مطلقًا في الوقت الحالي على أي حال!

هل يمكنك أن تشرح بالتفصيل ما الذي يمنعه docker pull --insecure-registry ؟

للتوسع في نقطتي الثانية ، لا أستطيع أن أرى كيف ستغلق هذا دون إعادة التفكير في قدر كبير من كيفية عمل عامل الإرساء! ضع جانبًا القدرة على docker load a tarball التي يمكنك الحصول عليها عن طريق كتابة مجتذب التسجيل الخاص بك ، واستخدام docker run -v لتصعيد الخاص وإضافة شيء إلى الحجج الخفية ، هناك طريقة بسيطة للغاية لتجاوز أي 'إجباري':

$ docker pull registry:5000/aidanhs/blah                                    
FATA[0004] Error: v1 ping attempt failed with error: Get https://registry:5000/v1/_ping: EOF. If this private registry supports only HTTP or HTTPS [...]
$ socat tcp4-listen:5000,reuseaddr,fork tcp4:registry:5000 &
[1] 22924
$ docker pull localhost:5000/aidanhs/blah
Pulling repository localhost:5000/aidanhs/blah
[...]
Status: Image is up to date for localhost:5000/aidanhs/blah:latest
$ docker tag localhost:5000/aidanhs/blah registry:5000/aidanhs/blah

إذا أراد المستخدم أن يفرض على المستخدمين أن جميع الصور تأتي من سجلات آمنة (أي سيناريو "الشركة") ، فلا يمكنهم في الواقع فرض هذا مطلقًا في الوقت الحالي على أي حال!

هذا هو السيناريو ، نعم.

للتوسع في نقطتي الثانية ، لا يمكنني رؤية كيف ستغلق هذا دون إعادة التفكير في قدر كبير من كيفية عمل عامل الإرساء

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

ومع ذلك ، فإنه _ يفعل _ يعطي إشارة واضحة للمستخدم إذا أعطى docker pull --insecure-registry .. خطأ ("السجلات غير الآمنة معطلة") ، والتي _ ستعلم المستخدمين بأنه غير مرغوب فيه ، على سبيل المثال ، عند تجربة بعض الأمثلة التي عثروا عليها مكان ما.

فهل ستغطي جميع الحالات؟ لا ، هل هذا _أذى_ ، لا أعتقد ذلك أيضًا.

أنا شخصياً أشعر أنه سيضر أكثر مما ينفع ، ببساطة لأنه يضلل الناس للتفكير "أوه ، انظر ، عامل الميناء يفرض هذا" في حين أنه في الواقع حماية سطحية للغاية. يمكنني المضي قدمًا ، لكن في النهاية أعتقد أن الأمر يتعلق بمسألة الذوق.

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

أرى المشكلات في الغالب مع عامل ميناء غير قادر على إعادة التشغيل دون قتل الفرعية
حاويات. التي تجعل تكوينها / إعادة تكوينها أصعب بكثير.

يوم الأربعاء ، 15 أبريل 2015 الساعة 8:11 مساءً ، Jan Krueger [email protected]
كتب:

+1

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/docker/docker/issues/8887#issuecomment -93362359.

أشعر بخيبة أمل كبيرة لأنه لم يتم اتخاذ بعض الإجراءات بشأن هذه المشكلة حتى الآن. من الواضح أنه يسبب ألمًا لعدد من الأشخاص.

من الواضح أنه أمر مزعج لعدد كبير من الناس ، إنه يمنع عملي بشكل نشط في الوقت الحالي. الاضطرار إلى إعادة تشغيل Docker daemon للسماح بالانسحاب من سجل غير آمن يتراوح من مزعج إلى مستحيل تمامًا اعتمادًا على الموقف الذي تعيش فيه.

يبدو أن الحجة الرئيسية لعدم القيام بذلك هي أن مسؤول النظام يجب أن يكون قادرًا على قفل النظام والتأكد من أنه يمكن فقط سحب الصور من عمليات إعادة الشراء الآمنة. حالة الاستخدام هذه حقيقية بالتأكيد ولكني أعتقد أنها تؤدي إلى تقصير سيء. يبدو من المعقول أكثر أن يكون لديك علامة يمكن تمريرها إلى البرنامج الخفي عند البدء مثل --no-insecure والذي يعطل استخدام --insecure-registry في pull . بهذه الطريقة يمكن للمسؤول قفل الأشياء إذا كان يريد ذلك حقًا.

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

شاهد مشروعي "Docker-pull": https://github.com/ewindisch/docker-pull

يمكنك استخدامه على هذا النحو:

docker run ewindisch/docker-pull --insecure-registry 10.0.0.0/16 10.0.1.2/someimage | docker load

من الممكن أيضًا السماح لجميع السجلات على أنها غير آمنة:

docker run ewindisch/docker-pull --insecure 10.0.1.2/someimage | docker load

سوف أذكر أنه لا يزال من غير المستحسن فعل ذلك.

ewindisch هاك أنيق.

حل جيد آخر هو استخدام نفق tcp:

$ docker pull host:5000/image #fails
$ ssh -N -L 5000:host:5000 user<strong i="8">@host</strong>
$ docker pull localhost:5000/image #works

كلاهما حلول رائعة!

أنا أيضا أود أن أرى التقصير معكوس.

في 15 أبريل 2015 ، الساعة 6:14 مساءً ، كتب Joe Doliner [email protected] :

أشعر بخيبة أمل كبيرة لأنه لم يتم اتخاذ بعض الإجراءات بشأن هذه المشكلة حتى الآن. من الواضح أنه يسبب ألمًا لعدد من الأشخاص.

من الواضح أنه أمر مزعج لعدد كبير من الناس ، إنه يمنع عملي بشكل نشط في الوقت الحالي. الاضطرار إلى إعادة تشغيل Docker daemon للسماح بالانسحاب من سجل غير آمن يتراوح من مزعج إلى مستحيل تمامًا اعتمادًا على الموقف الذي تعيش فيه.

يبدو أن الحجة الرئيسية لعدم القيام بذلك هي أن مسؤول النظام يجب أن يكون قادرًا على قفل النظام والتأكد من أنه يمكن فقط سحب الصور من عمليات إعادة الشراء الآمنة. حالة الاستخدام هذه حقيقية بالتأكيد ولكني أعتقد أنها تؤدي إلى تقصير سيء. يبدو من المعقول أكثر أن يكون لديك علامة يمكن تمريرها إلى البرنامج الخفي في البداية مثل - no-unecure الذي يعطل - استخدام التسجيل غير الآمن في السحب. بهذه الطريقة يمكن للمسؤول قفل الأشياء إذا كان يريد ذلك حقًا.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

لذلك يتم إعادة فتح هذا والوضع الحالي بعد 4 أشهر ليس شيئًا وكحل بديل ، استخدم مجموعة من الاختراقات؟ : - / هل هناك بعض النقاش حول هذا يحدث في مكان آخر أم أنه مات للتو؟

ونعم ، +1

+1

+1

أود أن أشير إلى أنني أحصيت حالات "+1" في هذه الصفحة ، وبلغ العدد 31 حتى الآن. هذا لا يشمل التعليقات الداعمة الأخرى التي لا تتضمن هذه السلسلة بالضبط.

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

"مسؤول النظام" هو حالة استخدام واحدة ل Docker ، لكن أنا "مطور" و "غير مسؤول النظام" هما حالات استخدام صالحة بنفس القدر. بالنسبة للمطور ، يؤدي توفير خيار --insecure تقليل الاحتكاك في سير العمل.

ربما يمكننا الحصول على أفضل ما في العالمين من خلال توفير خيار يمكن لمسؤولي النظام تحديده من أجل رفض استخدام خيار --insecure . وبهذه الطريقة ، لا يزال مسؤولو النظام يتمتعون بالتحكم الكامل ، ولكن لا يتعين على الحالات التي لا تتبع مسؤول النظام التعامل مع آلام سير العمل.

ما هو تافه لمدير النظام يمكن أن يكون مرهقًا بشكل مفاجئ لغير مسؤولي النظام. اضطررت إلى مساعدة ما يقرب من عشرين مطورًا في إجراء (وإعادة إجراء) تغيير التكوين هذا عبر 5 أنظمة تشغيل مختلفة مستخدمة في مجموعة التطوير الخاصة بنا. أنا في الواقع أحتفظ بنص لأتمتة تغيير التكوين لبيئاتنا.

لن يقوم مسؤولو النظام لدينا حاليًا بإعداد شهادات موقعة ذاتيًا لسجلنا ، سواء كان ذلك أمرًا بسيطًا أم لا.

على أي حال ، حتى لو لم يتغير هذا ، فإن الناس في النهاية سوف يتأقلمون معهم. أفترض أن الألم الذي أتعامل معه سيختفي في المرة القادمة التي يقوم فيها مسؤولو النظام لدينا بصيانة السجل ، لأنه في هذه المرحلة يجب أن نكون قادرين على تثبيت شهادات SSL الفعلية. ربما هذا هو بيت القصيد. اجعل اتخاذ المسار الآمن أسهل من المضي قدمًا في المسار غير الآمن.

: +1: CleanCut ، والجميع قال كل شيء. أنا أعمل فقط مع حالة المطور وإعادة تكوين برنامج Docker daemon هو مجرد مضيعة للوقت بالنسبة لنا.

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

ومع ذلك ، هناك شيء يمكن قوله حول زيادة
الاحتكاك للمطورين الذين يحاولون فعل الشيء الخطأ في إغراء الآخرين
عليهم أن يفعلوا الشيء الصحيح.
في 18 حزيران (يونيو) 2015 الساعة 12:41 ظهرًا ، كتب "Brian Goff" [email protected] :

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

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/docker/docker/issues/8887#issuecomment -113213172.

ewindischtiborvass اقرأ مرة أخرى ، أرى https://github.com/docker/docker/issues/8887#issuecomment -75638745 ؛

وإدراكًا أن هذا يمثل ألمًا مستمرًا لعدد كبير من المستخدمين ، فإننا نعيد النظر في إضافة - تأمين سحب. ewindisch وسأعمل على العلاقات العامة التي
أعتذر عن طول الانتظار وشكراً للتعبير عن آرائك والإشارة إلى نقاط الألم لديك.

هل لا يزال هذا هو الوضع الحالي؟ (لا أعتقد أن العلاقات العامة قد تم إنشاؤها)

+1

هذا لا يزال يزعجني ويضايقني بشكل يومي.

:( مخروط حزين.

--inscure منطقي تمامًا من مطور POV. على الشخص الذي يقوم بتنفيذ عامل الرصيف في بيئته لجعله آمنًا.

+1

: +1:

_USER POLL_

_ أفضل طريقة للحصول على إشعار عند حدوث تغييرات في هذه المناقشة هي النقر فوق الزر "اشتراك" في أعلى اليسار.

قدّر الأشخاص المدرجون أدناه مناقشتك الكاملة مع إجراء +1 عشوائي:

تضمين التغريدة
تضمين التغريدة
@ tangr1
تضمين التغريدة
تضمين التغريدة
تضمين التغريدة
تضمين التغريدة
تضمين التغريدة
تضمين التغريدة
mhamrah
تضمين التغريدة
@ ريان عديم الجنسية
تضمين التغريدة
تضمين التغريدة
تضمين التغريدة
تضمين التغريدة

+1

+1

+1

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

+1

إذا كانت هذه المشكلة لا تزال مفتوحة بحلول عيد الهالوين ، أعتقد أن جميع إجراءات +1 يجب أن يكون لها عام واحد في حفلة ذكرى يغرق في أحزاننا.

+1 لحفلة الحزن!

في 14 سبتمبر 2015 ، الساعة 1:32 مساءً ، كتب Gordon [email protected] :

استطلاع رأي المستخدم

أفضل طريقة للحصول على إشعار عند حدوث تغييرات في هذه المناقشة هي النقر فوق الزر "اشتراك" في الجزء العلوي الأيسر.

قدّر الأشخاص المدرجون أدناه مناقشتك الكاملة مع إجراء +1 عشوائي:

تضمين التغريدة
تضمين التغريدة
@ tangr1
تضمين التغريدة
تضمين التغريدة
تضمين التغريدة
تضمين التغريدة
تضمين التغريدة
تضمين التغريدة
mhamrah
تضمين التغريدة
@ ريان عديم الجنسية
تضمين التغريدة
تضمين التغريدة
تضمين التغريدة
تضمين التغريدة

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

+1

+1 لحفلة الحزن

عزيزي مالك الروبوت الذي يطلب من الأشخاص التوقف عن استخدام "+1":
نستخدم +1 للتعامل معه وليس هناك الكثير مما يمكن قوله.

+1

+1

هناك نوعان من الحلول ، بما في ذلك استخدام أنفاق SSH - ولكن هذا يتطلب حسابات ssh على مضيف التسجيل. الحل التالي ، لا يحتاج إلى ذلك.

قم بتشغيل معيد توجيه منفذ التسجيل ، كما يلي:

docker run --name registry_forwarder -d -p 5000:5000 -e REGISTRY_HOST="<registry_host_ip>" -e REGISTRY_PORT="5000" rsmoorthy/registry-forwarder

ثم اسحب أو ادفع الصور من السجل المحلي الخاص بك:

docker pull localhost:5000/your-image
docker push localhost:5000/my-image

rsmoorthy هذا رائع. نشكرك على إثبات عدم جدوى هذا التقييد الحالي بإيجاز.

عامل ميناء ، يرجى إعادة تضمين هذه البطارية المعينة.

+1

يجب أن أقول إن تشجيع الأمن بقوة على المستخدم قد أثر بشكل خطير في أفكاري بشأن استخدام عامل الإرساء. أفهم تمامًا أنه يمكننا إضافة علامة --insecure-Registry إلى البرنامج الخفي في البداية ، ولن أخوض في جميع الأسباب التي لا تعمل طوال الوقت ، أو قد تكون مستحيلة.

لدي سؤال لمطوري Docker ، هل تعتقدون حقًا يا رفاق أنك تعرف ما هو الأفضل للمستخدم النهائي؟ أنا شخصياً لا أطلب SSL في سجلاتي على الإطلاق ، لأن الشبكة التي يتم تشغيلها عليها مشفرة بالكامل بالفعل. فلماذا على الأرض أقوم بتشفير حركة المرور المشفرة ، هل هذا فعلاً يفعل أي شيء إلى جانب إضافة القطع العلوية والمتحركة إلى نظام معقد وضخم بالفعل؟

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

TL ؛ DR +1

+1

Supernomad قال حسنا.

شاهدها من جانب عامل الشحن: إنها مشكلة من الأفضل عدم تنفيذها رسميًا أبدًا ، ولكن مع الكثير من الحلول الممكنة لتخفيف الألم. لا يزال صراخ بعض المستخدمين بصوت عالٍ أقل إيلامًا من عامل التسويق الخاص بالمنافسة باعتباره "غير آمن عن قصد" ، ويلحق الضرر بسمعته إلى الأبد.
بعد قولي هذا ، +1.

tiborvassewindisch هذه المسألة أكثر من سنة من العمر. لقد مر أكثر من 8 أشهر منذ أن قلت أنه سيتم إعادة تقييمه. هل قمت بتقييم ذلك؟ إذا كان الأمر كذلك ، ما الذي تقرر؟ لا تترك أخًا معلقًا! :-)

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

• ssh -N -L 5000:host:5000 user<strong i="10">@host</strong> && docker pull localhost:5000/lolsecurity
• socat tcp4-listen:5000,reuseaddr,fork tcp4:registry:5000 && docker pull localhost:5000/lolsecurity
• docker-machine create -d virtualbox --engine-insecure-registry 0.0.0.0/0 lolsecurity
• docker run --name registry_forwarder -d -p 5000:5000 -e REGISTRY_HOST="<registry_host_ip>" -e REGISTRY_PORT="5000" rsmoorthy/registry-forwarder && docker pull localhost:5000/lolsecurity

ناهيك عن شحن CoreOS الآن --insecure-registry 0.0.0.0/0 كإعداد افتراضي. تُظهر هذه الأمثلة بوضوح أن فكرة وجود خطوط لفصل الاهتمامات بين "مسؤول النظام" و "المطور" أصبحت الآن تعسفية ومزيفة إلى حد كبير في عام 2015. في الواقع ، فإن فكرة الحاويات (التي يرأسها Docker التبشيري) سارع هذا الاتجاه إلى حد كبير بعيدًا عن العمليات التقليدية التي لا تزال تزعج استدعاء أي شخص "مسؤول النظام" في المقام الأول.

على أي حال ، أود أن أرى هذا مغلقًا إلى الأبد ، بطريقة أو بأخرى.

+1

+1

+1

لماذا يجب أن أثق في Docker Registry باستخدام مفتاح SSL الخاص بي؟

بالنسبة لمستخدمي CoreOS الآخرين الذين تركوا ليجفوا بسبب هذا التدخل ،
https://coreos.com/os/docs/latest/registry-authentication.html#using -a-Registry-without-ssl-configuration

politician لا أقول ذلك بشكل أفضل بنفسي. بالتأكيد ، يبدو أن عامل النقل يتجاهل حقيقة أن جزءًا كبيرًا من مستخدميه غير راضين على الأقل.

الحقيقة هي أنني بصدد الهجرة بعيدًا تمامًا عن عامل الرصيف ولا يمكنني أن أكون أكثر سعادة بهذا القرار. أنا أستخدم حاليًا git و lxc ، ولا يقتصر الأمر على تسليمها بشكل أسرع من عامل الإرساء فحسب ، بل إنها تتيح لي فعلاً القيام بما هو أفضل لشركتي وليس ما تعتقده شركة أخرى ، وإن كان بشكل غير صحيح تمامًا ، هو الأفضل بالنسبة لي.

أقترح بشدة إلقاء نظرة على البدائل التي هي بصراحة أفضل من عامل الميناء ، مثل الصواريخ ، lxc الخام ، qemu (ليست هي نفسها ولكن لا تزال أفضل) على سبيل المثال لا الحصر.

سأقترح بشدة مسار العمل هذا على كل شخص أعرفه يدرس الحاويات من الآن فصاعدًا. على الأقل حتى يدرك الأشخاص في عامل الشحن أنه ليس لديهم أي فكرة ، وأؤكد - بالتأكيد - ليس لدي أي فكرة ، ما هو الأفضل للمستخدم النهائي من حيث الأمان.

استسلمت واشتريت شهادة SSL مخصصة رخيصة. إن اعتماد Docker CLI على نظام CA قوي للغاية - الشهادات الموقعة ذاتيًا ليست مجرد محبط تشغيلي ، فهي ببساطة لا تعمل.

• يحذف docker-machine تجاوز ca.crt بين الأسفل / الأعلى
• لا تتضمن أي من صورك الأساسية أدوات صنع الشهادات مثل طائرة بدون طيار لـ CI مستحيلة
• يستخدم docker CLI مجلدًا غير قياسي للشهادات ، لذلك هذا شيء آخر يجب تذكره.
• حتى إذا قمت بتشغيله بعد 18 ساعة ، فسيكون لديك دائمًا شعور مزعج بأن شيئًا آخر قد تم كسره

الخلاصة: يفرض Docker عقوبة مستمرة على فريق العمليات عند محاولة استخدام شهادة موقعة ذاتيًا.

هذا أمر محبط أكثر لأن curl -k موجود منذ الأبد.

+1

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

buehler ، يمكنك إضافة الخيار --insecure-registry إلى إعدادات البرنامج الخفي ، أو إلى ملف التكوين daemon.json الخاص بك ؛ فأنت تحتاج فقط إلى تكوينه مرة واحدة ، والسحب دون الحاجة إلى تحديد العلم

مجرد تحديث منا: لقد جردنا السجل من بنيتنا الأساسية منذ ذلك الحين وعادنا إلى استخدام

buehler فقط لتجسيد اقتراح haJeztah ، أضف هذا السطر إلى التكوين:

--insecure-registry 0.0.0.0/0

ستتمكن من الوصول إلى أي سجل تريده. يعمل جيدًا لاختبار الأشياء.

politician يحدث التكرار إذا تم تمييز الصور بمستودعات مختلفة. يعد عدم حذف النقاط مشكلة أكبر بكثير.

thaJeztah إذا كان من السهل القيام بذلك ، ولكن 80٪ (عدد تعسفي معترف به) من المستخدمين يحتاجون إلى القيام بذلك ، فالرجاء فقط جعله الخيار الافتراضي.

@ justinclayton لا ؛ يشير تعيين هذا الخيار بشكل أساسي إلى "تجاهل أي مشكلة تتعلق بالاتصال الآمن بالسجل" ، لذا اسمح بهجمات man-in-the-middle "خارج الصندوق" ، أو حتى عودة البرنامج الخفي إلى غير TLS "http: //" . قام Docker _does_ بالفعل بتعيينه كافتراضي للسجلات في النطاق 127.x.x.x .

إذا كان لديك سجل محلي ولا تريد إنشاء شهادة له ، فإن إضافة --insecure-registry إلى خيارات البرنامج الخفي يستغرق أقل من دقيقة. يجب أن يكون عملاً متعمدًا ، وليس شيئًا يتم تعيينه افتراضيًا.

thaJeztah أنا أفهم حجتك ، لكن هذا لا يمكن أن يكون نهاية الأمر. هناك فجوة كبيرة في تجربة المستخدم للمطورين الجدد نتيجة لوجود هذا في الجانب الخفي. سيناريو _الأغلبية_ حيث يمثل هذا ألمًا هو مطور جديد يتبع الإرشادات الموجودة على docker.com لتنزيل وتشغيل مثبت Docker Toolbox على جهاز Mac الخاص به. عند الانتهاء ، يحاولون على الفور تشغيل docker pull <internally-signed-registry>/foo ويتم استقبالهم بخطأ. هذه هي القضية الحقيقية. ربما هذا يعني أنه يجب إعادة تسمية هذه المشكلة؟

هناك الكثير من الطرق الأخرى التي يمكن أيضًا حلها من أجلها ؛ أنا متأكد من أن المجتمع والشركة يمكن أن يتفقوا على واحد منهم:

• الاسم الحالي لهذه المشكلة هو '--insecure-Registry يجب أن يكون على "docker pull"'. نظرًا لأن هذه المشكلة لا تزال مفتوحة ، يجب أن أفترض أن هذا الخيار لا يزال قيد الدراسة.
• إذا تم توفير حل بأمر واحد لهذا (وتوثيقه) كان بسيطًا للمستخدمين المبتدئين ، فسيؤدي ذلك إلى حل هذا الأمر.
• في حالتنا ، السجل _ is_ مؤمن. تستخدم شهادة موقعة من المرجع المصدق الداخلي الخاص بنا مثل أي شيء آخر في بيئة البناء الخاصة بنا. هذا أمن كاف. إذا كان البرنامج الخفي قادرًا بطريقة ما على تكريم متجر شهادات MacOS ، فسيؤدي ذلك إلى اختفاء هذا الصداع أيضًا.
• إذا طُلب منهم إضافة الشهادة أو إجراء هذا التكوين إلى جهاز الإرساء أثناء عملية تثبيت Toolbox ، فمن المحتمل أن يكون ذلك جيدًا أيضًا.

يُرجى السماح للمشاركين الذين يزيد عددهم عن 70 مشاركًا في هذه المشكلة بمعرفة الاتجاه الذي تنوي اتباعه في هذا الأمر ، وإلا يُرجى إغلاق المشكلة فقط حتى لا نترك معلقة. شكرا.

تضمين التغريدة
لا توجد طريقة لإضافة سجل - غير آمن - إلى اختيارات البرنامج الخفي دون إعادة تشغيل جميع الحاويات قيد التشغيل. هذه واحدة من المشاكل الرئيسية. لا يمكننا إعادة تحميل التكوين بدون إعادة التشغيل (تستمر المشكلة من عام 2013) ، ولا يمكننا سحب الصور من السجلات الأخرى غير الآمنة بدون إضافة خيار إلى البرنامج الخفي وإعادة التشغيل أيضًا. وفي الوقت الحاضر ، ما زلنا لا نملك خارطة طريق واضحة لإصلاح هذه المشكلة.

apakhomov خمن أنه يمكن إضافته إلى قائمة تغييرات التكوين التي يمكن تحديثها دون إعادة تشغيل https://docs.docker.com/engine/reference/commandline/daemon/#configuration -reloading. هل يمكنك فتح قضية منفصلة لذلك؟

+1.

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

هل من الممكن إضافة عدة سجلات غير آمنة إلى عامل الإرساء؟
شيء من هذا القبيل --insecure-Registry xxxx: xxxx --insecure-Registry zzzz: zzzz

kkorada --insecure-registry=0.0.0.0/0 سيجعل Docker يتصرف كما كان من قبل.

kkorada نعم ، يمكنك تحديد سجلات متعددة (العلامة --insecure-registry=[] - تشير الأقواس المربعة إلى أنه يمكن تحديدها عدة مرات).

بالنسبة إلى docker 1.12 أيضًا ، سنجعل هذا الخيار قابلاً للتكوين في ملف التكوين daemon.json ، بدون إعادة تشغيل البرنامج الخفي. انظر طلب السحب المفتوح هنا: https://github.com/docker/docker/pull/22337

شكرا لك mingfang و haJeztah

كماmhamrah وjustinclayton اقترح ، وأود أن أوصي أيضا حل باستخدام سه بالإضافة إلى TLS، على غرار كيف يسمح بوابة الوصول إلى respository باستخدام كل سه وTLS. هذا قد يجعل استخدام سه الحل البديل أنjustinclayton المدرجة .

على الرغم من عدم وجود بيانات لدي لدعم ادعائي ، إلا أنني أعتقد أن هناك العديد من السجلات الخاصة التي تعمل خلف جدران الحماية أكثر من السجلات التي تعمل على الإنترنت المفتوح. في هذه الحالة ، يكون تكوين ssh أسهل وأكثر أمانًا من TLS إن لم يكن أكثر.

علاوة على ذلك ، بعد أن قاتلت لأيام مع docker push وسجل محلي خاص يعمل داخل جهاز ظاهري داخلي وآمن بدرجة كافية (والمزيد من الوقت الذي تكافح فيه لإنشاء شهادات موقعة ذاتيًا) ، لقد أصبحت للتو أقدر حقًا rkt --insecure-options=image,tls,http .

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

حالة الاستخدام الحالية الخاصة بي: تشغيل بيئة تطوير مع تكوين عامل الإرساء. تحتاج البيئة إلى سجل عامل ميناء محلي. الغرض منه هو العمل بالكامل على جهاز افتراضي محلي.

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

الحل المخترق: تشغيل socat في كل حاوية يحتاج إلى استخدام التسجيل ، وإعادة التوجيه إلى المضيف المحلي.

ليس بالضبط جعل الأمور سهلة ...

+1

من المؤسف حقًا - غير آمن ألا يكون تكوينًا للعميل!
هذا يسبب لنا الكثير من الألم كما هو مشابه جدًا للعديد من التفسيرات المذكورة أعلاه.
يرجى تعيين --insecure-Registry = 0.0.0.0 / 0 افتراضيًا يوفر pr طريقة لتمريره إلى أمر docker بالإضافة إلى تكوينات docker-compose.

+1

+1

هل حان الوقت لعقد حفل الشفقة السنوي مرة أخرى؟

في 13 كانون الأول (ديسمبر) 2016 ، الساعة 1:00 صباحًا ، كتب 沙包 妖 梦[email protected] :

+1

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub ، أو قم بكتم صوت الموضوع.

إذا تم توقيع طبقات الصور ، فلا داعي لاستخدام CA PKI للأمان. انظر أيضًا كيف يعمل apt / yum. علاوة على ذلك ، فإن استخدام SSL في شبكة LAN لا معنى له ، وفي بيئة السحابة ، فهذا يعني أنه يجب عليك توفير مصدر عشوائي جيد - بصرف النظر عن الشهادات نفسها - (انظر أيضًا: https://lukehinds.github.io/2015-03 -03-إنتروبيا-في-السحابة /).

قصة قصيرة طويلة: إذا كانت غير ضرورية ، فلا تفرضها على المستخدمين.

لقد فتحت للتو # 29736 وهو مرتبط.

+1 ، إذا لم يكن وجود علامة من جانب العميل --insecure-registry خيارًا ، فيجب أن تكون هناك طريقة لتحديد شهادة موثوق بها لاستخدامها في docker pull و docker push . ليس كل شخص لديه حق الوصول إلى شهادات الثقة على مستوى نظام التشغيل ، أو الوصول للعب مع Docker daemon.

تعد خوادم CI المستضافة (التي يتم استخدامها لإنشاء صور عامل الإرساء والدفع إلى سجل خاص) مثالًا رائعًا على الوقت الذي قد لا يكون لديك فيه هذا المستوى من الوصول.

+1

ajhodges https://docs.docker.com/registry/insecure/#using -self-موقّعة-الشهادات

تضمين التغريدة
يعمل فقط إذا كان لديك وصول sudo ...

+1 طريقة جيدة لثني المطورين عن استخدام عامل الإرساء

+1 ، أود أن أرى - التسجيل الآمن لـ docker login أيضًا.

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

إذا كانت لديك نوايا سيئة ، فيمكنك فقط تحميل صورة عامل الإرساء

+1 وبصراحة هذا يحير العقل

+1 لتدريب الألم.

Plus F * cking One!

هل هناك علاقات عامة مفتوحة لهذا؟

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

+1 كذلك ...

+1

+1 ، من غير الملائم إضافة الإعداد إلى deamon.json وإعادة تشغيل عامل الإرساء.

آلات مختلفة لها نظام تشغيل مختلف. تثبيت بعض عامل التثبيت من yum 、 apt-get ، والبعض الآخر يستخدم بشكل مباشر. لذلك يجب أن أكتشف ذلك وأعيد تشغيل dockerd بشكل صحيح ... هذه كارثة

أنا فقط أؤكد سحب عامل ميناء تحتاج --insecure-registry العلم!

لقد مرت ثلاث سنوات فقط - دعونا لا نفقد الأمل الآن

نتوء 🤣

+1

+1

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

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

على أقل تقدير ، يجب أن يكون برنامج عامل الإرساء قابلاً للتكوين للسماح بتمرير معلمة التسجيل غير الآمنة. يؤدي ذلك إلى نقل تصميم الأمان إلى المكان المناسب - في يد المسؤول ، وخارج عامل الإرساء نفسه.

FWIW سأكون سعيدًا بأمر "إضافة بعض السجلات إلى قائمة السجلات غير الآمنة" ، نظرًا لأن تصحيح تكوينات json من نصوص shell يمثل نقطة ضعف رئيسية.

+1

: +1: +1

+1

+1

+1

+1

ستجعل العديد من التطبيقات المطلوبة لهذا من المستحيل على الشركات التي تستخدم Docker الالتزام بمتطلبات الامتثال SOC ، وما إلى ذلك.

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

ومع ذلك ، يجب أن يحدث ذلك.

لم أعد مشتركًا في تطوير Docker ، لذا سأزيل نفسي من الإشارات. حظا سعيدا yall ^ _ ^

شرط SOC هو نقطة جيدة. في هذه الحالة ، يجب تمكين هذه الميزة مع خيار تكوين لإضافته إلى تكوين عامل إرساء على مستوى النظام. بهذه الطريقة يمكن الاحتفاظ بمتطلبات SOC. شيء من هذا القبيل "ALLOW_INSECURE_REGISTY_OPTION" والذي يمكّن علامة --insecure-Registry على سطر أوامر عامل الإرساء.

للامتثال SOC ، يجب عدم تمكين الخيار.

+1

لقد مرت ثلاث سنوات فقط - دعونا لا نفقد الأمل الآن

5.

هذا الاقتراح (في شكله الحالي) من غير المرجح أن يتم تنفيذه ، لمختلف
الأسباب ، من بينها ؛

• إنها تحافظ على الشخص الذي يدير برنامج عامل الإرساء مسؤولاً عن الاتصالات
  الشيطان مسموح به. لاحظ أن هذا الخيار يمكن "إعادة تحميل مباشر" ،
  لذلك لا يلزم إعادة تشغيل البرنامج الخفي لتغيير التكوين.
• سيكون لكل أمر أو مسار رمز من المحتمل أن يتفاعل مع السجل
  إلى تعديل؛ ليس فقط docker pull ، ولكن أيضًا docker build ، docker run ،
  الأوامر الفرعية docker plugin ، docker service و docker stack ، بالإضافة إلى
  المنسقون مثل swarmkit ، الذين يسحبون الصور من عقد العمال.
• الامتثال SOC (كما هو مذكور أعلاه)

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

أعتقد أن المسؤول في هذه الحالة سيكون الشخص / الفريق الذي يدير
المضيفات التي يعمل عليها برنامج Docker daemon ، وليس المستخدم الذي يتصل بجهاز التحكم عن بُعد
API. هذا هو سبب هذا التكوين ليكون تكوين خفي.

ترقيع تكوينات json من البرامج النصية للقذيفة هي نقطة ألم رئيسية.

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

شيء من هذا القبيل "ALLOW_INSECURE_REGISTY_OPTION" والذي يمكّن علامة --insecure-Registry على سطر أوامر عامل الإرساء.

إذا كنت تريد السماح بعمليات سحب غير آمنة من أي سجل (والذي سيكون مكافئًا
بإضافة علامة --insecure-registry ) ، يمكنك السماح لـ "الإنترنت" بعدم الأمان
التسجيل ؛ يجب أن يسمح ما يلي باستخدام أي عنوان IPv4 كسجل غير آمن ،
(وبالتالي الرجوع إلى اتصالات بخلاف TLS) ؛

من خلال ملف التكوين /etc/docker/daemon.json ؛

{"insecure-registries": ["0.0.0.0/1","128.0.0.0/2","192.0.0.0/3","224.0.0.0/4"]}

أو بتمرير الخيارات كعلامات على البرنامج الخفي (والذي يمكن تعيينه في systemd
ملف تجاوز) ؛

dockerd \
    --insecure-registry=0.0.0.0/1 \
    --insecure-registry=128.0.0.0/2 \
    --insecure-registry=192.0.0.0/3 \
    --insecure-registry=224.0.0.0/4