أتساءل ما إذا كان # 6075 سيمنحك ما تحتاجه

قد تجعل الحاوية السرية الأمر أكثر أمانًا قليلاً ، لكن جميع النقاط المذكورة لا تزال قائمة.

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

+1. لقد بدأت للتو في بلل قدمي باستخدام Docker وكان هذا أول حاجز أصطدم به. لقد قضيت بعض الوقت في محاولة استخدام VOLUME لتركيب جورب المصادقة قبل أن أدرك أن عامل الإرساء لا يمكنه / لن يقوم بتركيب وحدة تخزين مضيفة أثناء الإنشاء.

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

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

إليك بعض الأشخاص الآخرين الذين لديهم نفس حالة الاستخدام: https://twitter.com/damncabbage/status/453347012184784896

من فضلك ، احتضن SSH_AUTH_SOCK ، إنه مفيد للغاية.

شكرا

تحرير: الآن بعد أن عرفت المزيد حول كيفية عمل Docker (طبقات FS) ، من المستحيل القيام بما وصفته فيما يتعلق بإضافة مفتاح SSH أثناء الإنشاء وحذفه لاحقًا. سيظل المفتاح موجودًا في بعض طبقات الخدمة الثابتة.

+1 ، القدرة على استخدام SSH_AUTH_SOCK ستكون مفيدة للغاية!

أستخدم مفاتيح SSH للمصادقة مع Github ، سواء كان مستودعًا خاصًا أو عامًا.

هذا يعني أن أوامر git clone تبدو كما يلي: git clone [email protected]:razic/my-repo.git .

يمكنني تحميل مجلد مضيفي ~/.ssh في حاوياتي أثناء docker run و ssh كل شيء جيد. ومع ذلك ، لا يمكنني تحميل ~/.ssh خلال docker build .

: +1: لإعادة توجيه ssh أثناء الإنشاءات.

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

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

تعجبني فكرة # 6697 (مخزن / قبو سري) ، وقد ينجح ذلك بمجرد دمجه. ولكن إذا لم ينجح ذلك ، فإن البديل هو القيام بأشياء سرية للرجل في الوسط خارج برنامج Docker daemon ، اعتراض حركة مرور Docker daemon (ليس داخليًا). بدلاً من ذلك ، يمكن أن تكون جميع طلبات git + ssh موجهة إلى مضيف محدد محليًا يقوم بوكلاء github بشفافية أو أي شيء تريده في النهاية.

لقد تم بالفعل طرح هذه الفكرة (انظر التعليق 2). لا يحل المشكلة.

+1 لإعادة توجيه ssh أثناء الإنشاءات.

+1 على إعادة توجيه وكيل SSH على docker build

+1 لإعادة توجيه ssh أثناء الإنشاء لأمثال تثبيت npm أو ما شابه ذلك.

هل حصل أي شخص على عمل إعادة توجيه ssh أثناء التشغيل على OSX؟ لقد طرحت سؤالاً هنا: http://stackoverflow.com/questions/27036936/using-ssh-agent-with-docker/27044586؟noredirect=1#comment42633776_27044586 يبدو أنه غير ممكن مع OSX ...

+1 = (

فقط اصطدم بهذا الحاجز أيضًا. محاولة تشغيل npm install وأشار إلى الريبو الخاص. الإعداد يشبه:
host -> vagrant -> docker يمكنه إعادة توجيه وكيل ssh host -> vagrant -! docker

+1
ما عليك سوى النقر على هذا أثناء محاولة اكتشاف كيفية جعل وكيل ssh يعمل أثناء "إنشاء عامل ميناء".

+1 نفس اللاعبين السابقين. يبدو الحل الأفضل لهذه المشكلة عند الحاجة إلى الوصول إلى واحد أو أكثر من مستودعات git الخاصة (فكر في bundle install و npm install على سبيل المثال) عند إنشاء صورة Docker.

يمكنني تخزين مجلد مضيفي ~ / .ssh في حاوياتي أثناء تشغيل عامل الإرساء و ssh جيد.

razic هل يمكنك مشاركة كيف تحصل على هذا العمل؟ لأنني عندما حاولت ذلك من قبل اشتكيت من "مالك أو أذونات سيئة"

ما لم تتأكد من أن جميع الحاويات تعمل بمستخدم معين أو أذونات تسمح لك بفعل ذلك؟

+1 على SSH_AUTH_SOCK

tonivdv ألق نظرة على الأمر docker run في التعليق الأولي حول هذه المسألة. يقوم الربط بتثبيت المسار المشار إليه بواسطة SSH_AUTH_SOCK إلى /tmp/ssh_auth_sock داخل الحاوية ، ثم يقوم بتعيين SSH_AUTH_SOCK في الحاوية إلى هذا المسار.

@ md5 أفترض أن razic و tonivdv يتحدثان عن تصاعد مثل هذا: -v ~/.ssh:/root/.ssh:ro ، لكن عند القيام بذلك ، فإن ملفات .ssh ليست مملوكة للجذر وبالتالي تفشل في فحوصات الأمان.

KyleJamesWalker نعم هذا ما أفهمه من razic والذي كان أحد محاولاتي منذ بعض الوقت ، لذلك عندما قرأت razic كان قادرًا على

tonivdv ، أود أيضًا أن أعرف ما إذا كان ذلك ممكنًا ، ولم أتمكن من العثور على أي شيء عندما حاولت آخر مرة.

+1 أنا مهتم ببناء بيئات مطوّرة يمكن التخلص منها باستخدام Docker ولكن لا يمكنني تشغيلها تمامًا. هذا من شأنه أن يساعد كثيرا في هذا الصدد.

لأي شخص يبحث عن حل مؤقت ، لدي إصلاح أستخدمه في أي من الأشياء الغاشمة تفرض:

https://github.com/atrauzzi/docker-laravel/blob/master/images/php-cli/entrypoint.sh

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

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

+1 هذا سيكون رائعًا

tonivdv يتم إنشاء الحاوية التي من

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

: +1: لإعادة توجيه ssh عبر الإنشاء

يجب أن يكون هنا أيضًا!

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

docker run -ti --volumes-from ssh-data ...

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

لإنشاء تلك الحاوية ، أفعل ما يلي

docker run \
  --name ssh-data \
  -v /root/.ssh \
  -v ${USER_PRIVATE_KEY}:/root/.ssh/id_rsa \
  busybox \
  sh -c 'chown -R root:root ~/.ssh && chmod -R 400 ~/.ssh'

آمل أن يساعد هذا الآخرين :)

هتافات

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

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

لن أجعل من الضروري أن يحتفظ الأشخاص الذين يشغلون حاوياتك بحاوية بيانات فقط مليئة بمفاتيح ssh. يبدو متورطا.

atrauzzi صحيح أن حاوية الحجم يجب أن تكون موجودة ، ولكن في طريقتك يجب على المستخدم مشاركة مفتاح ssh الخاص به عند التشغيل بشكل صحيح جدًا؟ بالإضافة إلى الحاجة إلى حاوية حجم ssh ، فإن الاختلاف الوحيد في كلا الحلين من وجهة نظر التشغيل هو:

docker run ... --volumes-from ssh-data ... php-cli ...

و

docker run ... -v ~/.ssh:/path/.host-ssh ... php-cli ..

حق؟ أم أنني أفتقد شيئًا آخر :)

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

كما قلت ، كلاهما عبارة عن حل ولكل منهما إيجابيات وسلبيات.

هتافات

سيكون من الرائع حقًا الحصول على تحديث من فريق Docker حول حالة هذه الميزة. على وجه التحديد ، مصادقة SSH من docker build .

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

التحديث سيكون محل تقدير كبير. من فضلك و شكرا لك.

/ ccphemmer

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

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

أعلم أنكم لا تتجاهلونا يا رفاق :)

إذن الوضع هو:

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

هل هذا يبدو دقيقا بالنسبة لك؟

أيضًا ، هل هناك حاليًا أي مقترحات مفتوحة تعالج هذه المشكلة؟

في يوم الثلاثاء ، 7 أبريل 2015 ، كتبت Jessie Frazelle [email protected] :

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

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

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

نعم

ولا أعتقد أن هناك أي مقترحات مفتوحة لهذا الغرض.

يوم الثلاثاء ، 7 نيسان (أبريل) 2015 الساعة 2:36 مساءً ، زكاري آدم كابلان <
[email protected]> كتب:

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

أعلم أنكم لا تتجاهلونا يا رفاق :)

إذن الوضع هو:

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

هل هذا يبدو دقيقا بالنسبة لك؟

أيضًا ، هل هناك حاليًا أي مقترحات مفتوحة تعالج هذه المشكلة؟

في الثلاثاء 7 أبريل، 2015، جيسي Frazelle [email protected]
كتب:

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

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

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

لا أعرف ما إذا كنت أفرط في تبسيط الأشياء ، ولكن هذا هو اقتراحي:

SSHAGENT: إعادة توجيه # الإعدادات الافتراضية لتجاهلها

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

ليس لدي أي خبرة في العمل داخل قاعدة كود عامل الإرساء ، لكن هذا مهم بما يكفي بالنسبة لي لدرجة أنني سأفكر في توليه.

باهر. أين يمكنني معرفة كيفية تقديم عرض؟ هل يوجد
إرشادات محددة أم يجب أن أفتح مشكلة فقط؟

في يوم الثلاثاء ، 7 أبريل 2015 ، كتبت Jessie Frazelle [email protected] :

إنه شيء نفكر في تنفيذه إذا كان هناك قبول
اقتراح
وعرض النطاق الترددي الهندسي.

نعم

ولا أعتقد أن هناك أي مقترحات مفتوحة لهذا الغرض.

يوم الثلاثاء ، 7 نيسان (أبريل) 2015 الساعة 2:36 مساءً ، زكاري آدم كابلان <
[email protected]
<_e i = "18">

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

أعلم أنكم لا تتجاهلونا يا رفاق :)

إذن الوضع هو:

إنه شيء نفكر في تنفيذه إذا كان هناك قبول
اقتراح
وعرض النطاق الترددي الهندسي.

هل هذا يبدو دقيقا بالنسبة لك؟

أيضًا ، هل هناك حاليًا أي مقترحات مفتوحة تعالج هذه المشكلة؟

في يوم الثلاثاء ، 7 أبريل 2015 ، جيسي فرازيل < [email protected]
كتب <_e i = "31" />:

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

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

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

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

أعني مثل اقتراح التصميم
https://docs.docker.com/project/advanced-contributing/#design -proposal

الثلاثاء، 7 أبريل 2015 في 14:39، دانيال Staudigel [email protected]
كتب:

لا أعرف ما إذا كنت أفرط في تبسيط الأشياء ، ولكن هذا هو اقتراحي:

SSHAGENT: إعادة توجيه # الإعدادات الافتراضية لتجاهلها

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

ليس لدي أي خبرة في العمل داخل قاعدة كود عامل الإرساء ، لكن هذا
مهم بما يكفي بالنسبة لي لدرجة أنني سأفكر في توليه.

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

هذه فكرة عالية المستوى حقًا ، ولكن ماذا لو قام عامل التحميل بتشغيل برنامج خفي ، مع برنامج خفي ssh مجمّع ، داخل الحاوية بدلاً من إرفاقه من خلال واجهة برمجة التطبيقات البعيدة لعمال التحميل؟

يمكن استخدام هذا لحل عدد من القضايا.

• سيكون هذا البرنامج الخفي هو PID 1 ، وستكون عملية الحاوية الرئيسية هي PID 2. وهذا من شأنه أن يحل جميع المشكلات المتعلقة بتجاهل إشارات PID 1 والحاويات التي لا يتم إغلاقها بشكل صحيح. (# 3793)
• سيسمح ذلك بإعادة توجيه وكيل مفتاح SSH بشكل نظيف. (# 6396)
• هذا البرنامج الخفي يمكنه إبقاء مساحات الأسماء مفتوحة (# 12035)
• سيتم إنشاء TTY بواسطة البرنامج الخفي (# 11462)
• ... وربما العديد من القضايا الأخرى التي أنساها.

قد ترغب في رؤية https://github.com/docker/docker/issues/11529 حول ملف
النقطة الأولى

الثلاثاء، 7 أبريل 2015 في 02:46، باتريك Hemmer [email protected]
كتب:

هذه فكرة عالية المستوى حقًا ، ولكن ماذا لو بدلاً من الارتباط بها
واجه عامل ميناء التحكم عن بعد ، قام عامل الميناء بتشغيل البرنامج الخفي لـ init ، مع ssh المجمعة
شيطان ، داخل الحاوية؟

يمكن استخدام هذا لحل عدد من القضايا.

• سيكون هذا البرنامج الخفي هو PID 1 ، وستكون عملية الحاوية الرئيسية
  PID 2. سيؤدي ذلك إلى حل جميع المشكلات المتعلقة بإشارات تجاهل PID 1 و
  الحاويات لا تغلق بشكل صحيح. (# 3793
  https://github.com/docker/docker/issues/3793)
• سيسمح ذلك بإعادة توجيه وكيل مفتاح SSH بشكل نظيف. (# 6396
  https://github.com/docker/docker/issues/6396)
• يمكن لهذا البرنامج الخفي الاحتفاظ بمساحات أسماء مفتوحة (# 12035
  https://github.com/docker/docker/issues/12035)
• سيتم إنشاء TTY بواسطة البرنامج الخفي (# 11462
  https://github.com/docker/docker/issues/11462)
• ... وربما العديد من القضايا الأخرى التي أنساها.

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

11529 غير مرتبط تمامًا بمسألة PID 1.

تبادل لاطلاق النار ، ولصق النسخ ، والآن لا بد لي من العثور على الآخر مرة أخرى

لا ، هذا هو الأمر ، فهو يعمل على إصلاح أشياء زومبي PID 1 وهو ما اعتقدت أنك تشير إليه ولكن بغض النظر عن أنني كنت أنشر للتو ، لأن الأمر كله يتعلق بالصحة

phemmer يبدو أن لديك الخبرة

يبدو أيضًا أن dts وأنا على استعداد لقضاء بعض الوقت في العمل على ذلك.

phemmer و dts هل هناك أي طريقة ممكنة يمكننا من خلالها تحويل هذه المناقشة إلى عميل دردشة في الوقت الفعلي أكثر قليلاً لتسهيل الاتصال؟ أنا متاح من خلال Slack و Google Chat / Hangout و IRC وسأقوم بتنزيل أي شيء آخر إذا لزم الأمر.

phemmer يبدو أن لديك الخبرة

لسوء الحظ ليس حقًا :-)
يمكنني طرح أفكار التصميم ، لكنني أعرف فقط أجزاء صغيرة من قاعدة رمز عامل الإرساء. من المحتمل أن يكون هذا النوع من التغيير واسع النطاق.

كانت هناك بعض المقترحات هنا بالفعل:

اقترح @ phemmer

ماذا لو ، بدلاً من الإرفاق من خلال واجهة برمجة التطبيقات البعيدة لعمال التحميل ، قام عامل التحميل بتشغيل برنامج خفي لـ init ، مع برنامج ssh الخفي المجمعة ، داخل الحاوية؟

اقترح dts

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

اقترح razic

تفعيل ربط وحدة التخزين لـ docker build .

ما نحتاجه حقًا في هذه المرحلة هو أن يقبل أحدهم أحدًا حتى نتمكن من البدء في العمل عليه.

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

يمكنني أن أكون متاحًا لاجتماع Slack / irc / Gchat / إلخ ، وأعتقد أن هذا سيجعل الأمور أسهل قليلاً ، على الأقل لجمع المتطلبات واتخاذ قرار بشأن مسار معقول للعمل.

اقترح dts

SSHAGENT: إعادة توجيه # الإعدادات الافتراضية لتجاهلها

هذه مجرد فكرة عن كيفية استهلاكها ، وليس تنفيذها. "البرنامج الخفي init / ssh" هو فكرة عن كيفية تنفيذه. يمكن أن كلاهما موجود.

اقترح razic

تفعيل ربط وحدة التخزين لتشغيل عامل الإرساء.

للأسف هذا لن ينجح. بافتراض أن هذا يعني docker build ، وليس docker run ، والذي يدعم بالفعل عمليات تحميل وحدة التخزين ، يمكن أن يكون هناك عميل بعيد (boot2docker هو أحد الأمثلة البارزة). تعمل روابط وحدة التخزين فقط عندما يكون العميل على نفس مضيف برنامج عامل التحميل.

razic يرجى الاطلاع على هذا الرابط حول اقتراح التصميم ... هذه ليست مقترحات https://docs.docker.com/project/advanced-contributing/#design -proposal

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

أنا أفشل في فهم سبب عدم نجاح ذلك بالضبط. docker-compose مع وحدات التخزين على مجموعة swarm . إذا لم يكن الملف / المجلد على النظام المضيف ، فإنه يمارس نفس السلوك كما لو قمت بتشغيل -v بمسار غير موجود.

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

إذا لم يكن الملف / المجلد على النظام المضيف ، فإنه يمارس نفس السلوك كما لو قمت بتشغيل -v بمسار غير موجود على عامل إرساء محلي.

لست متأكدًا من أنني أتابع وجهة نظرك. كيف يساعد هذا السلوك في هذه القضية؟
إذا كان لدي وكيل مفتاح ssh يستمع بسعر /tmp/ssh-UPg6h0 على جهازي المحلي ، وكان لدي عامل إرساء يعمل على جهاز بعيد ، وأتصل بـ docker build ، فإن وكيل مفتاح ssh المحلي لا يمكن الوصول إليه من قبل Docker daemon. لن تحصل عليه وحدة التخزين ، ولن تتمكن حاويات docker build الوصول إلى مفتاح ssh.

من مستوى عالٍ ، أرى طريقتين فقط لحل هذا:

1. توكيل مقبس وكيل مفتاح ssh:

ينشئ برنامج Docker daemon مقبس مجال unix داخل الحاوية وكلما يتصل به شيء ما ، فإنه يقوم بوكلاء هذا الاتصال مرة أخرى إلى العميل الذي يقوم بالفعل بتشغيل الأمر docker build .

قد يكون هذا صعب التنفيذ حيث يمكن أن يكون هناك عدد تعسفي من الاتصالات بمقبس مجال unix هذا داخل الحاوية. قد يعني هذا أنه يجب على برنامج Docker daemon & client أن يقوم بتوكيل عدد تعسفي من الاتصالات ، أو يجب أن يكون البرنامج الخفي قادرًا على التحدث ببروتوكول وكيل ssh ، ومضاعفة الطلبات.

ومع ذلك ، بعد أن أصبحت واجهة برمجة التطبيقات (API) البعيدة ل Docker تدعم مآخذ الويب (لم تكن كذلك في وقت إنشاء هذه المشكلة) ، فقد لا يكون هذا صعبًا للغاية.

2. ابدأ برنامج خفي SSH فعلي

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

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

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

لست متأكدًا من أنني أتابع وجهة نظرك. كيف يساعد هذا السلوك في هذه القضية؟

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

أنت تبني الصورة على جهاز يحتوي على مفتاح SSH. بهذه البساطة.

إذا كان لدي وكيل مفتاح ssh يستمع إلى / tmp / ssh-UPg6h0 على جهازي المحلي ، ولدي عامل إرساء يعمل على جهاز بعيد ، وقمت ببناء عامل ميناء ، فإن وكيل مفتاح ssh المحلي لا يمكن الوصول إليه من قبل برنامج عامل ميناء.

أنا أعرف. من يهتم؟ سأقوم بتشغيل docker build على جهاز يمكنه الوصول إلى مقبس المصادقة.

ما أحاول قوله هو .... docker-compose يسمح لك باستخدام أمر volume ضد مجموعة swarm ، بغض النظر عما إذا كان الملف موجودًا بالفعل على المضيف أم لا! .

يجب أن نفعل الشيء نفسه بالنسبة لحجم التحميل على بنى عامل الإرساء.

| الملف موجود على النظام | العمل |
| : - | : - |
| نعم | جبل |
| لا | لا شيء (في الواقع يحاول نوعًا ما التحميل ولكنه ينشئ مجلدًا فارغًا إذا لم يكن الملف / المجلد موجودًا ، يمكنك التحقق من ذلك عن طريق تشغيل docker run -v /DOES_NOT_EXIST:/DOES_NOT_EXIST ubuntu ls -la /DOES_NOT_EXIST ) |

أحد المفاهيم الكامنة وراء swarm هو جعل نموذج المضيف المتعدد شفافًا.

من الجيد أننا نفكر في عامل إرساء بعيد ، لكن لا ينبغي أن يكون الأمر مهمًا حقًا.

يجب علينا فقط نسخ سلوك تركيب وحدة التخزين لـ docker build بنفس الطريقة التي نستخدمها بالضبط لـ docker run .

من https://github.com/docker/compose/blob/master/SWARM.md :

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

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

phemmer أعتقد أن الناس ربما يفكرون في حل للمشكلة التي وصفتها. تبدو المشكلة التي تصفها مثل https://github.com/docker/docker/issues/7249 وهي منفصلة.

إذا اتبعنا أسلوبي: السماح فقط بتركيب وحدة التخزين في بناء عامل الإرساء (بغض النظر عما إذا كان الملف الذي تحاول تحميله موجودًا بالفعل على النظام ، فيمكننا إغلاق هذه المشكلة. والبدء في العمل على https://github.com/ docker / docker / issues / 7249 والذي من شأنه أن يوسع سلوك هذه الميزة للعمل مع شياطين عامل الإرساء البعيدة التي لا تحتوي على الملف المحلي.

@ cpuguy83 قبل أن أقوم بإنشاء اقتراح ، كنت أنظر إلى # 7133 ولاحظت أنه يبدو مرتبطًا بشكل مباشر.

هل يمكنك فقط إضافة بضع كلمات هنا؟ هو # 7133 متعلقًا بالفعل باقتراحي لإصلاح هذه المشكلة ، وهو السماح لـ docker build بدعم وحدات التخزين.

razic يتعلق الأمر بحقيقة أن VOLUME /foo يقوم بالفعل بإنشاء وحدة تخزين وتثبيتها في الحاوية أثناء الإنشاء ، وهو أمر غير مرغوب فيه بشكل عام.

أود أن أقول أيضًا أن الاقتراح الذي يعتمد على استخدام أدوات الربط لإدخال الملفات في حاويات البناء لن يطير على الأرجح.
انظر # 6697

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

في يوم الأربعاء ، 8 أبريل 2015 ، كتب Brian Goff [email protected] :

razic https://github.com/razic يتعلق الأمر بحقيقة أن الحجم
يقوم / foo بالفعل بإنشاء وحدة تخزين وتركيبها في الحاوية أثناء
البناء ، وهو أمر غير مرغوب فيه بشكل عام.

أود أن أقول أيضًا اقتراحًا يعتمد على استخدام أدوات الربط لإدخال الملفات
بناء الحاويات ربما لن تطير.
انظر # 6697 https://github.com/docker/docker/pull/6697

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

@ cpuguy83 شكرا للتوضيح.

6697 أيضًا لن يطير لأنه مغلق بالفعل و # 10310 هو عمليًا خدعة # 6697.

+1 ، لقد ضربت هذا اليوم للتو أثناء محاولتي إنشاء صورة لتطبيق ريلز يستخدم Bower لتثبيت تبعيات جانب العميل. يحدث أن إحدى التبعيات تشير إلى [email protected]:angular/bower-angular-i18n.git وبما أن git فشل هناك ، فشل bower ، وفشل بناء الصورة أيضًا.

أنا حقا أحب ما يفعله المتشرد بالمناسبة. من خلال تكوين forward_agent واحد في Vagrantfile ، يتم حل هذا للضيوف المتشردين. هل يستطيع Docker تنفيذ شيء كهذا؟

أيضًا ، كملاحظة إضافية ، يحدث هذا أثناء بناء الصورة. لا أحد يعرف أي الحلول الحالية؟

كان الحل البديل الخاص بي هو إنشاء زوج مفاتيح RSA جديد ، وإعداد مفتاح الحانة على جيثب (إضافة بصمة الإصبع) ، وإضافة المفتاح الخاص إلى صورة Docker:

ADD keys/docker_rsa /srv/.ssh/id_rsa

أود تجنب هذا ، لكن أعتقد أن هذا مقبول في الوقت الحالي. نقدر أي اقتراحات أخرى!

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

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

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

fullofcaffeine لست متأكدًا بنسبة 100٪ من كيفية عمل Docker داخليًا ، لكنني أعتقد أنه ما لم يتم ذلك في أمر RUN واحد (وهو أمر مستحيل مع الحل البديل) ، فإن محفوظات الصورة تحافظ على مفتاح SSH.

razic نقطة جيدة.

كعمل للتغلب على هذا القيد ، كنا نتلاعب بفكرة تنزيل المفاتيح الخاصة (من خادم HTTP محلي) ، وتشغيل أمر يتطلب المفاتيح وحذفها بعد ذلك.

نظرًا لأننا نقوم بكل هذا في RUN ، فلن يتم تخزين أي شيء مؤقتًا في الصورة. إليك كيف يبدو في Dockerfile:

RUN ONVAULT npm install --unsafe-perm

يتوفر تطبيقنا الأول حول هذا المفهوم على

العيب الوحيد يتطلب تشغيل خادم HTTP ، لذلك لا يتم إنشاء لوحة Docker.

اسمحوا لي أن أعرف ما هو رأيك :)

+1
أرغب في رؤية تنفيذ هذا الأمر ، فسيساعد ذلك في إنشاء حاويات لبيئة التطوير

+1 ، فقط بحاجة إلى وكيل ssh المُعاد توجيهه باستخدام boot2dock

لقد انتهينا من إجراء عملية من 3 خطوات للالتفاف على هذا القيد:

1. قم ببناء حاوية عامل ميناء بدون التبعيات المطلوبة لـ SSH ، مع إضافة المصدر في الخطوة الأخيرة
2. تحميل المصدر عبر وحدة التخزين المشتركة ، بالإضافة إلى SSH_AUTH_SOCK عبر وحدة التخزين المشتركة وتشغيل خطوة البناء ، وكتابة الإخراج الذي يتطلب ssh (على سبيل المثال ، أحجار ياقوت مستضافة على جيثب) مرة أخرى في وحدة التخزين المشتركة
3. إعادة تشغيل بناء docker ، والذي سيعيد تشغيل إضافة المصدر ، نظرًا لأن الأحجار الكريمة موجودة الآن في دليل المصدر

والنتيجة هي صورة عامل إرساء مع تبعيات تم سحبها عبر مصادقة SSH التي لم يكن بها مفتاح SSH مطلقًا.

لقد قمت بإنشاء برنامج نصي لتمكين إعادة توجيه وكيل ssh مقابل docker run في بيئة boot2docker على OSX بأقل قدر من المتاعب. أعلم أنه لا يحل مشكلة الإصدار ، ولكنه قد يكون مفيدًا للبعض:

https://gist.github.com/rcoup/53e8dee9f5ea27a51855

هل يعمل وكيل Forward ssh الرئيسي مع خدمات مثل Amazon EC 2 Container Service؟ يبدو لي أن هذا سيتطلب برنامجًا محددًا قد لا يتوفر على جميع الأنظمة الأساسية أو PaaS التي تستخدمها لنشر حاوياتك.

مطلوب حل أكثر عمومية ، والعمل للجميع.

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

FWIW ، لقد وجدت أن عامل ssh المعبأ في حاويات ومشاركة الحجم يعملان بشكل جيد مع الحد الأدنى من الحماقة:

https://github.com/whilp/ssh-agent

سيكون من الرائع الحصول على دعم من الدرجة الأولى لهذا ، رغم ذلك.

من المهم التمييز بين ما يصلح في _run_ مقابل _build_. يعمل حل whilp بشكل رائع في _run_ ولكنه لا يعمل في _build_ لأنك لا تستطيع الوصول إلى مجلدات عمال الرصيف الأخرى أثناء _build_. ولهذا السبب لا تزال هذه البطاقة مؤلمة ومفتوحة.

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

هل عناوين IP لتشغيل الحاويات مضمنة في / etc / hosts أثناء الإنشاء؟ إذا كان الأمر كذلك ، فقد يكون أحد الحلول هو بدء حاوية تخدم المفاتيح ، ثم الالتفاف عليها أثناء الإنشاء.

قد تكون مهتمًا جميعًا بمعرفة أنني قمت بالتدوين حول طريقة لاستخدام وكيل SSH الخاص بك خلال docker build - http://aidanhs.com/blog/post/2015-10-07-dockerfiles-reproducibility- الخداع / # _ streamlining_your_experience_using_an_ssh_agent

أنت فقط بحاجة لبدء حاوية واحدة. بمجرد البدء ، يجب أن يعمل وصول وكيل SSH بشكل لا تشوبه شائبة مع 3 سطور إضافية فقط في Dockerfile - لا حاجة بعد الآن إلى كشف مفاتيحك في الحاوية.

بعض التحذيرات: تحتاج إلى Docker> = 1.8 ، ولن يعمل على بناء Docker Hub الآلي (من الواضح). يرجى أيضًا قراءة الملاحظة الخاصة بالأمن! لا تتردد في طرح المشكلات في مستودع sshagent github الذي أرتبط به في المنشور إذا كان لديك أي مشاكل.

لقد قمت أيضًا بحل هذه المشكلة بطريقة مماثلة لـ aidanhs - عن طريق سحب السر المطلوب عبر الشبكة الفرعية
https://github.com/mdsol/docker-ssh-exec

هل كان هناك أي تقدم في جعل هذا ممكنا؟ أنا غير قادر على ربط دليل المضيف ~/.ssh بسبب تعطل الأذونات والملكية.

ألن يكون هذا قابلاً للحل من خلال السماح لربط الربط بفرض uid / gid والأذونات المحددة؟

atrauzzi bind-mounts لا يمكنها فرض uid / gid / أذونات.
يمكن القيام بذلك عبر FUSE (مثل bindfs) ، ولكن ليس فقط مع حوامل الربط العادية.

@ cpuguy83 بدأ هذا حقًا يأخذني في الطرق التي لا أريد التعامل معها. خاصة عندما أستخدم مضيفًا يستند إلى Windows.

لا يوجد خيار سهل الاستخدام هنا؟ أشعر وكأن هناك مشكلة هنا تم تأجيلها للتو.

atrauzzi في الواقع ، ليس من السهل حلها على المدى القريب (ليس بسلاسة على أي حال).

يعد إجراء +1 هذا مانعًا كبيرًا لملف Dockerfile لتطبيق Node.js البسيط. لقد عملت على العديد من تطبيقات Node ، ونادراً ما رأيت تطبيقًا لا يحتوي على مستودع Github خاص باعتباره تابعًا لـ NPM.

كحل بديل apeace ، يمكنك محاولة إضافتها كوحدة (وحدات) git الفرعية إلى git repo. بهذه الطريقة يكونون في السياق ويمكنك فقط إضافتهم أثناء الإنشاء وإذا كنت تريد أن تكون نظيفًا حقًا ، فاحذف أو تجاهل ملف .git في كل ملف. في بناء عامل الإرساء ، يمكن تثبيتها فقط باستخدام الدليل المحلي. إذا كانوا بحاجة إلى مستودعات git كاملة لسبب ما ، فتأكد من عدم وجود ملف .git في إنشاء عامل الإرساء وإضافة .git/modules/<repo> كـ <path>/<repo>/.git . سيؤدي ذلك إلى التأكد من أنها عمليات إعادة شراء عادية كما لو تم استنساخها.

شكرًا على هذا الاقتراح jakirkham ، لكننا نستخدم كاعتماد NPM لفترة طويلة ، ولا أريد كسر سير العمل العادي npm install .

في الوقت الحالي ، لدينا حل ناجح ولكنه صعب المراس. لدينا:

• إنشاء مستخدم وفريق Github الذي لديه وصول للقراءة فقط إلى المستودعات التي نستخدمها كاعتماديات NPM
• التزمت بالمفتاح الخاص لهذا المستخدم في الريبو الخاص بنا حيث لدينا Dockerfile
• في Dockerfile ، بدلاً من RUN npm install نقوم بعمل RUN GIT_SSH='/code/.docker/git_ssh.sh' npm install

حيث يكون git_ssh.sh نصًا كالتالي:

#!/bin/sh
ssh -o StrictHostKeyChecking=no -i /code/.docker/deploy_rsa "$@"

إنه يعمل ، ولكن إعادة توجيه وكيل مفتاح ssh سيكون أجمل بكثير ، وأقل بكثير من أعمال الإعداد!

: +1:
لا يمكنني تصديق أن طلب الميزة هذا لم يتم تنفيذه بعد نظرًا لوجود الكثير من حالات الاستخدام حيث يطلب الأشخاص الوصول من عمليات إعادة الشراء الخاصة أثناء وقت الإنشاء.

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

: +1:

: +1: كنت بحاجة إلى هذا إلى الأبد.

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

إنه مزيج من البرنامج النصي وخادم الويب. ما رأيك https://github.com/dockito/vault ؟

pirelenito ألا يجعل هذا المفتاح متاحًا داخل طبقة من

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

apeace في Medidata ، نستخدم أداة صغيرة -ssh-exec . إنه يترك فقط ثنائي docker-ssh-exec في صورة البناء الناتجة - لا توجد أسرار. ولا يتطلب سوى تغيير كلمة واحدة إلى Dockerfile ، لذا فهو "تأثير منخفض" للغاية.

ولكن إذا كنت تحتاج _ حقًا_ إلى استخدام حل عامل ميناء أصلي فقط ، فهناك الآن طريقة مضمنة للقيام بذلك ، كما هو مذكور في منشور مدونة الشركة . يتيح لك Docker 1.9 استخدام المعلمة --build-arg لتمرير القيم المؤقتة لعملية الإنشاء. يجب أن تكون قادرًا على تمرير مفتاح SSH خاص كـ ARG ، وكتابته في نظام الملفات ، وتنفيذ git checkout ، ثم _delete_ المفتاح ، كل ذلك في نطاق RUN التوجيه docker-ssh-exec ). سيؤدي هذا إلى الحصول على Dockerfile قبيحًا ، لكن يجب ألا يتطلب أي أدوات خارجية.

أتمنى أن يساعدك هذا.

benton لقد توصلنا إلى حل مماثل. :)

شكرًا pirelenito و @ benton ، سأقوم بفحص كل اقتراحاتكم!

تحرير : ما يلي _NOT_ آمن ، في الواقع:

للتسجيل ، إليك كيفية التحقق من الريبو الخاص من Github دون ترك مفتاح SSH في الصورة الناتجة.

أولاً ، استبدل user/repo-name في Dockerfile بالمسار إلى الريبو الخاص بك (تأكد من الاحتفاظ بالبادئة [email protected] بحيث يتم استخدام ssh للخروج):

FROM ubuntu:latest

ARG SSH_KEY
ENV MY_REPO [email protected]:user/repo-name.git

RUN apt-get update && apt-get -y install openssh-client git-core &&\
    mkdir -p /root/.ssh && chmod 0700 /root/.ssh && \
    ssh-keyscan github.com >/root/.ssh/known_hosts

RUN echo "$SSH_KEY" >/root/.ssh/id_rsa &&\
    chmod 0600 /root/.ssh/id_rsa &&\
    git clone "${MY_REPO}" &&\
    rm -f /root/.ssh/id_rsa

ثم بناء مع الأمر

docker build --tag=sshtest --build-arg SSH_KEY="$(cat ~/.ssh/path-to-private.key)" .

تمرير المسار الصحيح لمفتاح SSH الخاص بك.

^ مع Docker 1.9

benton قد ترغب في إلقاء نظرة فاحصة على ناتج docker inspect sshtest و docker history sshtest . أعتقد أنك ستجد أن البيانات الوصفية في الصورة النهائية لها سرك حتى لو لم تكن متوفرة داخل سياق الحاوية نفسه ...

ljrittle اكتشاف جيد. المفتاح موجود بالفعل إذا كنت تستخدم VAR . أعتقد أن الحل الخارجي لا يزال مطلوبًا هنا.

ربما يكون أحد أسباب عدم تطوير حل أصلي بعد هو وجود العديد من الحلول البديلة. لكنني أتفق مع معظم الآخرين هنا على أن الحل المدمج من شأنه أن يخدم المستخدمين بشكل أفضل ، ويلائم فلسفة Docker "المضمنة بالبطاريات".

من المستندات ...

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

(https://docs.docker.com/engine/reference/builder/#arg)

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

أنا لا أتبعjcrombez. المثال هو تمرير مفتاح ssh كمتغير عبر ARG . لذلك ، فإنه ينطبق.

من حيث المخاطر الأمنية ، هذا مختلف تمامًا:

docker build --tag=sshtest --build-arg SSH_KEY="$(cat ~/.ssh/path-to-private.key)" .

من هذا :

docker build --tag=sshtest --build-arg SSH_KEY="mykeyisthis" .

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

على سطر الأوامر ، أفترض.

لكن، وكما أشارljrittle واعترفbenton، بأي شكل من الأشكال التي تستخدمها --build-arg / ARG سيتم ارتكبت في الإنشاء. لذا فإن فحصه سيكشف عن معلومات حول المفتاح. كلاهما يترك حالته في حاوية الرصيف النهائية ويعاني كلاهما من نفس الضعف في هذه النهاية. ومن ثم ، لماذا يوصي عامل الميناء بعدم القيام بذلك.

_USER POLL_

_ إن أفضل طريقة للحصول على إخطارات بالتحديثات هي استخدام الزر _Subscribe_ في هذه الصفحة ._

الرجاء عدم استخدام تعليقات "+1" أو "لدي هذا أيضًا" على المشكلات. نحن تلقائيا
اجمع تلك التعليقات لإبقاء الموضوع قصيرًا.

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

@ fletcher91
تضمين التغريدة
تضمين التغريدة
تضمين التغريدة
saada
تضمين التغريدة
تضمين التغريدة
تضمين التغريدة
تضمين التغريدة
تضمين التغريدة
تضمين التغريدة
تضمين التغريدة
تضمين التغريدة
kouk
تضمين التغريدة
@ kotlas92
taion

_USER POLL_

_ إن أفضل طريقة للحصول على إخطارات بالتحديثات هي استخدام الزر _Subscribe_ في هذه الصفحة ._

الرجاء عدم استخدام تعليقات "+1" أو "لدي هذا أيضًا" على المشكلات. نحن تلقائيا
اجمع تلك التعليقات لإبقاء الموضوع قصيرًا.

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

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

من حيث المخاطر الأمنية ، هذا مختلف تمامًا:

docker build --tag=sshtest --build-arg SSH_KEY="$(cat ~/.ssh/path-to-private.key)" .

بصرف النظر عن تاريخ bash الخاص بك ، فإنهم متماثلون تمامًا ؛ هناك العديد من الأماكن حيث يمكن أن تنتهي هذه المعلومات.

على سبيل المثال ، ضع في اعتبارك أنه يمكن تسجيل طلبات API على الخادم ؛

هذا سجل خفي لـ docker build --tag=sshtest --build-arg SSH_KEY="fooobar" .

DEBU[0090] Calling POST /v1.22/build
DEBU[0090] POST /v1.22/build?buildargs=%7B%22SSH_KEY%22%3A%22fooobar%22%7D&cgroupparent=&cpuperiod=0&cpuquota=0&cpusetcpus=&cpusetmems=&cpushares=0&dockerfile=Dockerfile&memory=0&memswap=0&rm=1&shmsize=0&t=sshtest&ulimits=null
DEBU[0090] [BUILDER] Cache miss: &{[/bin/sh -c #(nop) ARG SSH_KEY]}
DEBU[0090] container mounted via layerStore: /var/lib/docker/aufs/mnt/de3530a82a1a141d77c445959e4780a7e1f36ee65de3bf9e2994611513790b8c
DEBU[0090] container mounted via layerStore: /var/lib/docker/aufs/mnt/de3530a82a1a141d77c445959e4780a7e1f36ee65de3bf9e2994611513790b8c
DEBU[0090] Skipping excluded path: .wh..wh.aufs
DEBU[0090] Skipping excluded path: .wh..wh.orph
DEBU[0090] Applied tar sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef to 91f79150f57d6945351b21c9d5519809e2d1584fd6e29a75349b5f1fe257777e, size: 0
INFO[0090] Layer sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef cleaned up

_USER POLL_

_ إن أفضل طريقة للحصول على إخطارات بالتحديثات هي استخدام الزر _Subscribe_ في هذه الصفحة ._

الرجاء عدم استخدام تعليقات "+1" أو "لدي هذا أيضًا" على المشكلات. نحن تلقائيا
اجمع تلك التعليقات لإبقاء الموضوع قصيرًا.

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

@ cj2

أحاول وضع تطبيق روبي / رف بسيط في حاويات. يشير Gemfile إلى العديد من الجواهر الخاصة. في اللحظة التي يبدأ فيها bundle install ويحاول الوصول إلى المستودعات الخاصة ، أبدأ في تلقي هذا الخطأ

Host key verification failed.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

تمكنت من حلها ولكن ليس بدون الكشف عن مفتاحي الخاص. هذا لن ينفع. الرجاء تمكين إعادة توجيه مصادقة ssh.

+1 لإعادة توجيه ssh أثناء الإنشاءات. لا يمكن استخدام go get مع عمليات إعادة الشراء الخاصة بسبب ذلك ؛ (

+1 لتمكين حالة الاستخدام هذه بطريقة آمنة

_USER POLL_

_ إن أفضل طريقة للحصول على إخطارات بالتحديثات هي استخدام الزر _Subscribe_ في هذه الصفحة ._

الرجاء عدم استخدام تعليقات "+1" أو "لدي هذا أيضًا" على المشكلات. نحن تلقائيا
اجمع تلك التعليقات لإبقاء الموضوع قصيرًا.

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

lukad

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

بمعنى آخر

استثناء .ssh

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

يعمل اقتراح benton بشكل جيد ، وسوف يقوم برنامج عامل الإرساء بتسجيل مفتاح id_rsa فقط إذا كان في وضع التصحيح.

طريقة لطيفة لفضح مفتاحك أثناء الإنشاء هي:

# Dockerfile
ARG SSH_KEY
RUN eval `ssh-agent -s` > /dev/null \
    && echo "$SSH_KEY" | ssh-add - \
    && git clone [email protected]:private/repository.git

docker build -t my_tag --build-arg SSH_KEY="$(< ~/.ssh/id_rsa)" .

Ha ، على الرغم من أنه موجود بالفعل هناك إذا نظرت إلى docker inspect my_tag .. لذا لست متأكدًا من القيمة الحقيقية لـ boot-arg ، بخلاف كونها مرتبة قليلاً من ENV.

وإذا كانت لديك كلمة مرور على مفتاح id_rsa ، أعتقد أنك قد تكون إنسانًا سيئًا وتقوم بما يلي:

# Dockerfile
ARG SSH_KEY
ARG SSH_PASS
RUN eval `ssh-agent -s` > /dev/null \
    && echo "echo $SSH_PASS" > /tmp/echo_ps && chmod 700 /tmp/echo_ps \
    && echo "$SSH_KEY" | SSH_ASKPASS=/tmp/echo_ps DISPLAY= ssh-add - \
    && git clone [email protected]:private/repository.git
    && rm /tmp/echo_ps

docker build -t my_tag --build-arg SSH_KEY="$(< ~/.ssh/id_rsa)" --build-arg SSH_PASS=<bad_idea> .

بالطبع ، من الصعب تبرير فكرة أن تكون فكرة جيدة عن بعد .. لكننا جميعًا بشر ، على ما أظن.

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

أود أن أقول فقط قم بتوريد تبعياتك وأضف المشروع بأكمله .. ولكن ، في بعض الأحيان تحتاج الأشياء إلى إنجازها الآن.

SvenDowideitthaJeztah هل هناك أي حل لهذه المشكلة؟ حاولت متابعة الموضوع ولكن بين إغلاق وفتح مواضيع أخرى والعديد من الآراء ليس لدي أي فكرة عما سيفعله فريق Docker أو متى.

الأفضل ولكن يحتاج التنفيذ؟

يستخدم Docker build ssh-agent داخل البناء للوكيل لـ ssh الخاص بالمضيف ثم استخدم مفاتيحك دون الحاجة إلى معرفتها!

لأي شخص يتعلم فقط عن وكيل ssh: github to the save

فكرةphemmer الأصلية.

yordis لا أعتقد أن هناك حلاً "رائعًا" في الموضوع المتاح مجانًا حتى الآن.

يبدو أن هذا التعليق من docker / docker-py # 980 يشير إلى أنه إذا قمت بنسخ مفاتيح ssh إلى دليل مفتاح المستخدم الجذر على نظامك المضيف ، فإن البرنامج الخفي سيستخدم هذه المفاتيح. ومع ذلك ، فأنا مبتدئ مجنون في هذا الصدد ، لذلك قد يتمكن شخص آخر من التوضيح.

حسنًا ، لكن ليس الأفضل

تمرير المفتاح باستخدام docker 1.8's build args.
المحاذير .

بالتأكيد فكرة سيئة

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

لماذا لم يذهب هذا إلى أي مكان بعد؟

يحتاج إلى اقتراح تصميم ، هذه المشكلة _cah_- _ مزدحمة _ والأفكار غامضة فقط في الوقت الحالي. تُفقد تفاصيل التنفيذ الفعلية وسط غيوم من "ماذا لو فعلنا س" و +1. للتنظيم والتحرك في هذه الميزة التي تشتد الحاجة إليها ، يجب على أولئك الذين لديهم حلول ممكنة إنشاء ملف. . .

اقتراح تصميم

ثم قم بالإشارة إلى هذه المشكلة.

لدي بعض الأخبار حول هذا الموضوع.

في DockerCon الأسبوع الماضي ، شجعنا على طرح أصعب أسئلتنا على جناح Docker "اسأل الخبراء" ، لذلك ذهبت وأجرت محادثة قصيرة مع مهندس ذكي وودود مع لقب مهندس الحلول المشجع. لقد أعطيته ملخصًا قصيرًا عن هذه المشكلة ، والذي آمل أن أكون قد نقلته بدقة ، لأنه أكد لي أنه يمكن القيام بذلك باستخدام _only_ docker-compose ! تضمنت تفاصيل ما كان يقترحه بناء متعدد المراحل - ربما لتجميع التبعيات في سياق مختلف عن بناء التطبيق النهائي - ويبدو أنها تنطوي على استخدام أحجام البيانات في وقت الإنشاء.

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

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

benton أستخدم التكوين التالي لـ docker-compose.yaml للقيام بالأشياء الموضحة في هذا الموضوع:

version: '2'
services:
  serviceName:
     volumes:
      - "${SSH_AUTH_SOCK}:/tmp/ssh-agent"
    environment:
      SSH_AUTH_SOCK: /tmp/ssh-agent

تأكد من أن وكيل ssh بدأ على الجهاز المضيف ويعرف عن المفتاح (يمكنك التحقق منه باستخدام الأمر ssh-add -L).

يرجى ملاحظة أنك قد تحتاج إلى إضافة

Host *
  StrictHostKeyChecking no

للحاوية .ssh / config.

مرحبًاWoZ! شكرًا لإجابتك ، تبدو بسيطة بما يكفي لذا سأجربها :)

لدي سؤال ، كيف يمكنك استخدام هذا مع الإنشاءات الآلية في Docker hub؟ بقدر ما أنا الآن لا توجد طريقة لاستخدام ملف إنشاء هناك :(

يعمل garcianavalon بشكل جيد ، ولكنه فقط مقابل run ، وليس build . لم أعمل بعد مع Docker for Mac أيضًا ، على الرغم من أنه مدرج في قائمة المهام على ما يبدو.

تحرير: https://github.com/docker/for-mac/issues/410

توصلنا إلى حلين آخرين لتلبية احتياجاتنا المحددة:

1) قم بإعداد مرآة الحزمة الخاصة بنا لـ npm و pypi وما إلى ذلك خلف VPN الخاص بنا ، وبهذه الطريقة لا نحتاج إلى SSH.

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

نحن نستخدم حاليا الخيار 2).

بقدر docker run ، يبدو أن docker-ssh-agent-forward يقدم حلاً أنيقًا ويعمل عبر Docker لنظام التشغيل Mac / Linux.

قد تكون فكرة جيدة أن تقوم بنسخ ملف known_hosts من المضيف بدلاً من إنشائه في الحاوية (أقل أمانًا) ، نظرًا لأن وكيل ssh لا يبدو أنه يقوم بإعادة توجيه المضيفات المعروفة.

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

تتمثل إحدى الطرق للتغلب على هذا القيد في md5 / تاريخ إعلانات تبعية البناء (على سبيل المثال package.json ) ، ودفع النتيجة إلى صورة وإعادة استخدام نفس الصورة إذا لم يتغير الملف. سيسمح استخدام التجزئة في اسم الصورة بالتخزين المؤقت لحالات متعددة. يجب أن يتم دمجه مع ملخص الصورة المثبت مسبقًا أيضًا.

يجب أن يكون هذا أكثر قوة من حل aidanhs لبناء الخوادم ، على الرغم من أنه لا يزال يتعين علي اختباره على نطاق واسع.

يجب أن يكون هذا أكثر قوة من حل aidanhs لبناء الخوادم ، على الرغم من أنه لا يزال يتعين علي اختباره على نطاق واسع.

لم يعمل الحل الخاص بي منذ 1.9.0 - اتضح أن الميزة المقدمة في الإصدار 1.8.0 والتي كنت أعتمد عليها لم تكن مقصودة ولذلك تمت إزالتها.

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

شكرًا لك على المعلومات الإضافيةaidanhs!

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

لقد قمت بتنفيذ الحل الكامل للعقدة / npm ويمكن العثور عليها هنا مع وثائق وأمثلة مفصلة: https://github.com/iheartradio/docker-node

بالطبع ، يمكن توسيع المبادئ لتشمل أطر أخرى.

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

https://github.com/bibendi/dip#dip -ssh

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

@ binarytemple-bet365 انظر https://github.com/iheartradio/docker-node للحصول على مثال شامل يفعل ذلك بالضبط. أستخدم أكثر من خطوتين حيث أستخدم حاوية خدمة ssh ، والتثبيت المسبق (الصورة الأساسية حتى قبل تثبيت التبعيات الخاصة) ، والتثبيت (حالة الحاوية بعد تثبيت وقت التشغيل للتبعيات الخاصة) والتثبيت اللاحق (يضيف الأوامر التي كانت لديك بعد التثبيت من التبعيات الخاصة) لتحسين السرعة وفصل الاهتمام.

تحقق من Rocker ، إنه حل نظيف.

Sodki أخذت نصيحتك. نعم ، الكرسي الهزاز هو حل نظيف ومدروس جيدًا. المزيد من العار أن فريق عامل الميناء لن يأخذ هذا المشروع تحت جناحهم ويهمل docker build . شكرا لك.

لا تزال هناك طريقة أفضل؟ :(

هل جرب أحد هذا الشيء الجديد الاسكواش؟ https://github.com/docker/docker/pull/22641 قد يكون الحل الأصلي لعمال السفن الذي نبحث عنه. سنقوم بتجربته الآن وتقديم تقرير مرة أخرى لمعرفة كيف ستسير الأمور.

بعد أكثر من عامين ، لم يتم إصلاح هذا بعد 😞 يرجى من فريق Docker القيام بشيء حيال ذلك

يبدو أن الخيار --squash في 1.13 يناسبني:
http://g.recordit.co/oSuMulfelK.gif

أقوم بإنشائه بـ: docker build -t report-server --squash --build-arg SSH_KEY="$(cat ~/.ssh/github_private_key)" .

لذلك عندما أقوم بعمل docker history أو docker inspect ، لا يظهر المفتاح.

يبدو ملف Dockerfile الخاص بي كما يلي:

FROM node:6.9.2-alpine

ARG SSH_KEY

RUN apk add --update git openssh-client && rm -rf /tmp/* /var/cache/apk/* &&\
  mkdir -p /root/.ssh && chmod 0700 /root/.ssh && \
  ssh-keyscan github.com > /root/.ssh/known_hosts

RUN echo "$SSH_KEY" > /root/.ssh/id_rsa &&\
  chmod 0600 /root/.ssh/id_rsa

COPY package.json .

RUN npm install
RUN rm -f /root/.ssh/id_rsa

# Bundle app source
COPY . .

EXPOSE 3000

CMD ["npm","start"]

@ kienpham2000 ، تبدو لقطة الشاشة الخاصة بك كما لو أنها لا تزال تحتوي على المفاتيح - هل يمكنك من فضلك التحقق من إخراج docker history مع العلم --no-trunc والإبلاغ هنا مرة أخرى سواء كانت المفاتيح الخاصة أم لا معروضة في عامل الإرساء التاريخ؟

ryanschwartz أنت على حق ، --no-trunc يظهر الأمر برمته ، هذا لا يطير.

MustafaHosny اللهم امين
شيء آخر قدموه في الإصدار 1.13 وهو:

بناء الأسرار
• تمكن من بناء أسرار الوقت باستخدام علم سر البناء
• يخلق tmpfs أثناء البناء ، ويكشف أسرار
بناء الحاويات ، لاستخدامها أثناء البناء.
• https://github.com/docker/docker/pull/28079

ربما هذا يمكن أن يعمل؟

لم يصل إنشاء الأسرار إلى 1.13 ، ولكن نأمل أن يتم ذلك في 1.14.

في 15 كانون الأول (ديسمبر) 2016 ، الساعة 9:45 صباحًا ، كتب "Alex" [email protected] :

@ kienpham2000 https://github.com/kienpham2000
شيء آخر قدموه في الإصدار 1.13 وهو:

بناء الأسرار
• تمكن من بناء أسرار الوقت باستخدام علم سر البناء
• يخلق tmpfs أثناء البناء ، ويكشف أسرار
بناء الحاويات ، لاستخدامها أثناء البناء.
• # 28079 https://github.com/docker/docker/pull/28079

ربما هذا يمكن أن يعمل؟

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/docker/docker/issues/6396#issuecomment-267393020 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AAdcPDxrctBP2TlCtXen-Y_uY8Y8B09Sks5rIXy2gaJpZM4CD4SM
.

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

الحل هو تنفيذ إعادة توجيه SSH. مثل Vagrant يفعل ذلك على سبيل المثال.

هل يمكن لأي شخص أن يشرح لي سبب تعقيد تنفيذ ذلك؟

omarabid - هل ترد على

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

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

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

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

أنا أستخدم aws cli لتنزيل المفتاح الخاص المشترك من S3 إلى الريبو الحالي للمضيف. يتم تشفير هذا المفتاح في وضع الراحة باستخدام KMS. بمجرد تنزيل المفتاح ، سيقوم Dockerfile بنسخ هذا المفتاح فقط أثناء عملية الإنشاء وإزالته بعد ذلك ، ولا يظهر المحتوى عند docker inspect أو docker history --no-trunc

قم بتنزيل مفتاح جيثب الخاص من S3 أولاً إلى الجهاز المضيف:

# build.sh
s3_key="s3://my-company/shared-github-private-key"
aws configure set s3.signature_version s3v4
aws s3 cp $s3_key id_rsa --region us-west-2 && chmod 0600 id_rsa

docker build -t app_name .

يبدو Dockerfile كما يلي:

FROM node:6.9.2-alpine

ENV id_rsa /root/.ssh/id_rsa
ENV app_dir /usr/src/app

RUN mkdir -p $app_dir
RUN apk add --update git openssh-client && rm -rf /tmp/* /var/cache/apk/* && mkdir -p /root/.ssh && ssh-keyscan github.com > /root/.ssh/known_hosts

WORKDIR $app_dir

COPY package.json .
COPY id_rsa $id_rsa
RUN npm install && npm install -g gulp && rm -rf $id_rsa

COPY . $app_dir
RUN rm -rf $app_dir/id_rsa

CMD ["start"]

ENTRYPOINT ["npm"]

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

• نقوم بإنشاء عنوان URL للتسجيل المسبق للوصول إلى المفتاح باستخدام aws s3 cli ، ونحد من الوصول لمدة 5 دقائق تقريبًا ، ونحفظ عنوان URL للتسجيل المسبق في ملف في دليل repo ، ثم في ملف dockerfile نضيفه إلى الصورة.
• في ملف dockerfile ، لدينا أمر RUN يقوم بكل هذه الخطوات: استخدم عنوان URL للغناء المسبق للحصول على مفتاح ssh وتشغيل تثبيت npm وإزالة مفتاح ssh.
  من خلال القيام بذلك في أمر واحد ، لن يتم تخزين مفتاح ssh في أي طبقة ، ولكن سيتم تخزين عنوان URL للتسجيل المسبق ، وهذه ليست مشكلة لأن عنوان URL لن يكون صالحًا بعد 5 دقائق.

يبدو نص البناء كما يلي:

# build.sh
aws s3 presign s3://my_bucket/my_key --expires-in 300 > ./pre_sign_url
docker build -t my-service .

يبدو Dockerfile كما يلي:

FROM node

COPY . .

RUN eval "$(ssh-agent -s)" && \
    wget -i ./pre_sign_url -q -O - > ./my_key && \
    chmod 700 ./my_key && \
    ssh-add ./my_key && \
    ssh -o StrictHostKeyChecking=no [email protected] || true && \
    npm install --production && \
    rm ./my_key && \
    rm -rf ~/.ssh/*

ENTRYPOINT ["npm", "run"]

CMD ["start"]

diegocsandrim شكرًا لك على الإشارة إلى ذلك ، أنا معجب حقًا

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

يبدو الأمر مزعجًا ، ولكنه ممكن بشكل أساسي

• إنشاء سلطة تصديق محلية
• لديك عملية لإنشاء شهادة
• لديك عملية لإصدار الشهادة
• لديك عملية لإلغاء الشهادة المذكورة
• لديك شياطين ssh تستخدم PKI

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

https://security.stackexchange.com/questions/30396/how-to-set-up-openssh-to-use-x509-pki-for-authentication

https://jamielinux.com/docs/openssl-certificate-authority/create-the-root-pair.html

mehmetcodes : امتلاك PKI لا يحل المشكلة حقًا. لكي تعمل مصادقة SSH المستندة إلى PKI ، ستظل بحاجة إلى تحميل المفتاح الخاص للصورة.

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

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

أوه ، إنه مزعج أكثر من ذلك ، لكن لا بد لي من أن أسعى إلى شيء ما أو لماذا قد يكون موجودًا في البرية؟

https://blog.cloudflare.com/red-october-cloudflares-open-source-implementation-of-the-two-man-rule/
https://blog.cloudflare.com/how-to-build-your-own-public-key-infrastructure/

لا أعرف ، ربما يكون مفتاح SSH المؤقت أفضل بكثير لمعظم حالات الاستخدام ، ولكن هناك شيء مقلق حول كل ملاذ ، بما في ذلك الذي اقترحته ، لا سيما في هذا السياق.

ما رأيك في http://blog.cloud66.com/using-ssh-private-keys-securely-in-docker-build/؟

عادةً ما تقوم فقط بتركيب وحدة تخزين بالمفتاح ، بدلاً من ذلك ، لكن هذا لا يساعد في الحاجة إلى عامل الإرساء لحل Mac / moby.

من و .. موبي؟

@لون أبيض

لقد وصلت إلى هذا الحد في نظام MacOS:

bash-3.2$ docker run -t -i -v "$SSH_AUTH_SOCK:/tmp/ssh_auth_sock" -e "SSH_AUTH_SOCK=/tmp/ssh_auth_sock" python:3.6 ssh-add -l
docker: Error response from daemon: Mounts denied:
The path /var/folders/yb/880w03m501z89p0bx7nsxt580000gn/T//ssh-DcwJrLqQ0Vu1/agent.10466
is not shared from OS X and is not known to Docker.
You can configure shared paths from Docker -> Preferences... -> File Sharing.
See https://docs.docker.com/docker-for-mac/osxfs/#namespaces for more info.
.

/ var / هو اسم مستعار يبدو أن Docker يعاني منه. ولكن إذا قمت ببدء مسار $ SSH_AUTH_SOCK بـ /private (أي مسار الاسم المستعار الذي تم حله) ، فيمكن لـ Docker قراءة الملف ، لكنني أحصل على:

bash-3.2$ docker run -t -i -v "/private$SSH_AUTH_SOCK:/tmp/ssh_auth_sock" -e "SSH_AUTH_SOCK=/tmp/ssh_auth_sock" python:3.6 ssh-add -l
Could not open a connection to your authentication agent.

في هذه المرحلة ، أتساءل عن مدى سوء ...

docker run -v ~/.ssh:/root/.ssh python:3.6 bash

؟

docker build  --build-arg ssh_prv_key="$(cat ~/.ssh/id_rsa_no_pass)" --build-arg ssh_pub_key="$(cat ~/.ssh/id_rsa.pub)" --squash .

ثم داخل ملف Docker:

ARG ssh_prv_key
ARG ssh_pub_key

# Authorize SSH Host
RUN mkdir -p /root/.ssh && \
    chmod 0700 /root/.ssh && \
    ssh-keyscan github.com > /root/.ssh/known_hosts

# Add the keys and set permissions
RUN echo "$ssh_prv_key" > /root/.ssh/id_rsa && \
    echo "$ssh_pub_key" > /root/.ssh/id_rsa.pub && \
    chmod 600 /root/.ssh/id_rsa && \
    chmod 600 /root/.ssh/id_rsa.pub

ولا تنسى تضمينها

RUN rm -f /root/.ssh/id_rsa /root/.ssh/id_rsa.pub

كخطوة أخيرة.

المهم هنا هو أن مفتاحك الخاص لا ينبغي أن يكون محميًا بكلمة مرور.

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

ألا يحل docker secret هذه المشكلة؟
WDYTthaJeztah

سر عامل الإرساء غير متاح (حتى الآن) أثناء الإنشاء ، ومتاح فقط في الخدمات (لذلك ليس بعد مقابل docker run )

عند استخدام إنشاءات متعددة المراحل ، يمكن أن يعمل شيء مثل هذا على الرغم من (الكتابة على هاتفي ، لذا دعني أقوم بربط جوهر أنشأته منذ فترة) ؛ https://gist.github.com/thaJeztah/836c4220ec024cf6dd48ffa850f07770

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

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

لقد كان ما يقرب من 3 سنوات 😢

تم تجميد yordis docker builder لمدة عام أو عامين. ذكر فريق Docker أن المنشئ جيد بما يكفي وأنهم يركزون جهودهم في مكان آخر. لكن هذا ذهب وكان هناك تغييران في عامل البناء منذ ذلك الحين. بناء مرحلة الاسكواش والموستلي. لذلك قد تكون أسرار وقت البناء في طريقهم.

لإعادة توجيه وقت تشغيل وكيل ssh ، أوصي بـ https://github.com/uber-common/docker-ssh-agent-forward

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

yordis يقرأ أعلى وصف لهذه المشكلة ، وتنفيذ هذا بعيد كل البعد عن التافه ؛ بعد قولي هذا ، إذا كان لدى شخص ما اقتراح تصميم تقني لهذا ، فلا تتردد في فتح قضية أو العلاقات العامة للمناقشة. لاحظ أيضًا أنه بالنسبة للجزء _build_ ، تم بدء مشروع buildkit من أجل التحسينات المستقبلية للمُنشئ ؛ https://github.com/moby/buildkit

thaJeztah أتمنى أن أمتلك المهارات المطلوبة لكنني لا

villlem هل تعرف أي خارطة طريق من فريق Docker؟

يمكن الاطلاع على التقارير الأسبوعية للمنشئ هنا ؛ https://github.com/moby/moby/tree/master/reports/builder لا تزال أسرار وقت البناء مدرجة في أحدث تقرير ، ولكن يمكن استخدام المساعدة

نحن نستخدم حل diegocsandrim ولكن بخطوة تشفير وسيطة لتجنب ترك مفتاح SSH غير مشفر في S3.

تعني هذه الخطوة الإضافية أنه لا يمكن استرداد المفتاح من صورة Docker (تنتهي صلاحية عنوان URL لتنزيله بعد خمس دقائق) ولا يمكن استرداده من AWS (لأنه مشفر بكلمة مرور دوارة معروفة فقط لصورة عامل الإرساء) .

في build.sh:

BUCKET_NAME=my_bucket
KEY_FILE=my_unencrypted_key
openssl rand -base64 -out passfile 64
openssl enc -aes-256-cbc -salt -in $KEY_FILE -kfile passfile | aws s3 cp - s3://$BUCKET_NAME/$(hostname).enc_key
aws s3 presign s3://$BUCKET_NAME/$(hostname).enc_key --expires-in 300 > ./pre_sign_url
docker build -t my_service

وفي Dockerfile:

COPY . .

RUN eval "$(ssh-agent -s)" && \
    wget -i ./pre_sign_url -q -O - | openssl enc -aes-256-cbc -d -kfile passfile > ./my_key && \
    chmod 700 ./my_key && \
    ssh-add ./my_key && \
    mkdir /root/.ssh && \
    chmod 0700 /root/.ssh && \
    ssh-keyscan github.com > /root/.ssh/known_hosts && \
    [commands that require SSH access to Github] && \
    rm ./my_key && \
    rm ./passfile && \
    rm -rf /root/.ssh/

إذا كنت تستخدم docker run فيجب عليك تحميل .ssh مع --mount type=bind,source="${HOME}/.ssh/",target="/root/.ssh/",readonly . القراءة فقط هي السحر ، فهي تخفي الأذونات العادية وترى ssh بشكل أساسي أذونات 0600 التي ترضيها. يمكنك أيضًا اللعب بـ -u root:$(id -u $USER) لجعل المستخدم الجذر في الحاوية يكتب أي ملفات يقوم بإنشائها مع نفس المجموعة مثل المستخدم الخاص بك ، لذلك نأمل أن تتمكن على الأقل من قراءتها إذا لم تقم بكتابتها بالكامل دون الحاجة إلى chmod / chown .

أخيرا.

أعتقد أنه يمكن الآن حل هذه المشكلة باستخدام docker build ، باستخدام عمليات إنشاء متعددة المراحل .
فقط COPY أو ADD مفتاح SSH أو أي سر آخر أينما تحتاج إليه ، واستخدمه في كشوف الحسابات RUN كيفما تشاء.

بعد ذلك ، استخدم عبارة FROM ثانية لبدء نظام ملفات جديد ، و COPY --from=builder لاستيراد مجموعة فرعية من الأدلة التي لا تتضمن السر .

(لم أجرب هذا بالفعل حتى الآن ، ولكن إذا كانت الميزة تعمل كما هو موضح ...)

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

لقد تحققت من التقنية التالية:

1. قم بتمرير _location of a private key_ as a Build Argument ، مثل GITHUB_SSH_KEY ، إلى المرحلة الأولى من بناء متعدد المراحل
2. استخدم ADD أو COPY لكتابة المفتاح إلى المكان المطلوب للمصادقة. لاحظ أنه إذا كان موقع المفتاح هو مسار نظام ملفات محلي (وليس عنوان URL) ، فيجب ألا يكون في الملف .dockerignore ، وإلا فلن يعمل التوجيه COPY . هذا له آثار على الصورة النهائية ، كما سترى في الخطوة 4 ...
3. استخدم المفتاح حسب الحاجة. في المثال أدناه ، يتم استخدام المفتاح للمصادقة على GitHub. يعمل هذا أيضًا مع مستودعات Ruby bundler ومستودعات الأحجار الكريمة الخاصة. اعتمادًا على مقدار قاعدة التعليمات البرمجية التي تحتاج إلى تضمينها في هذه المرحلة ، قد ينتهي بك الأمر بإضافة المفتاح مرة أخرى كأثر جانبي لاستخدام COPY . أو ADD . .
4. قم بإزالة المفتاح إذا لزم الأمر . إذا كان موقع المفتاح هو مسار نظام ملفات محلي (وليس عنوان URL) ، فمن المحتمل أنه قد تمت إضافته إلى جانب قاعدة الشفرة عندما فعلت ADD . أو COPY . هذا هو على الأرجح _ الدليل_ هذا سيتم نسخها في صورة وقت التشغيل النهائية ، لذلك ربما تريد أيضًا تضمين عبارة RUN rm -vf ${GITHUB_SSH_KEY} بمجرد الانتهاء من استخدام المفتاح.
5. بمجرد أن يتم دمج تطبيقك بالكامل في WORKDIR ، ابدأ مرحلة الإنشاء الثانية ببيان FROM ، يشير إلى صورة وقت التشغيل التي تريدها. قم بتثبيت أي تبعيات ضرورية لوقت التشغيل ، ثم قم بتثبيت COPY --from=builder مقابل WORKDIR من المرحلة الأولى.

هذا مثال Dockerfile يوضح الأسلوب أعلاه. سيؤدي تقديم GITHUB_SSH_KEY Build Argument إلى اختبار مصادقة GitHub عند الإنشاء ، ولكن لن يتم تضمين البيانات الأساسية في صورة وقت التشغيل النهائية. يمكن أن يكون GITHUB_SSH_KEY مسارًا لنظام ملفات (داخل Docker build dir) أو عنوان URL يخدم البيانات الأساسية ، ولكن لا يجب تشفير المفتاح نفسه في هذا المثال.

########################################################################
# BUILD STAGE 1 - Start with the same image that will be used at runtime
FROM ubuntu:latest as builder

# ssh is used to test GitHub access
RUN apt-get update && apt-get -y install ssh

# The GITHUB_SSH_KEY Build Argument must be a path or URL
# If it's a path, it MUST be in the docker build dir, and NOT in .dockerignore!
ARG GITHUB_SSH_KEY=/path/to/.ssh/key

  # Set up root user SSH access for GitHub
ADD ${GITHUB_SSH_KEY} /root/.ssh/id_rsa

# Add the full application codebase dir, minus the .dockerignore contents...
# WARNING! - if the GITHUB_SSH_KEY is a file and not a URL, it will be added!
COPY . /app
WORKDIR /app

# Build app dependencies that require SSH access here (bundle install, etc.)
# Test SSH access (this returns false even when successful, but prints results)
RUN ssh -o StrictHostKeyChecking=no -vT [email protected] 2>&1 | grep -i auth

# Finally, remove the $GITHUB_SSH_KEY if it was a file, so it's not in /app!
# It can also be removed from /root/.ssh/id_rsa, but you're probably not going
# to COPY that directory into the runtime image.
RUN rm -vf ${GITHUB_SSH_KEY} /root/.ssh/id*

########################################################################
# BUILD STAGE 2 - copy the compiled app dir into a fresh runtime image
FROM ubuntu:latest as runtime
COPY --from=builder /app /app

قد يكون من الأكثر أمانًا تمرير البيانات الأساسية نفسها في وسيطة الإنشاء GITHUB_SSH_KEY بدلاً من _تخصيص _ البيانات الأساسية. سيؤدي هذا إلى منع التضمين العرضي للبيانات الرئيسية إذا تم تخزينها في ملف محلي ثم إضافتها بـ COPY . . ومع ذلك ، قد يتطلب ذلك استخدام echo وإعادة توجيه shell لكتابة البيانات إلى نظام الملفات ، والذي قد لا يعمل في جميع الصور الأساسية. استخدم الأسلوب الأكثر أمانًا والأكثر جدوى لمجموعة الصور الأساسية الخاصة بك.

jbiel عام آخر ، والحل الذي وجدته هو استخدام شيء مثل Vault.

إليك رابط بطريقتين (الحاوية الوسيطة والاسكواش الموصوفة سابقًا بواسطةbenton)

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

حل.
إنشاء برنامج bash النصي (~ / bin / docker-compose أو ما شابه):

#!/bin/bash

trap 'kill $(jobs -p)' EXIT
socat TCP-LISTEN:56789,reuseaddr,fork UNIX-CLIENT:${SSH_AUTH_SOCK} &

/usr/bin/docker-compose $@

وفي Dockerfile باستخدام socat:

...
ENV SSH_AUTH_SOCK /tmp/auth.sock
...
  && apk add --no-cache socat openssh \
  && /bin/sh -c "socat -v UNIX-LISTEN:${SSH_AUTH_SOCK},unlink-early,mode=777,fork TCP:172.22.1.11:56789 &> /dev/null &" \
  && bundle install \
...
or any other ssh commands will works

ثم قم بتشغيل docker-compose build

benton لماذا تستخدم RUN rm -vf ${GITHUB_SSH_KEY} /root/.ssh/id* ؟ ألا يجب أن يكون RUN rm -vf /root/.ssh/id* ؟ أو ربما أسأت فهم النية هنا.

benton وأيضًا ليس من الآمن القيام به:

RUN ssh -o StrictHostKeyChecking=no -vT [email protected] 2>&1

يجب عليك التحقق من بصمة الإصبع

لقد عالجت هذه المشكلة بهذه الطريقة

ARGS USERNAME
ARGS PASSWORD
RUN git config --global url."https://${USERNAME}:${PASSWORD}@github.com".insteadOf "ssh://[email protected]"

ثم بناء مع

docker build --build-arg USERNAME=use --build-arg PASSWORD=pwd. -t service

ولكن في البداية ، يجب أن يدعم خادم git الخاص بك username:password clone repo.

zeayes تم تخزين الأمر RUN في محفوظات الحاوية. لذلك تكون كلمة مرورك مرئية للآخرين.

صيح؛ عند استخدام --build-arg / ARG ، ستظهر هذه القيم في سجل الإنشاء. من الممكن استخدام هذه التقنية إذا كنت تستخدم عمليات إنشاء متعددة المراحل _ وتثق في المضيف الذي تم إنشاء الصور عليه (على سبيل المثال ، لا يمكن لأي مستخدم غير موثوق به الوصول إلى محفوظات الإنشاء المحلية) ، و _ ولا يتم دفع مراحل الإنشاء المتوسطة إلى السجل.

على سبيل المثال ، في المثال التالي ، سيظهر USERNAME و PASSWORD فقط في محفوظات المرحلة الأولى ("builder") ، لكن لن يكون في محفوظات المرحلة النهائية ؛

FROM something AS builder
ARG USERNAME
ARG PASSWORD
RUN something that uses $USERNAME and $PASSWORD

FROM something AS finalstage
COPY --from= builder /the/build-artefacts /usr/bin/something

إذا تم دفع الصورة النهائية فقط (التي تم إنتاجها بواسطة "finalstage") إلى السجل ، فلن يكون هناك USERNAME و PASSWORD في تلك الصورة.

_ومع ذلك ، في محفوظات ذاكرة التخزين المؤقت للبناء المحلي ، ستظل هذه المتغيرات موجودة (ويتم تخزينها على القرص بنص عادي).

سيكون لمنشئ الجيل التالي (باستخدام

kinnalruthaJeztah thx ، أنا تصميمات متعددة المراحل ، ولكن يمكن رؤية كلمة المرور في محفوظات حاوية ذاكرة التخزين المؤقت ، thx!

تضمين التغريدة أرى أنني فعلت خطأ نسخ / لصق ؛ يجب ألا تستخدم المرحلة الأخيرة FROM builder .. . هنا مثال كامل. https://gist.github.com/thaJeztah/af1c1e3da76d7ad6ce2abab891506e50

هذا التعليق من kinnalru هو الطريقة الصحيحة للقيام بذلك https://github.com/moby/moby/issues/6396#issuecomment -348103398

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

لقد استغرق الأمر بعض الوقت لمعرفة ذلك ، لذلك يوجد شرح أكثر وضوحًا وتحسينًا. لقد غيرت كود kinnalru لاستخدام --network=host و localhost ، لذلك لا تحتاج إلى معرفة عنوان IP الخاص بك. ( تذكر هنا )

هذا هو docker_with_host_ssh.sh ، وهو يلتف عامل الإرساء ويعيد توجيه SSH_AUTH_SOCK إلى منفذ على المضيف المحلي:

#!/usr/bin/env bash

# ensure the processes get killed when we're done
trap 'kill $(jobs -p)' EXIT

# create a connection from port 56789 to the unix socket SSH_AUTH_SOCK (which is used by ssh-agent)
socat TCP-LISTEN:56789,reuseaddr,fork UNIX-CLIENT:${SSH_AUTH_SOCK} &
# Run docker
# Pass it all the command line args ($@)
# set the network to "host" so docker can talk to localhost
docker $@ --network='host'

في Dockerfile ، نقوم بالاتصال عبر مضيف محلي بعامل ssh للمضيف:

FROM python:3-stretch

COPY . /app
WORKDIR /app

RUN mkdir -p /tmp

# install socat and ssh to talk to the host ssh-agent
RUN  apt-get update && apt-get install git socat openssh-client \
  # create variable called SSH_AUTH_SOCK, ssh will use this automatically
  && export SSH_AUTH_SOCK=/tmp/auth.sock \
  # make SSH_AUTH_SOCK useful by connecting it to hosts ssh-agent over localhost:56789
  && /bin/sh -c "socat UNIX-LISTEN:${SSH_AUTH_SOCK},unlink-early,mode=777,fork TCP:localhost:56789 &" \
  # stuff I needed my ssh keys for
  && mkdir -p ~/.ssh \
  && ssh-keyscan gitlab.com > ~/.ssh/known_hosts \
  && pip install -r requirements.txt

ثم يمكنك بناء صورتك عن طريق استدعاء النص:

$ docker_with_host_ssh.sh build -f ../docker/Dockerfile .

cowlicks ، قد تكون مهتمًا بطلب السحب هذا ، والذي يضيف دعمًا لـ docker build --ssh لإعادة توجيه وكيل SSH أثناء الإنشاء ؛ https://github.com/docker/cli/pull/1419. لا يزال بناء جملة Dockerfile غير موجود في المواصفات الرسمية ، ولكن يمكنك استخدام التوجيه syntax=.. في Dockerfile الخاص بك لاستخدام واجهة أمامية تدعمه (انظر المثال / التعليمات في طلب السحب).

سيكون طلب السحب هذا جزءًا من إصدار 18.09 القادم.

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

ملاحظات الإصدار:
https://docs.docker.com/develop/develop-images/build_enhancements/#using -ssh-to-access-private-data-in-builds

مشاركة متوسطة:
https://medium.com/@tonistiigi/build -secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066

مشوق.

kalenp راجع أيضًا https://github.com/moby/buildkit/issues/760 و https://github.com/moby/buildkit/issues/825

أعتقد أنه يمكننا إغلاق هذا لأن لدينا docker build --ssh الآن

مشكلة الإنشاء ذات الصلة هنا: docker / compose # 6865. وظيفة لاستخدام Compose وفضح مقبس وكيل SSH للحاويات التي لوحظ أنها تهبط في مرشح الإصدار التالي ، 1.25.0-rc3 ( الإصدارات ).