بينغewindischdiogomonicaNathanMcCauley هذا هو مجرد وسيلة سريعة متابعة الكتابة. لا تتردد في تعديل / تحديث الوصف إذا كنت تعتقد أن هذا ضروري :)

هذه معلومات مفيدة:

https://github.com/hashicorp/vault/issues/165

كما هذا:

https://github.com/hashicorp/vault/issues/164

@ dreamcat4 هناك بعض الخطط لتنفيذ "واجهة برمجة تطبيقات الأسرار" العامة ، والتي من شأنها أن تسمح لك باستخدام Vault أو Keywiz أو تسميتها مع Docker ، ولكن جميعها بنفس الطريقة. إنها مجرد فكرة مبكرة ، لذا فهي تتطلب بحثًا إضافيًا.

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

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

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

@ dreamcat4 نعم ، أنت على حق ؛ على المدى القصير ، هذه الروابط مفيدة حقًا.

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

شكرا! أعتقد أنه كان لدي ذلك في وصفي الأصلي ، يجب أن يكون قد ضاع في هذه العملية. سأضيف رصاصة

ومع ذلك فأنا لست خبيرا أمنيا.

ولست أنا كذلك ، ولهذا السبب "أزعج" مسؤولي الأمن ؛ IMO ، يجب أن يكون هذا شيئًا مكتوبًا من قبلهم 😇

thaJeztah ملخص رائع. سأحاول الوخز في هذا كلما وجدت بعض الوقت.

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

بافتراض أنه يمكنك تحميل وحدات التخزين كمستخدم بخلاف الجذر (أعلم أنه مستحيل ، ولكن دعني) ، فهل سيكون هذا أسلوبًا مناسبًا لإدخال الأسرار في الحاويات؟

إذا كان الأمر كذلك ، فأنا أدافع عن بديل لـ -v host_dir:image_dir والذي يتوقع استخدام حاوية البيانات فقط وقد يبدو مثل -vc host_dir:image_dir (أي نسخة المجلد) حيث تكون محتويات host_dir نسخها إلى مجلد image_dir في حاوية البيانات فقط.

يمكننا بعد ذلك التأكيد على نموذج secure-data-only containers والسماح بتشفير هذه الأحجام

لقد قرأت مؤخرًا مقالًا جيدًا عن ذلك من jrslv حيث اقترح إنشاء صورة عامل وبدلاً من إنشاء صورة أخرى للتوزيع باستخدام النتائج من تشغيل صورة

إذن لديك ملفان Dockerfiles:

• Dockerfile.build (هنا يمكنك ببساطة نسخ جميع أسرارك)
• Dockerfile.dist (هذا الذي ستدفعه للتسجيل)

الآن يمكننا بناء توزيعنا على هذا النحو:

# !/bin/sh
docker build -t hello-world-build -f Dockerfile.build .
docker run hello-world-build >build.tar.gz 
docker build -t hello-world -f Dockerfile.dist ^

أسرارك في أمان ، لأنك لا تدفع صورة hello-world-build أبدًا.

أوصي بقراءة مقال jrslv لمزيد من التفاصيل http://resources.codeship.com/ebooks/continuous-integration-continuous-delivery-with-docker

شكرا لتقاسم kepkin !
انتهيت للتو من قراءة المقال. موجزة حقا!

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

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

@ kepkin بلا إهانة لكن هذا لا معنى له. الأسرار ليست آمنة بالتأكيد ، نظرًا لأنها موجودة في كرة القطران ويتم تحرير كرة القطران ADD ed لصورة الإنتاج - حتى إذا قمت بإزالة كرة القطران ، دون سحقها ، فسوف تتسرب في بعض الطبقات.

TomasTomecek إذا فهمت المثال بشكل صحيح ، فإن كرة القطر هي _not_ طبقات الصورة ، ولكنها فقط الثنائية التي تم إنشاؤها داخل حاوية الإنشاء. انظر على سبيل المثال ؛ https://github.com/docker-library/hello-world/blob/master/update.sh (لا توجد أسرار متضمنة هنا ، ولكن مجرد مثال بسيط على حاوية بناء)

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

kepkin الحق ، الآن قرأت

TomasTomecek هذا هو بالضبط كيف أحضر القطع الأثرية في الواقع.

في صورة Docker.build ، قمت بتنزيل بعض التبعيات الثنائية من صورة Amazon S3 التي تتطلب مفتاح وسر AWS. بعد الاسترجاع والبناء ، أقوم بإنشاء كرة تار مع كل ما أحتاجه.

هل هناك مقال أساسي حول "أفضل الممارسات" - "ما يجب القيام به" كما ورد في "ما يجب" - ينصحكم جميعًا بقراءته؟

تجدر الإشارة (لأي شخص آخر مثلي يتعثر في هذا الأمر) أن Docker Compose يدعم خيار env_file .

https://docs.docker.com/compose/compose-file/#env -file

afeld docker نفسها لديها هذه الميزة أيضًا ، راجع http://docs.docker.com/engine/reference/commandline/run/#set -environment-variables-e-env-env-file لكن تلك env-vars ستظل تظهر في نفس الأماكن ، لذلك لا تحدث فرقًا في حالة حدوث "تسريب"

لقد عثرت على ورقة الغش هذه: http://container-solutions.com/content/uploads/2015/06/15.06.15_DockerCheatSheet_A2.pdf

kepkin هذه هي الطريقة التي أمرر بها مفتاح ssh إلى docker build :

# serve the ssh private key once over http on a private port.
which ncat
if [ "$?" = "0" ]; then
  ncat -lp 8000 < $HOME/.ssh/id_rsa &
else
  nc -lp 8000 < $HOME/.ssh/id_rsa &
fi
nc_pid=$!
docker build --no-cache -t bob/app .
kill $nc_pid || true

وداخل Dockerfile حيث 172.17.0.1 هو عنوان IP لبوابة عامل الإرساء:

RUN \
  mkdir -p /root/.ssh && \
  curl -s http://172.17.0.1:8000 > /root/.ssh/id_rsa && \
  chmod 600 /root/.ssh/id_rsa && chmod 700 /root/.ssh && \
  ssh-keyscan -t rsa,dsa github.com > ~/.ssh/known_hosts && \
  git clone --depth 1 --single-branch --branch prod [email protected]/app.git . && \
  npm i --production && \
  ... && \
  rm -rf /root/.npm /root/.node-gyp /root/.ssh

إذا كان لدى شخص ما شيء أبسط ، أخبرنا بذلك.

إذن ما هو الوضع الحالي لهذا؟

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

thaJeztah ما الذي يمكن فعله لدفع هذا إلى الأمام؟ أعتقد أن العديد من الأعين خلال مشاريع المصب المختلفة تدور حول هذه المسألة ... ej. https://github.com/rancher/rancher/issues/1269

أعتقد أن ما يتم عمله هنا محفوظ _secret_: D

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

بعض المحتويات ذات الصلة بهذا الموضوع من k8s .

ما رأيك في هذا كوسيلة محتملة لمعالجة أسرار وقت التشغيل؟
https://github.com/docker/docker/issues/19508

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

عدد قليل من الأشياء التي رأيتها تشير إلى أنها مخاوف مشروعة إلى حد ما تشمل:

أوراق اعتماد وقت التشغيل

• معلومات المستخدم / كلمة المرور منسقة بين حاويتين تشتركان في link
• من السهل الاحتفاظ بالمعلومات خارج مستودع git الخاص بك
• من السهل الاحتفاظ بالمعلومات بعيدًا عن صورك المدفوعة (ماذا عن الحاويات المحلية؟)
• من السهل الاحتفاظ بالمعلومات خارج .bash_history (ربما يكون الجسر بعيدًا جدًا؟)
• تتوقع بعض التطبيقات وجود أسرار كجزء من ملف التكوين الذي يحتوي على معلومات أخرى
• تتوقع بعض التطبيقات الأسرار كمتغير بيئة
• تسمح بعض التطبيقات لكليهما

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

أوراق اعتماد وقت البناء

• تم إنشاء المشروع من مستودعات خاصة واحدة أو أكثر (على سبيل المثال: يسمح package.json لعناوين url الخاصة بـ git)
• قد يكون Builder وراء وكيل محمي بكلمة مرور
• قد يستخدم Builder ذاكرة تخزين مؤقت محمية بكلمة مرور
• يهتم المستخدم النهائي فقط بصورة العمل (على سبيل المثال ، سيستخدمون pull أو FROM ، وليس أبدًا docker build )
• من السهل الاحتفاظ بالمعلومات بعيدًا عن صورك المدفوعة

التحرير الأول:

توثيق ما هو "تسرب" وما لا يتم "تسريبه" في صورة نموذجية أو حاوية

• ما هي الملفات التي تنتهي في الصورة (فقط النسخ والإضافة؟ أي شيء آخر؟)
• ما الذي يحتفظ به عامل الإرساء بعد إنشاء الصورة (خاصة boot2docker ، ولكن ماذا عن الآخرين؟)
• كيف يتم التقاط متغيرات البيئة وسطر الأوامر في الصورة ، وأين يتم التقاطها
• التوقعات بشأن مُصدري العلاقات العامة فيما يتعلق بتغيير هذه السلوكيات

أشعر وكأنني أفتقد اثنين من كبار الشخصيات هنا. أي شخص حصل على شيء نسيت؟

مفاتيح API لأي خدمات json.

على سبيل المثال (وهذه هي حالة الاستخدام الحقيقية الخاصة بي) ، يقوم Docker build بتجميع برنامج ، ومفتاح API ضروري لمصادقيتي وتحميل منتج (منتجات) الإنشاء إلى Bintray.com.

@ dreamcat4 قد أكون بعيدًا عما تقوله ، لكن هنا يذهب:

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

في العالم الذي أعيش فيه ، يقوم وكيل الإنشاء فقط ببناء الثنائيات / الأرشيفات والاحتفاظ بها كـ "عناصر أثرية" لعملية الإنشاء ، ويدفع شيء آخر هؤلاء إلى البنية التحتية ، ويضع علامات على مستودع git ، وما إلى ذلك ، وهذا يعطيني نسخة احتياطية طارئة من العناصر الأثرية إذا كنت لدي مشكلة في الإنتاج ، على سبيل المثال ، مستودعي npm أو docker أو Artifactory معطّل لإجراء ترقيات ، أو أن الشبكة تعطلني.

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

dreamcat أوه ، إذن المصادقة على الرموز المميزة لنقاط نهاية REST؟ هل تعتقد أنه يتم التعامل مع هذه العناصر بشكل مختلف تمامًا عن ، على سبيل المثال ، كلمة مرور postgres الخاصة بك في ملف conf ، أم أنك ستتعامل معها بالمثل؟

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

غالبًا ما تكون الرموز المميزة لمصادقة واجهة برمجة التطبيقات:

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

غالبًا ما تكون كلمات المرور:

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

لذلك لا يعني ذلك بالضرورة أن حل الأسرار _يجب أن يكون مختلفًا_ لهذين النوعين. مجرد أن الحد الأدنى المقبول لمستوى الأمان قد يكون أقل قليلاً لمفاتيح API.

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

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

على سبيل المثال - مفتاح واجهة برمجة تطبيقات bintray الخاص بي: يتم الاحتفاظ به في نفس ملف .git مثل ملف Dockerfile الخاص بي. لذلك للحفاظ على أمانها ، يتم الاحتفاظ بها في PRIVATE git repo (يمكن الوصول إليها عبر SSH). لذا فإن الوصول إلى مفتاح API محمي بشكل جيد نسبيًا هناك. ومع ذلك ، فبدون وجود أي وظائف / حماية لأسرار مدمجة خاصة به ، فإن صورة عامل الإرساء المدمجة تتضمن دائمًا مفتاح واجهة برمجة التطبيقات في نص عادي. لذلك ، يجب أن تظل صورة إنشاء Docker الناتجة خاصة مثل مستودع git ... الذي له تأثير غير مرغوب فيه لا يمكن لأي شخص آخر عرض / رؤية حالة سجلات البناء / البناء هناك بشكل عام.

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

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

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

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

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

حسنًا ، أعتقد أن القليل من التوثيق سيظل مفيدًا هنا ، حيث يقدم Docker بعض مكامن الخلل الإضافية في مساحة المشكلة.

يبدو أن رجال Vault ربما ينظرون إلى هذا أيضًا من نهايتهم. أعتقد أن هذه التذكرة هي التي يجب مشاهدتها:

https://github.com/hashicorp/vault/issues/165

ربما هذا شيء يمكن التعاون فيه.

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

ربما هذا شيء يمكن التعاون فيه.

+1

+1 Docker + Hashi Corp Vault

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

إنني أبحث عن حل يغطي التطوير (على سبيل المثال: مفاتيح جيثب) والنشر (على سبيل المثال: مفاتيح شهادات nginx وبيانات اعتماد ديسيبل). لا أرغب في تلويث المضيف باستخدام أدوات env أو إنشاء أدوات وبالطبع لا يجب أن ينتهي الأمر بأسرار في github (غير مشفر) أو دليل صورة عامل ميناء ، حتى في دليل خاص.

gittycat أتفق معك بمعنى أنه من المحتمل أن يكون هناك العديد من حالات الاستخدام المتميزة. حيث يجب أن تكون بعض الحلول أبسط من الحلول الأخرى.

يجب علينا بالتأكيد تجنب اللجوء إلى ENV vars بالرغم من ذلك.

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

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

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

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

لا أعرف ما إذا كان هذا أي استخدام أم أنه سيعمل ، ولكن إليك القليل من اقتراح الحقل الأيسر لحل الحالة التي أريد فيها إدخال سر في حاوية في وقت التشغيل (على سبيل المثال ، كلمة مرور postgres)

إذا كان بإمكاني تجاوز نقطة الإدخال عند docker run time وتعيينها على برنامج نصي من اختياري على سبيل المثال / sbin / get_secrets ، والتي بعد الحصول على أسرار من آلية من اختياري (مثل KMS) ، فإنها ستنفذ نقطة الإدخال الأصلية (وبالتالي أصبح مجرد غلاف هدفه الوحيد هو إعداد متغيرات البيئة مع وجود أسرار بداخلها داخل الحاوية. يمكن توفير مثل هذا البرنامج النصي في وقت التشغيل عبر وحدة تخزين. لن تتضمن هذه الآلية أسرارًا يتم كتابتها على الإطلاق على القرص ( يكره أحد الحيوانات الأليفة الخاصة بي) ، أو أن يتم تسريبه بواسطة عامل التحميل (ليس جزءًا من فحص عامل الإرساء) ، ولكنه سيضمن وجودها فقط داخل بيئة العملية 1 داخل الحاوية ، والتي تحافظ على 12 عنصرًا.

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

أخيرًا ، أعتقد أنه من الممكن حتى توفير مفتاح مشفر لمرة واحدة عبر حقن env var التقليدي الذي يمكن أن تستخدمه الخارجية / sbin / get_secrets لطلب الأسرار الفعلية (مثل كلمة مرور postgres) ، وبالتالي إضافة حماية إضافية إلى عامل الإرساء تسريب المفتاح لمرة واحدة.

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

thaJeztah - يمكنني تأكيد الحل الذي

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

ربما يجعل مثال مجلد التعليمات البرمجية التقارب أسهل قليلاً في التوضيح / الفهم.

مثال على الكود وسيناريوهات العمل هنا @ dreamcat4kaos >

https://github.com/gtmtechltd/secret-squirrel

قد أكون مخطئا ، ولكن لماذا هذه الأساليب المعقدة؟ أنا أعتمد على أذونات ملف يونيكس القياسية. قم بتسليم جميع الأسرار إلى عامل الإرساء باستخدام -v /etc/secrets/docker1:/etc/secrets يمكن قراءته فقط عن طريق الجذر ، ثم هناك نص برمجي يعمل عند بدء تشغيل الحاوية كجذر ، والذي ينقل الأسرار إلى الأماكن المناسبة للبرامج ذات الصلة (على سبيل المثال تكوين apache). تقوم هذه البرامج بإسقاط أذونات الجذر عند بدء التشغيل ، لذا إذا تم اختراقها ، فلن تتمكن من قراءة السر المملوك للجذر لاحقًا. هل هذه الطريقة التي أستخدمها معيبة إلى حد ما؟

شكرا gtmtech :)
لسوء الحظ ، ليس لدينا نقطة دخول قياسية ، كما أنني غير قادر على تشغيل فحص عامل الإرساء قبل تشغيل عامل الإرساء بطريقة خاضعة للرقابة .. لكني أحب أسلوبك.

قد أكون مخطئا ، ولكن لماذا هذه الأساليب المعقدة؟ أنا أعتمد على أذونات ملف يونيكس القياسية. قم بتسليم جميع الأسرار إلى عامل الإرساء باستخدام -v / etc / secrets / docker1: / etc / secrets لا يمكن قراءتها إلا عن طريق الجذر ثم يوجد نص برمجي يعمل عند بدء تشغيل الحاوية كجذر ، والذي يمرر الأسرار إلى الأماكن المناسبة للبرامج ذات الصلة (على سبيل المثال apache التكوين). تقوم هذه البرامج بإسقاط أذونات الجذر عند بدء التشغيل ، لذا إذا تم اختراقها ، فلن تتمكن من قراءة السر المملوك للجذر لاحقًا. هل هذه الطريقة التي أستخدمها معيبة إلى حد ما؟

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

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

إذن هذا يترك (ربما خمنته بالفعل) ...
أسرار بناء الوقت!

لكن أعتقد أن هذا تقدم! نظرًا لعدم الوصول إلى أي مكان بعد وقت طويل ، ربما تقسم الأشياء إلى النصف وتحل حوالي 45-50٪ من إجمالي المشكلة.

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

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

Secret_squirrel هو على أي حال اختراق في مساحة لا أستطيع فيها رؤية أي حلول قابلة للتطبيق حتى الآن ، حول عامل ميناء لم يقدم بعد أسرار API ، أو برنامج أسرار قابل للتوصيل ، والذي نأمل أن يفعلوه في مرحلة ما ، ولكن ربما يعمل على توضيح ذلك إعداد ENV المتغيرات الموجودة داخل الحاوية قبل عملية exec ، ولكن ليس كجزء من عملية إنشاء عامل الإرساء (أو البيانات الوصفية) هي طريقة آمنة للامتثال لـ 12 عاملاً مع الأسرار ، وربما يمكن لمجتمع تطوير عامل الإرساء استخدام هذه الفكرة عندما يبدأون في بناء secrets-api / driver إذا كانوا يعتقدون أنها فكرة جيدة!

سعيد لرسو السفن!

لقد استخدمنا نوع النهج الذي

عادةً ما يتضمن ذلك نقطة دخول بسيطة أمام التطبيق. نقوم حاليًا بتنفيذ هذا الرقاقة بمزيج من shell وثنائي Golang صغير (https://github.com/realestate-com-au/shush) ، لكني أحب صوت نهج Pure-Go.

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

قبو +1

قبو -1. يحتوي Vault على بعض الخصائص التشغيلية (فتح الختم) التي تجعله حقًا غير مرغوب فيه لكثير من الأشخاص.

سيكون وجود واجهة برمجة تطبيقات قابلة للتوصيل أكثر منطقية.

هناك أيضا قبو أنسبل. هذا هو بالأحرى وحش مختلف.

gtmtech شكرًا على الاقتراح ، لقد ألهمني ذلك لكتابة نقطة الدخول هذه:

#!/bin/bash

if [ -d "/var/secrets" ]; then
  tmpfile="$(mktemp)"
  for file in /var/secrets/*
  do
    if [ -f $file ]; then
      file_contents=$(cat $file)
      filename=$(basename "$file")
      underscored_filename="${filename//-/_}"
      capitalized_filename=${underscored_filename^^}
      echo "export $capitalized_filename=$file_contents" >> $tmpfile
    fi
  done

  source $tmpfile
  rm -f $tmpfile
fi

exec "$@"

لقد أضفته إلى Dockerfile هكذا (لا تنسَ أن chmod + x عليه):

ENTRYPOINT ["/app/docker-entrypoint.sh"]

وفويلا. متغيرات ENV متوفرة في وقت التشغيل. جيد بما فيه الكفاية :)

إذا فهمت بشكل صحيح ، يجب أن يتم تثبيت /var/secrets dir من خلال وحدات التخزين ، أليس كذلك؟
أيضا ، عندما يكون هناك تعليق حول الأسرار التي لا تتم كتابتها على القرص ، ما مدى سوء كتابتها على القرص ثم حذفها ؟؟؟

هذا لطيف! يجب عليك استخدام shred لحذف الملف بأمان بالرغم من ذلك.

في الخميس 3 مارس، 2016، خوان اجناسيو دونوسو [email protected]
كتب:

إذا فهمت بشكل صحيح ، فيجب تثبيت / var / secrets dir من خلال
مجلدات الحق ؟؟
أيضًا ، عند وجود تعليق حول عدم كتابة الأسرار على القرص ، كيف يتم ذلك
السيئة هي كتابتها على القرص ثم حذفها ؟؟؟

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

روي مارينيو

مستوحاة من "Secret-squirrel" gtmtech ، لقد وسعت أداة الإدارة السرية الخاصة بي "shush" لجعلها قابلة للاستخدام كنقطة دخول للصورة:

ADD shush_linux_amd64 /usr/local/bin/shush
ENTRYPOINT ["/usr/local/bin/shush", "exec", "--"]

يقوم هذا بفك تشفير أي متغيرات KMS_ENCRYPTED_xxx ، ويضخ النتائج مرة أخرى في البيئة.

https://github.com/realestate-com-au/shush#use -as-a-command-shim

لذلك يبدأ الخيط بـ "لا تفعل أيًا من هذه الأشياء ...

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

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

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

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

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

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

عندما أفكر في النواقص القصيرة من env vars ، أفكر في قضايا محددة غير عامل الرصيف مثل:

1. تجميع السجلات التي تلتقط جميع متغيرات env أو phpinfo المنسية المتبقية على خادم ويب للإنتاج - لذا كن حذرًا مع الأسرار والتكوين بشكل صحيح.
2. ربما حصان طروادة الذي يكشف Vars - لذلك لا تقم بتشغيل برامج غير موثوق بها.
3. الهجمات التي تستغل الضعف مثل حقن SQL - لذا تحقق من صحة الإدخال واستخدم جدار حماية لتطبيق الويب.

نقاط الضعف المعروضة في الجزء العلوي من هذا الموضوع:

يمكن الوصول إليها بأي عملية في الحاوية ، وبالتالي "تسرب" بسهولة

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

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

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

هل يقوم الأشخاص بتخزين البيئة في الصور بدلاً من الإعداد في وقت التشغيل أم أنني أسيء فهم هذه الصورة. لا تعيد الأسرار إلى القطع الأثرية ، أليس كذلك؟ Yes sudo docker inspect container_name يعطي المتغير env ، ولكن إذا كان لديك على خادم الإنتاج الخاص بي ، فإن iv فقده بالفعل. sudo docker inspect image_name ليس لديه حق الوصول إلى متغيرات env الخاصة بي التي تم تعيينها في وقت التشغيل.

مشتركة مع أي حاوية مرتبطة بالحاوية

ماذا عن عدم استخدام الروابط والشبكات الجديدة بدلاً من ذلك؟

المشكلة الوحيدة التي تبدو وكأنها مشكلة عامل ميناء وليست عالمية هي الروابط ...

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

لم أجد طريقة جيدة ومعقولة للتعامل مع هذا المأزق دون التغلب على بعض الأشياء الأخرى التي أجدها مفيدة في عامل الرصيف (انظر: docker squash ).

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

أعتقد أن docker build يحتاج إلى بعض الوظائف للتعامل مع البيانات المؤقتة مثل الأسرار حتى لا تجد طريقها إلى حاوية الشحن النهائية.

أعتقد أن بناء عامل الإرساء يحتاج إلى بعض الوظائف للتعامل مع البيانات المؤقتة مثل الأسرار

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

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

إذا لم تكن الأسرار جزءًا من الصورة ، فيمكنك تشغيل حاوية سريعة الزوال ، والتي من شأنها أن تعكس / توكيل جميع مواردك المحمية بشكل سري وتوفر وصولاً غير سري. الانعكاس ، راجع للشغل له سبب آخر: https://developers.slashdot.org/story/16/03/23/0652204/how-one-dev-broke-node-and-thousands-of-projects-in-11-lines -من جافا سكريبت

يمكنك مشاركة مفتاح ssh نفسه أيضًا ، لكن لن تتمكن من التحكم في استخدامه.

@ bhamilton-idexx إذا تأكدت من أن المصادقة على مستودعاتك الخاصة تعمل برمز قصير العمر ، فلا داعي للقلق بشأن السر الذي يظل موجودًا في صورة عامل الإرساء.
لديك نظام إنشاء ينشئ رمزًا مميزًا مع ttl لمدة ساعة واحدة ، اجعل هذا متاحًا كمتغير بيئة لبناء عامل الإرساء.
يمكنك الإنشاء جلب تفاصيل البنية المطلوبة ، ولكن تنتهي المهلة السرية بعد فترة وجيزة من اكتمال البنيات ، مما يؤدي إلى إغلاق متجه الهجوم.

كنت أقرأ مجموعة من هذه الخيوط الآن وميزة واحدة من شأنها أن تحل بعض حالات الاستخدام هنا وسيكون لها حالات استخدام خارج الأسرار هي علامة --add لـ docker run التي تنسخ ملفًا في الحاوية ، تمامًا مثل عبارة ADD في Dockerfiles

هذه المقالة هي A + http://elasticcompute.io/2016/01/21/runtime-secrets-with-docker-containers/

هذا حقا مقال عظيم قراءة جيدة جدا. وهو بالضبط نوع الشيء الذي كنا نأمل أن نراه.

بالمناسبة:

تم العثور أيضًا على بعض أدوات الأسرار الأخرى التي يبدو أنها فُقدت هناك من المقالة. آسف على أي تكرار / ازدواجية. لم ألاحظ ذكرها هنا حتى الآن:

بناء أسرار الوقت:

https://github.com/defunctzombie/docket

أسرار وقت التشغيل:

https://github.com/ehazlett/docker-volume-libsecret

ماذا يعتقد الناس؟ تشكرات.

لي:

هذه الأدوات الأحدث ^ ^ تبدو جيدة جدًا الآن. وهم بالتأكيد لم يكونوا موجودين عندما بدأنا هذه التذكرة لأول مرة. ولكن الشيء الرئيسي الذي أشعر به الآن لا يزال يفتقد أكثر:

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

لقد كتبنا أداة أخرى ، على غرار docket ، تستخدم تنسيق الصورة الجديد:

https://github.com/AngryBytes/docker-surgery

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

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

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

Vanuan [Dockerfile] لا يمكنه التكاثر. يضمن الأمر RUN أنه لا يمكنني أنت وأنا أن نتوقع بشكل معقول الحصول على نفس الصورة بالضبط من تشغيلين. لماذا ا؟ لأن الأشخاص يستخدمون RUN في معظم الأوقات للوصول إلى موارد الشبكة. إذا كنت تريد نفس الصورة مثلي ، فأنت بحاجة إلى إنشاء صورتك الخاصة "من" صورتي. لن يعطينا أي ترتيب آخر نفس الصور. لا يمكن لأي ترتيب آخر

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

stephank لقد قمت بتطبيق أداة بناء عامل

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

ما يبدو عليه خط أنابيب البناء متروك تمامًا للمشروع باستخدام ملف محدد لتكوين متطلبات البناء.

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

kaos من ناحية ، لم أرغب في الانحراف عن أدوات Docker للمخزون. من ناحية أخرى ، أشعر أنه يجب أن يكون هناك المزيد من المنافسة بين أدوات بناء الصور. هذا يبدو مثيرا للاهتمام! 😀

thaJeztah لأسرار البيئة (12 عاملاً) ، نحن نغلق Docker daemon عبر Twistlock (+ Scalock) لمنع تسرب متغيرات البيئة عبر الفحص. سيكون رائعًا إذا كانت لدينا قدرة Docker الأصلية على عدم تسريب أكبر قدر من المعلومات المميزة عبر الفحص لجعل هذا حقيقة أكثر ملاءمة.

alexkolson أعتقد أن مفتاح هذا الموضوع هو "لا تفعل هذا" إلا إذا كنت قد خففت X ، Y ، Z. من الواضح أنه شيء هندسي - سيكون هناك دائمًا "حلول" للمشاكل الشائعة. ومع ذلك ، يعد التثقيف بشأن ما لا يجب فعله ولماذا أمرًا مهمًا حتى تبدأ الحلول الحقيقية. الشيطان دائمًا في الإعدادات الافتراضية - لذلك نحن بحاجة إلى التأكد من أن المستخدمين الجدد يفهمون ما هو في خطر.

ربما يمكن لبعضكم يا رفاق مساعدتي لأنني لا أجرب الكثير من الخبرة مع عامل الرصيف حتى الآن.
لقد استخدمت Hashicorps Vault لجلب أسراري.

ما فعلته بشكل أساسي هو تمرير رمز مميز كوسيطة بناء ويمكن استخدام الرمز المميز لجلب معلومات حساسة من Vault. يحدث هذا في وقت الإنشاء ولا يمكن أن ينجح إلا إذا كان Vault "غير مغلق" (مفتوح لجلب البيانات). بعد البناء يتم إبطال الرمز المستخدم.

لكنني أعتقد أنني ما زلت أواجه بعض المشكلات الشائعة.

• لا بد لي من إنشاء صور جديدة إذا تغيرت البيانات الحساسة
• إذا تعرضت صورتي للسرقة / الاختراق ، فستكون البيانات الحساسة داخل الصورة.

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

إذن ما مدى سوء فعل ذلك (لا بأس من القول إنني أفسدت وقتًا كبيرًا ؛)) هل لدى أي شخص نصائح وحيل لجعل الأمور أكثر أمانًا؟

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

أيضًا ، تعمل Vault على خلفية مصادقة AWS والتي ستوفر مفيدة في المستقبل إذا كنت تستخدم AWS كمزود خدمة سحابية.

@ jaredm4 هل يمكنك توضيح هذا البيان من فضلك ؟:

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

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

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

سيكون موضع تقدير أي توجيه هنا. شكرا

بالتأكيد mcmatthew ، على الرغم من أنني يجب أن أبدأ بالقول إنني ما زلت أحاول إتقان Vault لذا فإن تجربتي خفيفة جدًا.

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

عند تمهيد الحاوية ، سيلاحظ تطبيق ريلز الخاص بك أنه لا يحتوي على أسرار بعد ، ويجب أن يجلبها من Vault. يحتوي على app-id ، وسيحتاج بطريقة ما إلى إنشاء user-id . ستحتاج إلى تحديد إنشاء معرف المستخدم هذا بواسطتك ، ولكن تلميحات التوثيق الخاصة بهم على أنها "بشكل عام قيمة فريدة لجهاز ما ، مثل عنوان MAC أو معرف المثيل ، أو قيمة مجزأة من هذه القيم الفريدة."

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

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

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

أتمنى أن يساعد ذلك. أعلم ، مستوى عالٍ قليلاً ، لكن هذه هي الطريقة التي خططنا للتعامل معها.

ما هو غير واضح هو ما يجب أن يظل سريًا أو معرف التطبيق أو معرف المستخدم أو كليهما.

حسنًا ، الإجابة هي https://www.vaultproject.io/docs/auth/app-id.html
ولكن لا يزال من غير الواضح سبب كونها أكثر أمانًا من مجرد الوصول العادي بجدار الحماية.
ربما يجب ربط كل سر مضيف بسر التطبيق (السياسة)؟
أي إذا كان لديك حق الوصول إلى سر المضيف ، فسيمكنك الوصول إلى تطبيقات معينة إذا كنت تعرف أسمائها السرية؟

الآن نحن بحاجة لتخزين 2 توكن في مكان ما؟

Vanuan يجب أن يظل كلاهما سريًا قدر الإمكان ، نعم.

الغرض الرئيسي من معرف التطبيق هو تقييد الوصول إلى بعض الأسرار داخل Vault عبر السياسات. يحصل أي شخص لديه حق الوصول إلى معرف التطبيق على حق الوصول إلى أسرار سياسات معرف التطبيق. يجب أن يتم توفير معرف التطبيق من خلال إستراتيجية النشر الخاصة بك. على سبيل المثال ، إذا كنت تستخدم Chef ، فيمكنك تعيينه في أكياس المعلمات (أو CustomJSON لـ OpsWorks). ومع ذلك ، لن يسمح لأي شخص بالوصول إلى Vault بمفرده. لذلك لن يتمكن أي شخص تمكّن من الوصول إلى Chef من الوصول إلى Vault.

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

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

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

(مرة أخرى ، هذا هو تفسيري بعد التملص من الوثائق بأفضل ما يمكنني)

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

thaJeztah :

يمكن الوصول إليها عن طريق أي عملية في الحاوية ، وبالتالي "تسرب" بسهولة

هل يمكنك دعم هذا الادعاء؟ لا يمكن للعمليات غير المتميزة الوصول إلى متغيرات البيئة للعمليات غير الأم. راجع https://help.ubuntu.com/community/EnvironmentVariables#Process_locality.

تم تعيين متغيرات البيئة للحاوية (عبر --env أو --env-file ) _ يمكن الوصول إليها من خلال أي عملية في الحاوية.

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

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

أعلم أنه خارج عن الموضوع ولكن هل لاحظ أي شخص آخر أن هذه المشكلة نشطة منذ عام كامل تقريبًا الآن! غدا هو الذكرى. 👏

هل سيكون من الممكن لعملية الحاوية أن تقرأ متغيرات env في ذاكرة العملية ثم تلغي ضبطها (في البيئة)؟ هل هذا يصلح معظم المخاوف الأمنية وقت التشغيل؟

davibe ، المشكلة في ذلك هي أنه إذا تمت إعادة تشغيل الحاوية أو عملياتها ، المتغيرات من

حاولت ولكن يبدو أن env vars لا يزال هناك بعد إعادة التشغيل.

dade<strong i="6">@choo</strong>:~/work/grocerest(master)$ cat test.js
console.log("FOO value: " + process.env.FOO);
delete(process.env.FOO);
console.log("FOO value after delete: " + process.env.FOO);

dade<strong i="7">@choo</strong>:~/work/grocerest(master)$ docker run --name test -it -e FOO=BAR -v $(pwd):/data/ node node /data/test.js
FOO value: BAR
FOO value after delete: undefined

dade<strong i="8">@choo</strong>:~/work/grocerest(master)$ docker restart test
test

dade<strong i="9">@choo</strong>:~/work/grocerest(master)$ docker logs test
FOO value: BAR
FOO value after delete: undefined
FOO value: BAR
FOO value after delete: undefined

ربما كان عامل ميناء ينفذ عملي كطفل باش؟ أعتقد أنه لا ينبغي ..

davibe :

unset 'SECRET_ENV_VAR'

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

لذا فإن إحدى الأفكار هي إزالة sudo و su من الحاوية الخاصة بك وإضافة أمر USER قبل أي ENTRYPOINT أو CMD . يجب ألا يحصل أي شخص يشغل الحاوية الخاصة بك الآن على فرصة للتشغيل كـ root (إذا لم أكن مخطئًا) وبالتالي يمكنك الآن إخفاء شيء عنه بالفعل.

فكرة أخرى (أفضل IMHO) تتمثل في إضافة فكرة المستخدمين والمجموعات إلى مقبس Docker وإلى الحاويات ، بحيث يمكنك إخبار GROUP-A بإمكانية الوصول إلى الحاويات باستخدام TAG-B ، وأن USER-C ينتمي إلى GROUP- أ حتى أنه لديه حق الوصول إلى تلك الحاويات. يمكن أن يكون إذنًا لكل عملية (لدى المجموعة A حق الوصول لبدء / إيقاف TAG-B ، ولدى GROUP-B حق الوصول إلى exec ، ولدى GROUP-C حق الوصول إلى rm / فحص ، وما إلى ذلك).

بعد البحث في هذا الأمر لبضع ساعات ، لا أستطيع أن أصدق أنه لا يبدو أنه لا يوجد حل أو حل بديل موصى به رسميًا لأسرار وقت الإنشاء ، ويبدو أن شيئًا مثل https://github.com/dockito/vault هو الخيار الوحيد القابل للتطبيق لـ أسرار وقت البناء (دون سحق الصورة الناتجة بالكامل أو بنائها يدويًا في المقام الأول). لسوء الحظ ، https://github.com/dockito/vault محدد تمامًا لمفاتيح ssh ، لذا أذهب لمحاولة تكييفه لاستضافة ملفات تخزين بيانات اعتماد git https أيضًا ...

بعد ما يبدو إلى الأبد (في الأصل سمعت أنه كان مقررًا لإصدار الربع الرابع من عام 2015) ، يبدو أن AWS ECS قد جاء أخيرًا من خلال وعدهم بجلب أدوار IAM إلى تطبيقات الإرساء . هنا هو بلوق وظيفة أيضا.

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

لم أجربها بعد ، لكنها في قائمتي القصيرة ...

يبدو أيضًا أن لدى Kubernetes بعض الأسرار في التعامل التي تذكرني بالكثير من علامات بيانات Chef المشفرة.

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

لقد ركضت للتو عبر شيء قد يساعد في هذا الصدد: https://github.com/docker/docker/pull/13587

يبدو أن هذا متاح بدءًا من docker v1.10.0 ، لكنني لم ألاحظه حتى الآن. أعتقد أن الحل الذي أميل إليه في هذه المرحلة هو استخدام https://www.vaultproject.io/ لتخزين واسترداد الأسرار ، وتخزينها داخل الحاوية في نظام ملفات tmpfs مثبت على / أسرار أو شيء من هذا القبيل . مع تمكين ميزة ECS الجديدة لأدوار IAM على الحاويات ، أعتقد أنه يجب أن أكون قادرًا على استخدام مصادقة AWS EC2 الخاصة بالمخزن لتأمين التفويض للأسرار نفسها. (بالنسبة إلى النظام الأساسي المستقل ، قد أميل إلى استخدام مصادقة معرف التطبيق الخاصة بهم.)

على أي حال ، كانت القطعة المفقودة بالنسبة لي هي المكان الذي أضع فيه الأسرار بأمان بمجرد استعادتها. يبدو أن خيار tmpfs خيار جيد بالنسبة لي. الشيء الوحيد المفقود هو أن ECS لا يبدو أنها تدعم هذه المعلمة حتى الآن ، ولهذا السبب قمت بإرسال هذا اليوم: https://github.com/aws/amazon-ecs-agent/issues/469

كل ذلك يبدو وكأنه حل شامل جدا IMHO.

CameronGo ، شكرا على المؤشر. إذا فهمت بشكل صحيح ، لا يمكن استخدام هذا في البناء الجيد ، أو هل يمكن ذلك؟

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

يتولى Jenkins هذا الأمر نيابةً عنا ويخزن بيانات الاعتماد للوصول إلى Git.

كيف يعمل ذلك مع عامل ميناء؟ أم أنك لست git clone داخل الحاوية نفسها؟

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

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

بالنسبة لأسرار وقت التشغيل ، قررت استخدام http://kubernetes.io/docs/user-guide/secrets/. هذا لا يعمل إلا إذا كنت تستخدم kubernetes. خلاف ذلك يبدو قبو على ما يرام. أي شيء سري سواء في الصورة التي تم إنشاؤها أو الطبقة المؤقتة فكرة سيئة.

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

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

أنا أعمل حاليًا على حل باستخدام Vault :

1. جهاز Builder يحتوي على Vault مثبتًا ويحتوي على رمز مميز محفوظ محليًا
2. عند بدء البناء ، تطلب آلة البناء رمزًا جديدًا مؤقتًا صالحًا لدقائق فقط (بناءً على الإنشاء ، يمكن قبول ساعة واحدة)
3. يضخ الرمز المميز باسم build arg
4. تحتوي صورة Docker أيضًا على Vault مثبتًا (أو يتم تثبيته وإزالته أثناء الإنشاء) واستخدام هذا الرمز المميز يمكنه جلب الأسرار الحقيقية

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

لم أبني هذا بعد ، لكني أعمل عليه.

يرتبط إلى حد ما بتعليقkozikow : "فيما يتعلق بأسرار وقت البناء - لا يمكنني التفكير في حالة استخدام أسرار وقت البناء الأخرى بخلاف توزيع التعليمات البرمجية الخاصة."

ربما لا يكون سر وقت البناء على وجه التحديد ، ولكن لدي حاجة لحالة استخدام (تأمين) كلمة مرور أثناء وقت الإنشاء في Dockerfile للسماح بتنزيل عنصر تم إنشاؤه بالفعل عبر أمر RUN curl. يتطلب تنزيل وقت الإنشاء بيانات اعتماد المستخدم للمصادقة من أجل الحصول على الأداة - لذلك نقوم بتمرير كلمة المرور كمتغير بيئة في Dockerfile في الوقت الحالي (ما زلنا في Dev). تحدث الإنشاءات خلف الكواليس تلقائيًا ، حيث نستخدم OpenShift ، ويتم إخراج متغيرات البيئة في Dockerfile إلى السجلات أثناء الإنشاء ، مثل أي أمر إنشاء عامل ميناء. هذا يجعل كلمة المرور مرئية لأي شخص لديه حق الوصول إلى السجلات ، بما في ذلك المطورين لدينا. لقد كنت أحاول بشدة اكتشاف طريقة لإرسال كلمة المرور بحيث يمكن استخدامها أثناء إنشاء عامل الإرساء ، ولكن بعد ذلك لم يكن لدي إخراج كلمة المرور للسجلات أو انتهى بي الأمر في أي طبقات.

أنا أيضًا أؤيد ما قاله

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

كبداية أقترح:

• السر لا يظهر في فحص عامل الميناء
• بعد بدء العملية 1 ، لا يتوفر السر داخل أي ملف يمكن الوصول إليه من الحاوية (بما في ذلك الملفات المثبتة على وحدة التخزين)
• السر غير متوفر في / proc / 1 / cmdline
• يتم نقل السر إلى الحاوية بشكل مشفر

أي حل مقترح أعلاه ينتهك أحد هذه المشاكل يمثل مشكلة.

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

gtmtech اقتراحات رائعة :)

بعد بدء العملية 1 ، لا يتوفر السر داخل أي ملف يمكن الوصول إليه من الحاوية (بما في ذلك الملفات المثبتة على وحدة التخزين)

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

سأضيف إلى قائمة متطلبات وقت التشغيل:

• مصادقة / ترخيص الحاوية عند تمهيد السر الأول.

على سبيل المثال ، يوفر Vault ترخيصًا مع AppRole Backend ولكنه مفتوح فيما يتعلق بكيفية تعريف الحاويات عن نفسها.

قدم نيك سوليفان مشروع PAL الخاص بـ Clouflare قبل بضعة أسابيع ، واعدًا بفتح المصدر قريبًا ، والذي يجب أن يوفر إجابة واحدة محتملة لسؤال المصادقة باستخدام كاتب العدل.

من منظور التطبيق ، هناك ثلاث طرق للتعامل مع هذا:

1. احصل على سر من متغير البيئة.
2. احصل على سر من ملف.
3. احصل على سر من نظام آخر.

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

يتمحور Docker حول التنوع ودعم مجموعة متنوعة من حالات الاستخدام. على هذا الأساس يعتبر 1. و 2. أكثر جاذبية من وجهة نظر التطبيق ، على الرغم من حقيقة أنهما يتركان "فتات" على النظام.

أحد الأساليب الشائعة التي أستخدمها بالتأكيد هو إدخال الأسرار عبر برنامج نصي لنقطة الدخول (على سبيل المثال ، استخدم أداة مثل Creditstash أو KMS العادي في AWS وادمجها مع أدوار IAM). في هذا الصدد ، تقوم بالفعل بالخطوة رقم 3 أعلاه في البرنامج النصي لنقطة الإدخال ، وتقوم إما بتنفيذ الأمر رقم 1 (تعيين متغير بيئة) أو رقم 2 (الكتابة إلى ملف). هذا الأسلوب ديناميكي ولأول مرة (متغيرات البيئة) ، لا يعرض بيانات الاعتماد في سجلات عامل الإرساء أو فحص عامل الإرساء.

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

هذه منطقة حيث يمكن لـ Docker إضافة وظائف لتجنب الاضطرار إلى استخدام البرامج النصية الخاصة بنقطة الإدخال الخاصة بك. يحب Docker المكونات الإضافية ويمكن أن يوفر رابطًا في دورة حياة الحاوية حيث يمكنه دعم المكونات الإضافية لمزود "الأسرار" ، والتي تؤدي بشكل أساسي وظيفة البرنامج النصي لنقطة الإدخال اليدوية وتضخ الأسرار في الحاوية (عبر متغير البيئة الداخلية أو الملف). لذلك يمكن أن يكون لديك موفر أسرار Hashicorp Vault ، وموفر أسرار AWS KMS وما إلى ذلك ، ربما يكون لدى Docker مزود خاص به يعتمد على تشفير RSA (عبر الشهادات الرقمية). هذا المفهوم برمته مشابه بشكل فضفاض لمفهوم Kubernetes للأسرار ، والذي يقدم أسرارًا في نظام ملفات الحاوية.

بالطبع هناك تعقيد في كيفية تفويض الوصول إلى مزود الأسرار ، وهي مشكلة تواجهها اليوم بغض النظر. مع Hashicorp ، يمكنك إصدار وتمرير رمز مميز لمرة واحدة / محدودة المدة للمصادقة ، مع AWS لأدوار IAM ، مع نهج تشفير Docker RSA الذي ذكرته ، قد يكون مجرد تمرير أسرار مشفرة باستخدام شهادة Docker Engine العامة.

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

إن قضية "الصفر السري" هي مشكلة خادعة. وقت البناء أم وقت التشغيل؟ كلاهما له مزايا وعيوب ، وتدابير أمنية وعيوب واضحة (واختراقات وتجاوزات!).

ومع ذلك ، كنت أفكر كثيرًا في كيفية وصول إدارة المرور / المفتاح إلى التطبيق و / أو الخدمة.

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

سيتم توفير الكود والتكوين والأسرار عبر خدمة (خدمات) الدعم. في هذه الحالة ، نستخدم Stash و Consul و Vault. طالما زادت التبعية ، كذلك تكون القدرة على سحب التكوين والأسرار حسب الحاجة.

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

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

أود أن أرى هذه الوظيفة مطبقة كمكوِّن إضافي منشئ في Docker core (بالإضافة إلى بعض الميزات المفيدة الأخرى التي تمتلكها Rockerfiles)!

أرى جميع المقترحات الأربعة الموجودة حاليًا في OP تتعلق بالتخزين السري 🙁

أود أن أقول أن عمال الرصيف يجب أن يسهلوا تمرير كلمة سر / كلمة مرور إلى _ مثيل رصيف _ لكن تخزين / إدارة هذه الأسرار (ويجب أن يكون) خارج نطاق عامل الرصيف.

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

بالنسبة إلى _كيفية إدارة الأسرار_ ، أود أن أقول أي شيء يريده المستخدم ، من نص برمجي bash إلى التكامل بواسطة برنامج مثل Kubernetes .

ما الخطأ في تنفيذ MOUNT مثل حوامل الروك كما لاحظ @ agilgur5 سابقًا؟ لا أستطيع أن أصدق أن هذا النقاش قد مضى وقتًا طويلاً لدرجة أن الفريق اضطر إلى تفكيك الأمر docker build بشكل فعال من أجل تلبية حالة الاستخدام السهلة حقًا. هل نحتاج إلى خادم HTTP آخر في هذا المزيج؟ قبلة.

قضيت ساعات طويلة حول هذا الموضوع ...

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

يبدو أن [Habitus] (http://www.habitus.io/) هو خيار آخر ، ولكن في حالتي ، لا أريد إضافة أدوات أخرى بشكل أساسي لأنني أرغب في أن تكون عملية الإنشاء على خادم CI وعلى جهاز الكمبيوتر الخاص بالمستخدم بسيط / نفس.

وماذا عن طريقة عامل الإرساء (docker)؟

فيما يلي مثال على خطوتين للبناء بطريقة جيدة كما تحدثت للتو أعلاه: https://github.com/BenoitNorrin/docker-build-with-secrets

لا تتردد في التعليق ...

مثير للإعجاب. يذكرني نوعًا ما بكيفية إنشاء OpenShift.

يبدو لي أنك تقوم بتمرير كلمة المرور في سطر الأوامر. هل هناك طريقة اخرى؟

لاحظ أن هناك علاقات عامة قيد التشغيل لأسرار وقت البناء هنا ؛ https://github.com/docker/docker/pull/28079 (ستكون أسرار وقت تشغيل الخدمات في عامل الإرساء 1.13 ، راجع https://github.com/docker/docker/pull/27794)

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

cassiussa :
أنا لا أفهم ما تقصد؟
1 / تم تمرير كلمات المرور إلى "منشئ الحاوية" وهي ليست الصورة النهائية. يقوم هذا المنشئ ببناء عامل بناء وإنتاج صورة بناءً على Dockerfile.realease. لا توجد أسرار مخزنة في تاريخ هذه الصورة النهائية.
2 / لا تتردد في استخدام docker-compose ( مثال ) إذا كنت لا تريد تمرير كلمة المرور إلى سطر الأوامر

BenoitNorrin أعتقد أنه قد يتم توسيعه ليشمل سربًا في المستقبل ، لكن diogomonica قد يعرف المزيد عن ذلك

يبدو وكأنه:

هذا حاليًا في وضع Swarm فقط لأن مخزن الدعم هو Swarm وعلى هذا النحو مخصص لنظام Linux فقط. هذا هو الأساس للدعم السري المستقبلي في Docker مع التحسينات المحتملة مثل دعم Windows ، ومخازن الدعم المختلفة ، وما إلى ذلك.

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

في الثلاثاء ، 29 تشرين الثاني (نوفمبر) 2016 ، الساعة 15:53 ​​، أرسل مايكل واركنتين ، [email protected]
كتب:

يبدو وكأنه:

هذا حاليًا في وضع Swarm فقط لأن مخزن الدعم هو Swarm و as
هذا فقط لنظام التشغيل Linux. هذا هو الأساس للدعم السري في المستقبل في
Docker مع تحسينات محتملة مثل دعم Windows ، مختلفة
مخازن الدعم ، إلخ.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/docker/docker/issues/13490#issuecomment-263608915 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAZk5vlLwsBHHTTbUS_vvx-qTuwnkp6Oks5rDEpjgaJpZM4Eq021
.

أعتقد أن الحل هو تشفير بعض أجزاء المعلومات التي تم تمريرها من ملف docker-compose .

على سبيل المثال ، قم بتشغيل docker inspect ويجب عرض / تمييز المعلومات المشفرة على أنها _encrypted_. ثم يعرض docker inspect --encryption-key some_key_file جميع المعلومات المشفرة ، غير المشفرة.

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

أعتقد أن التشفير _ هو المفتاح_ :)

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

في الثلاثاء ، 3 كانون الثاني (يناير) 2017 ، الساعة 04:14 ، كتب Hisa ، [email protected] :

أعتقد أن الحل سيكون لتشفير بعض أجزاء من المعلومات التي تم تمريرها
من ملف docker-compose.

على سبيل المثال ، قم بتشغيل فحص عامل الإرساء ويجب أن تكون المعلومات المشفرة
معروضة / مميزة على أنها مشفرة . ثم فحص عامل الميناء - مفتاح التشفير
سيُظهر some_key_file جميع المعلومات المشفرة ، غير المشفرة.

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

أعتقد أن التشفير هو المفتاح :)

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

نظرًا لأنني لم أراها مذكورة ، فإليك مقالة أخرى جيدة حول التعامل مع الأسرار في AWS ECS: https://aws.amazon.com/blogs/security/how-to-manage-secrets-for-amazon-ec2-container- التطبيقات القائمة على الخدمة عن طريق استخدام amazon-s3 و docker /

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

يبدو أن أمر Docker secret ينطبق حاليًا فقط على Docker Swarm (أي خدمات عامل الإرساء) ، لذا فهو غير قابل للتطبيق حاليًا لحاويات Docker العامة.

أيضًا docker secret يدير فقط أسرار وقت التشغيل ، وليس بناء أسرار الوقت.

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

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

سأستمر في استخدام موسيقى الروك حتى عام 2019 أو عندما يرى شخص ما معنى بعد ذلك.

في الأحد ، 22 كانون الثاني (يناير) 2017 ، الساعة 23:47 ، كتب شين StClair ، [email protected] :

كما أن أسرار عامل التحميل تدير فقط أسرار وقت التشغيل ، وليس بناء أسرار الوقت.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/docker/docker/issues/13490#issuecomment-274370450 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAZk5vJVJe4OeypWd1Cwqmh8Gzyn8P-mks5rU-qqgaJpZM4Eq021
.

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

في الإثنين ، 23 كانون الثاني (يناير) 2017 ، 09:31 كتب بريان هانت [email protected] :

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

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

سأستمر في استخدام موسيقى الروك حتى عام 2019 أو عندما يرى شخص ما معنى
من ثم.

يوم الأحد ، 22 كانون الثاني (يناير) 2017 ، الساعة 23:47 شاين ستكلير ، [email protected]
كتب:

كما أن أسرار عامل التحميل تدير فقط أسرار وقت التشغيل ، وليس بناء أسرار الوقت.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/docker/docker/issues/13490#issuecomment-274370450 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAZk5vJVJe4OeypWd1Cwqmh8Gzyn8P-mks5rU-qqgaJpZM4Eq021
.

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

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

اعتقدت أن الشيء نفسه مثل mixja في أن الأمر secret يساعد فقط مستخدمي السرب ليس حلاً أكثر عمومية (كما فعلوا مع إرفاق مجلدات ثابتة). تعتمد كيفية إدارة أسرارك (ما هي ومن يمكنه الوصول إليها) بشكل كبير على النظام وتعتمد على الأجزاء المدفوعة و / أو OSS التي تجمعها معًا لإنشاء "النظام الأساسي" الخاص بك. مع انتقال شركة Docker إلى توفير منصة ، لست مندهشًا من أن أول تطبيق لها يعتمد على السرب تمامًا كما تقوم Hashicorp بدمج Vault في Atlas - فمن المنطقي.

كيف يتم تمرير الأسرار حقًا يقع خارج مساحة docker run . تقوم AWS بهذا النوع من المهام مع الأدوار والسياسات لمنح / رفض الأذونات بالإضافة إلى SDK. يقوم الشيف بذلك باستخدام علامات البيانات المشفرة و "التمهيد" المشفر للمصادقة. K8S لديها نسختها الخاصة مما تم إصداره للتو في 1.13. أنا متأكد من أن mesos ستضيف تطبيقًا مشابهًا في الوقت المناسب.

يبدو أن هذه التطبيقات تقع في معسكرين.
1) قم بتمرير السر عبر وحدة التخزين التي توفرها "المنصة" أو (الشيف / عامل الميناء / k8s
2) تمرير بيانات الاعتماد للتحدث إلى خدمة خارجية للحصول على الأشياء عند التمهيد (iam / Creditstash / إلخ)

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

يشجعني أن هذه الخطوة الأولى قد اتخذها عامل التحميل وآمل أن تخرج آلية أكثر عمومية مقابل docker run من هذا (لدعم المعسكر رقم 2) - مما يعني للأسف أنني لا أعتقد أن هذا الموضوع تم الوفاء بالمهمة الأولية ولا ينبغي إغلاقها بعد.

مثل!
تصميم بسيط ولكنه فعال للغاية

bacoboy ، mixja - سرب العقدة المفردة وخدمة الحاوية الواحدة ليست بهذا السوء
بدء سرب عامل ميناء ، إنشاء خدمة عامل ميناء نسخة متماثلة = 1

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

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

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

لإدخال أسرار وقت الإنشاء ، يمكننا الآن استخدام docker build --squash للقيام بما يلي بأمان:

COPY ssh_private_key_rsa /root/.ssh/id_rsa
RUN git pull ...
RUN rm -rf /root/.ssh/id_rsa

ستنتج علامة --squash طبقة واحدة لملف Dockerfile بأكمله: لن يكون هناك أي أثر للسر.

--squash متاح في Docker-1.13 كعلم تجريبي.

hmalphettes هذا يعني أنك تفقد مزايا الطبقات السفلية المشتركة بين البنيات.

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

zoidbergwill الطبقات الدنيا لا تزال مشتركة.

أوافق 100٪ مع @ cpuguy83. الاعتماد على علم وقت البناء لإخفاء الأسرار سيكون محفوفًا بالمخاطر. كان هناك اقتراح العلاقات العامة لوقت البناء (https://github.com/docker/docker/pull/30637) سأعمل على تغيير الأساس للحصول على مزيد من التعليقات.

wpalmer إذا كان لديك أدواتك كيفية الحصول على أسرار وقت البناء.

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

WDYT؟

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

+1 سر وقت الإنشاء! = سر وقت التشغيل

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

لماذا هذا صعب الفهم؟

في الخميس ، 16 فبراير 2017 ، 14:42 بول فان دير ليندن ، [email protected]
كتب:

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

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

pvanderlinden يمكنك أيضًا القيام بذلك بخطوتين للبناء.
هنا مثال: https://github.com/BenoitNorrin/docker-build-with-secrets

timka كما هو مذكور ، ليس من المستحسن https://github.com/docker/docker/pull/30637

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

timka يبدو أن النصف الأول من رسالتك يشير إلى أسرار وقت docker build .

البديل ، إذا كانت أسرار وقت الإنشاء ميزة قياسية ، فسيكون تشغيل هذه الخطوات داخل Dockerfile.

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

لمعلوماتك ، لقد كتبت https://github.com/abourget/secrets-bridge لمعالجة مشكلة أسرار وقت البناء.

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

يدعم الخادم إعادة توجيه وكيل SSH ، عبر نفق اتصال TLS websocket. إنه يعمل على Windows أيضًا!

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

أنا حالتي سأقوم بالتخلي عن "بناء عامل السفن" وبدلاً من ذلك استخدم الروك أو
شيء إذا كان إبداعي.

في الخميس ، 13 تموز (يوليو) 2017 ، الساعة 16:23 ، ألكسندر بورجيه ، [email protected]
كتب:

لمعلوماتك ، لقد كتبت https://github.com/abourget/secrets-bridge لمعالجة ملف
مشكلة أسرار وقت البناء.

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

يدعم الخادم إعادة توجيه وكيل SSH ، عبر نفق عبر TLS
اتصال websocket. إنه يعمل على Windows أيضًا!

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/moby/moby/issues/13490#issuecomment-315111388 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AAZk5hZqTAgPBjS9cFP_IsYNa9wv-yoAks5sNjaBgaJpZM4Eq021
.

إليكم أحدث اقتراح للأسرار: https://github.com/moby/moby/issues/33343

أعتقد أن وظيفة "البناء متعدد المراحل" الجديدة المضمنة في الإصدار الأخير من Docker CE تحل جزءًا كبيرًا من مشاكلنا.

https://docs.docker.com/engine/userguide/eng-image/multistage-build/

الحاويات التي يتم إنتاجها لتنفيذ الأوامر من Dockerfile تأتي مع /dev المطبوخ ولا يجب تسجيل أي تغييرات يتم إجراؤها هناك في طبقة. هل يستطيع عامل الإرساء تسليم أسرار المستخدم من خلال نقطة التحميل هذه؟ بنفس الطريقة التي يوفر بها /dev/init ؟

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

إنه أغسطس 2017. وفي الوقت نفسه ، رابط "المقترحات القديمة للتعامل مع الأسرار" في العدد الأصلي لقضايا من عام 2014.

لا توجد حتى الآن حلول جيدة لأسرار وقت البناء. تم إغلاق PR الذي عرض العلم --build-time-secret بدون تفسير. لم يتم تقديم شيء في "إذن ، ما المطلوب؟" يتم تنفيذ القسم.

في أثناء

الرئيس التنفيذي الجديد ستيف سينغ يركز على العملاء من رجال الأعمال
الجولة الأخيرة من 75 مليون دولار للمساعدة في تشكيل فريق المبيعات والتسويق

محدث: كما هو موضح أدناه بشكل صحيح

أعلم أنه غير مدمج ، ولكن secrets-bridge يعمل بشكل جيد في الوقت الحالي.

dmitriid أتفهم

لقد نشرت رابطًا لاقتراح أعلاه ، وشاهدت 0 بالضبط تعليقات عليه باستثناء تعليقي.

إليكم آخر اقتراح أسرار: # 33343

@ cpuguy83 رائع! لقد تخطيت نوعًا ما من الثلث الأخير من هذه المناقشة (وعدد قليل من المناقشات الأخرى) نظرًا لأن هناك الكثير من الأشياء التي يجب قراءتها (أثناء البحث في نفس الوقت عن حل) ، لذلك فاتني حقًا تعليقك ، آسف :(

بدأ هذا الموضوع في عام 2015.

إنه عام 2017.

لماذا لا يوجد حل لأسرار وقت البناء التي ليست مخترقة ورهيبة حتى الآن؟ من الواضح أنها مشكلة كبيرة لكثير من الناس ، ولكن لا يوجد حتى الآن حل جيد!

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

لماذا لا يوجد حل لأسرار وقت البناء التي ليست مخترقة ورهيبة حتى الآن؟

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

يرجى الاطلاع على تعليقي أعلى تعليقك:

لقد نشرت رابطًا لاقتراح أعلاه ، وشاهدت 0 بالضبط تعليقات عليه باستثناء تعليقي.
إليكم آخر اقتراح أسرار: # 33343

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

من السهل حلها. إنه يتطلب شيئًا فقط ، أي شيء ليس كذلك
خبز في الصور. وفي الواقع ، من السهل جدًا حلها ، توقف عن استخدامها
"بناء عامل ميناء" واستخدام python API أو rocker أو أي شيء آخر.

يوم الأربعاء ، 23 آب (أغسطس) ، 2017 الساعة 9:42 مساءً ، بريد إلكتروني بريان جوف [email protected]
كتب:

mshappe https://github.com/mshappe

لماذا لا يوجد حل لأسرار وقت البناء غير المخترقة و
رهيب ، حتى الآن؟

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

يرجى الاطلاع على تعليقي أعلى تعليقك:

لقد نشرت رابطًا لاقتراح أعلاه ، وشاهدت بالضبط 0 تعليقات على
ما عدا بلدي.
إليكم آخر اقتراح أسرار: # 33343
https://github.com/moby/moby/issues/33343

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

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/moby/moby/issues/13490#issuecomment-324441280 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AAZk5oEpcipmfCji1mXz6MOVt0p6-OA6ks5sbIC0gaJpZM4Eq021
.

binarytemple لقد بدأت في النظر إلى Rocker كبديل ، في الواقع ... ولكن فقط بسبب هذا الرصيف العقلي الغريب يبدو أنه يمتلك أسرار وقت البناء.

هذا غريب. أتحدث إلى الناس ويقومون بكل أنواع الاختراقات الغبية
مثل استخدام خدمة HTTP - التخلص من كل شيء (المراقبة / الحبيبية
أذونات / بساطة) يوفرها التحرير والسرد POSIX / SELinux. أنا فقط لا أفعل
تفهم. يبدو الرفض غير منطقي بالنسبة لي.

في يوم الأربعاء ، 23 أغسطس 2017 ، الساعة 23:03 مايكل سكوت شبي [email protected]
كتب:

binarytemple https://github.com/binarytemple لقد بدأت في البحث
الروك كبديل ، في الواقع ... ولكن فقط بسبب هذا الغريب
يبدو أن عامل عامل الإرساء العقلي لديه حول أسرار وقت البناء.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/moby/moby/issues/13490#issuecomment-324461257 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AAZk5ppZYsOhdfvgotCUk5l41Truo_EEks5sbJOLgaJpZM4Eq021
.

يعمل عامل الإرساء متعدد المراحل على حل الكثير من هذه المشكلات.

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

يعمل خادم البناء الخاص بنا مع بعض الأسرار المركبة كمجلدات ، لذلك نسخة CI الخاصة بنا في f.ex. /mnt/secrets/.npmrc في دليل العمل الحالي. ثم نستخدم Dockerfile مماثلة لتلك الموجودة أدناه.

FROM node:latest
WORKDIR /usr/src/app
COPY .npmrc .
RUN echo '{ "dependencies": [ "lodash" ] }' > package.json
RUN npm install
RUN ls -lah

FROM alpine:latest
WORKDIR /usr/src/app
COPY --from=0 /usr/src/app/node_modules ./node_modules
RUN ls -lah
CMD ["ls", "./node_modules"]

ستحتوي الصورة الناتجة على التبعيات المثبتة ، ولكن ليس npmrc أو أي آثار لمحتواها.

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

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

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

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

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

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

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

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

يمكن أن تبدو الأمور متوقفة في كثير من الأحيان عندما يكون هناك بالفعل أشخاص مجتهدون في العمل.
للبناء ، راجع github.com/moby/buildkit حيث يحدث معظم هذا العمل اليوم.

شكرا.

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

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

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

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

لا تختلف عملية إنشاء صورة docker عن أي نظام بناء آخر: يجب أن يكون لديك خط أنابيب بناء في مكانه.

Vanuan ليست كل اللغات بهذه البساطة في التعبئة والتغليف والتثبيت ، لتثبيتها ببساطة

أمثلة؟

تسحب مشاريع Python متطلباتها في وقت التثبيت ، وليس في الوقت المحدد. في حالتنا ، من مستودع pypi / conda خاص (محمي بكلمة مرور)

وبالتالي؟ اجعل التثبيت جزءًا من عملية الإنشاء الخاصة بك ، ثم انسخ الحزم المثبتة إلى صورة جديدة.

تحتاج فقط إلى التأكد من أن صورة البناء وصورة الإنتاج الخاصة بك تستندان إلى نفس صورة قاعدة Python.

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

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

ألا يمكنك فقط pip install requirements.txt في بناء المرحلة الأولى مع وجود أسرار متاحة لسحبها من مستودعاتك الخاصة. ثم تقوم المرحلة التالية من البناء بنسخ حزم الموقع من المرحلة الأولى.

لماذا يكون لديك Dockerfile إذا كان الشيء الوحيد الذي يمكنك استخدامه من أجله هو مجرد نسخ مجموعة من الدلائل؟

لما لا؟ يعد استخدام Dockerfile للبناء متسقًا.

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

اقرأ مرجع Dockerfile:
https://docs.docker.com/engine/reference/builder/

يبدو أنك كنت تركز بشكل أساسي على تعليمات RUN ، معتقدًا أن Dockerfile هو بديل لـ Makefile. ليس. تم تصميم Dockerfile لشيء واحد فقط: إنشاء صورة من بعض المواد المصدر. ماهية مادة المصدر هذه - تنزيل ثنائي عبر http أو مستودع git - لا يهم. لا يلزم أن يكون Docker هو نظام CI الخاص بك ، على الرغم من أنه يمكنك استخدامه كنظام واحد في ظل ظروف معينة.

يمكنني كتابة ملف travis ، أو تكوين التدفق في الخيزران.

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

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

إذا لم أكن أرغب في كل ذلك ، فسأتمسك بـ lxc + ansible ، ولا حاجة إلى عامل عامل في ذلك الوقت.

لا تحتاج docker build لذلك.

لا تحتاج docker build لذلك.

بالطبع يمكنك أيضًا تقديم برنامج نصي Makefile مخصص أو برنامج نصي build_image.sh لكل مشروع بدلاً من ملف Dockerfile واحد مكتفي ذاتيًا ، ولكن هذا له عيوب متعددة:

• التوافق عبر الأنظمة الأساسية: من خلال توفير Dockerfile ، أعلم أن أي نظام يمكنه تشغيل docker build سيكون قادرًا على إنشاء الصورة. من خلال توفير مخصص Makefile أو build_image.sh ، يجب أن أتأكد يدويًا من أن هؤلاء يعملون على جميع الأنظمة الأساسية التي أرغب في دعمها.
• واجهة معروفة للمستخدمين: إذا كنت تعرف عامل الإرساء ، فأنت تعرف بعضًا من سلوك docker build لأي مشروع ، حتى بدون النظر إلى Dockerfile (على سبيل المثال فيما يتعلق بالتخزين المؤقت ، إلخ ...). إذا كان لديّ مخصص Makefile أو build_image.sh ، لكل مشروع ، أحتاج أولاً إلى معرفة أوامر الإنشاء والتنظيف وأين وشكل النتيجة ، إذا كان هناك هو بعض التخزين المؤقت وبأي شكل ، ...

أوه ، Dockerfile بعيد كل البعد عن الاكتفاء الذاتي. خاصة لبيئة التنمية.
ضع في اعتبارك هذا:

• لا يعرف معظم المطورين جميع الخيارات المختلفة لـ docker build ، لكن الجميع تقريبًا يعرف كيفية تشغيل البرامج النصية bash
• يعتمد docker build على دليل السياق . لذلك ، ما لم تكن على استعداد لانتظار عدد غيغابايتات من البيانات (كود المصدر الخاص بك مع التبعيات) للانتقال من موقع إلى آخر لكل تغيير في خط المصدر ، فلن تستخدمه في التطوير.
• ما لم تقم ببناء كل شيء من نقطة الصفر ، فلديك اعتماد على
• من المحتمل أنك ستعتمد على مستودعات نظام التشغيل (سواء كنت تستخدم دبيان أو الصور المستندة إلى جبال الألب) ، إلا إذا قمت بتشغيل حاوية مباشرة إلى النظام الثنائي المبني بشكل ثابت
• ما لم تلتزم بكل شيء في git ، سيكون لديك بعض التبعيات على مستوى المشروع ، سواء كانت npm أو فهرس حزمة Python أو rubygems أو أي شيء آخر. لذلك ستعتمد على بعض سجلات الحزم الخارجية أو المرآة الخاصة بها
• كما لاحظ معظم الناس هنا عليك أن تعتمد على بعض حزمة مكان سري لالتبعيات الخاصة التي لا يمكن نشر إلى مستودع العام، لذلك عليك أن تعتمد على ذلك
• مطلوب توفير الأسرار للوصول إلى هذا الموقع الآمن ، لذلك ستعتمد على بعض الأنظمة التي ستوزع الأسرار على المطورين
• بالإضافة إلى Dockefile ، ستحتاج إلى docker-compose.yml ، وهي ليست منصة مشتركة: ما زلت تعتمد على اختلافات الخط المائل الخلفي / الأمامي.

التوافق عبر الأنظمة الأساسية: من خلال توفير Dockerfile ، أعلم أن أي نظام يمكنه تشغيل بناء عامل الميناء سيكون قادرًا على بناء الصورة.

لا يضمن Dockerfile التوافق عبر الأنظمة الأساسية. لا يزال يتعين عليك توفير ملفات Dockerfiles متعددة لمنصات متعددة. لا تعني عبارة "Can run docker build" "استخدام Linux" بعد الآن. يدعم Docker أيضًا صور Windows الأصلية. لا يزال يتعين عليك استخدام Cygwin + Linux VM إذا كنت تريد تشغيل شيء يستهدف بشكل خاص أجهزة Linux على مضيف Windows.

أوه ، ولم أذكر حتى x86 مقابل ARM ...

واجهة معروفة للمستخدمين: إذا كنت تعرف عامل الإرساء ، فأنت تعرف بعض سلوك إنشاء عامل الإرساء لأي مشروع ، حتى دون النظر إلى Dockerfile

إلا إذا كنت لا تفعل. يعرف الجميع كيفية تشغيل برنامج bash النصي بدون معلمات أو أمر واحد make . قلة من الناس يعرفون كيفية تحديد جميع خيارات سطر الأوامر المختلفة بشكل صحيح لـ docker build أو docker run أو docker-compose . من المحتم أن يكون لديك بعض البرامج النصية الخاصة بالغلاف bash أو cmd.

مع كل الاحترام لما فعله فريق Docker ، أعتقد أنك تطلب الكثير. أخشى أن مشروع Mobyproject ليس لديه مثل هذا النطاق الواسع لدعم جميع عمليات سير عمل التطوير التي يمكن تخيلها.

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

لا يعرف معظم المطورين جميع الخيارات المختلفة لبناء عامل ميناء ، لكن الجميع تقريبًا يعرف كيفية تشغيل البرامج النصية bash

إذا كنت مشتركًا في 10 مشاريع ، وكلهم يستخدمون Dockerfile ، فأنا بحاجة إلى التعرف على عامل الإرساء مرة واحدة فقط ، ولكن مع اقتراحك ، أحتاج إلى تعلم 10 نصوص بناء مختلفة تمامًا. كيف يمكنني مسح ذاكرة التخزين المؤقت والبدء من نقطة الصفر لمشروع Foo build_image.sh مرة أخرى؟ انه غير واضح. إذا تم إنشاء الصورة باستخدام docker build ، فمن الواضح (أحتاج إلى معرفة كيفية عمل docker ، لكنني أيضًا بحاجة إلى القيام بذلك لاستخدام الصورة التي تأتي من build_image.sh ).

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

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

مع كل الاحترام لما فعله فريق Docker ، أعتقد أنك تطلب الكثير. أخشى أن مشروع Mobyproject ليس لديه مثل هذا النطاق الواسع لدعم جميع عمليات سير عمل التطوير التي يمكن تخيلها.

يبدو لي أن ما يطلبه معظم الناس هنا ليس شيئًا من هذا القبيل ، ولكن فقط من أجل طريقة بسيطة لاستخدام الأسرار في docker build بطريقة ليست أقل أمانًا من استخدامها في build_image.sh المخصص الخاص بك

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

1. أريد تشغيل صور الإنتاج على آلات التطوير. استخدام سجل عامل ميناء
2. أريد نظام CI موزعًا ، بحيث يكون لكل مطور بنية قابلة للتكرار. استخدم docker run لإنشاء مشروعك ، واستخدم docker prune للتنظيف
3. أريد إنشاء صور عامل ميناء حتى أتمكن من توزيعها. استخدم خادم CI مخصصًا حيث يمكنك تشغيل إنشاءات متعددة المراحل.

Vanuan ، لذلك أعتقد أن

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

لأي شخص مهتم: لقد حاولت استغلال "مقنع افتراضيًا" بناء-args مثل FTP_PROXY لبناء سياقات. إنه آمن فيما يتعلق بحقيقة أن docker-build لا يعرض تلك اللوحات المقنعة لبيانات وصفية للصورة ولا لطبقات الصورة.

كانت 36443 محاولة لتوسيعها إلى نموذج بناء باسم SECRET حتى نتمكن من تشجيع المستخدمين على استخدامه كحل بسيط لحل مشكلة الإدارة السرية.

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

أفضل رهان لي بعد ذلك هو اتباعAkihiroSuda الصورة المشورة ، استخدم docker build --network أو أداة مثل خلقة إلى مخزن / تمرير أسرار عبر ملقم TCP مؤقت فقط سياقات بناء مرئية تعيش داخل الخفي عامل ميناء واحد، على أوسع نطاق.

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

في متابعة إصدار Args المحددة مسبقًا لبناء الأسرار.

لذلك ، بشكل أساسي ، يمكنني استخدام عامل إنشاء عامل ، مع تعيين مثل هذا:

  myProject:
    build:
      context: ../myProject/
      args: 
        - HTTPS_PROXY=${NEXUS_USERNAME}
        - NO_PROXY=${NEXUS_PASSWORD}

وبعد ذلك ، في المجلد الذي يحتوي على ملف docker-compose.yml ، أنشئ ملفًا باسم ".env" مع أزواج من NEXUS_USERNAME و NEXUS_PASSWORD - والقيم المناسبة هناك.

أخيرًا ، في ملف Dockerfile نفسه ، نحدد أمر التشغيل كما يلي:
RUN wget - المستخدم $ HTTPS_PROXY - كلمة المرور $ NO_PROXY

ولا تعلن أن هذه ARGs في DockerFile.

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

darmbrust لقد جربت الحل الذي
هنا هو بلدي التأليف yml:
الإصدار: "3.3"
خدمات:

  buildToolsImage:
    image: vsbuildtools2017:web-v6

    build:
      context: .
      dockerfile: ./vsbuild-web-v6-optimized.dockerfile
      args:
        - CONTAINER_USER_PWD=${CONTAINER_USER_CREDS}

يوجد هنا ملف .env الموجود بجوار ملف yml:

CONTAINER_USER_CREDS=secretpassword

وهذا هو ملف الرصيف الخاص بي:

# escape=`
FROM microsoft/dotnet-framework:4.7.2-sdk
# Add non-root user
CMD ["sh", "-c", "echo ${CONTAINER_USER_PWD}"] 
RUN net user userone ${CONTAINER_USER_PWD} /add /Y

وأخيرًا يكون الأمر ببدء هذا الأمر كما يلي:

docker-compose -f docker-compose.buildImage.yml build

يقوم ببناء الصورة ولكن بدون استخدام كلمة المرور المخزنة في ملف env.

[تحذير] لم يتم استهلاك قالب بناء واحد أو أكثر [CONTAINER_USER_PWD]

ما الذي افتقده هنا؟
شكرا!

يجب عليك استخدام أحد https://docs.docker.com/engine/reference/builder/#predefined -args في ملف عامل الإرساء. لا يمكنك استخدام أسماء الوسائط الخاصة بك مثل CONTAINER_USER_PWD.

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

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

darmbrust نعم ، هذه هي الحيلة.
ومع ذلك ، ألا تعتقد أن رائحته كريهة؟ أي توصيات أفضل؟
شكرا!

من المحتمل ألا تكون كريهة الرائحة مثل كشف بيانات اعتماد وكيل ssh عبر بروتوكول TCP
عبر socat لأي عملية محلية للسرقة ، ولكن في الواقع ، كما هو الحال مع أي شيء
فيما يتعلق بالأسرار ، فإن "بناء عامل السفن" له رائحة كريهة بالفعل.

في الواقع ، لقد نسيت أن Docker for Mac لا يمكنه كشف مجال Unix
مآخذ على مضيف osx للحاويات ، بحيث يفتح حتى أكثر من
علبة من الديدان.

الحل الحالي الخاص بي ، قم بتشغيل حساب مستخدم جهاز Centos VM ، GitHub
تدخل بيانات الاعتماد فيه ، قم بالبناء باستخدام أداة "Rocker" (مهملة).

في الخميس ، 26 يوليو 2018 ، الساعة 21:49 ، كتب سمير كومار ، [email protected] :

darmbrust https://github.com/darmbrust نعم ، هذه هي الحيلة.
ومع ذلك ، ألا تعتقد أن رائحته كريهة؟ أي توصيات أفضل؟
شكرا!

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/moby/moby/issues/13490#issuecomment-408230125 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AAZk5iz1kvCpZ0s65ng4TwL7LmHa9zZvks5uKitDgaJpZM4Eq021
.

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

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

إنه أمر بسيط وواضح ، يسمح بتركيب وحدات التخزين ، (ملفات أو
الدلائل) في الحاوية أثناء البناء.

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

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

Newsflash ، كشف سلسلة مفاتيح SSH عبر TCP ، حتى على المضيف المحلي ليس كذلك
آمن ، ولا يتم تمرير بيانات الاعتماد عبر متغيرات البيئة (تلميح ، تشغيل
ps ، أو نظرة خاطفة على نظام ملفات / proc) ، وسيطات الأوامر ، والمتغيرات البيئية كلها موجودة ، عارية ، ليراها العالم.

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

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

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

في الخميس ، 26 يوليو 2018 ، الساعة 22:00 ، كتب دان أرمبروست ، [email protected] :

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

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

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/moby/moby/issues/13490#issuecomment-408233258 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AAZk5nvbBTj4BAv5TtELNIHhJN8mU0Ctks5uKi38gaJpZM4Eq021
.

binarytemple كل من سبق له العمل على Docker / moby (كما هو الحال في المهندسين الذين يقفون وراءه) يعرف بالضبط ما هي المشكلة وحتى أنه

الأحجام هي الحل نفسه الذي لا يصدق بشكل لا يصدق.
هناك اقتراح ، مذكور في تدفق التعليقات قليلاً ، يحاول حل هذا بطريقة معقولة (https://github.com/moby/moby/issues/33343)

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

تم إنجاز الكثير من العمل على المنشئ مؤخرًا وهو أمر غير مرئي بالضرورة بعد ، ولكن ثمار هذا الجهد ستبدأ في الظهور في الأشهر المقبلة.
بادئ ذي بدء ، يأتي Docker 18.06 مع تطبيق بناء بديل مدعوم بـ https://github.com/moby/buildkit.
قد تعتقد "كيف يساعدني هذا؟". يوفر Buildkit الكثير من العناصر الأولية منخفضة المستوى التي تمكننا من أن نكون أكثر مرونة في Docker builder. حتى بقدر ما تكون قادرًا على توفير محلل البناء الخاص بك (والذي يمكن أن يكون أي شيء من محلل Dockerfile المحسن إلى شيء مختلف تمامًا). المحللون محددون في الجزء العلوي من "Dockerfile" وهم مجرد أي صورة تريد استخدامها لتحليل الملف.

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

تمت إضافة دعم التثبيت السري إلى buildkit في https://github.com/moby/buildkit/pull/522 . تظهر بشكل صارم على tmpfs ، ويتم استبعادها من ذاكرة التخزين المؤقت للبناء ويمكنها استخدام مصدر بيانات قابل للتكوين. لا توجد علاقات عامة تعرضها في صيغة ملف عامل عامل ولكن يجب أن تكون إضافة بسيطة.

هناك حلان لبناء صور بأسرار.

بناء متعدد المراحل:

FROM ubuntu as intermediate
ARG USERNAME
ARG PASSWORD
RUN git clone https://${USERNAME}:${PASSWORD}@github.com/username/repository.git

FROM ubuntu
# copy the repository form the previous image
COPY --from=intermediate /your-repo /srv/your-repo

ثم: docker build --build-arg USERNAME=username --build-arg PASSWORD=password my-image .

استخدام أداة إنشاء الصور: docker-build-with-secrets

BenoitNorrin آسف ، لكنك كشفت كلمة المرور هذه لكل عملية على النظام المضيف. Unix security 101 - لا تضع الأسرار كوسيطات أوامر.

نعم ولكن هناك بعض الاستخدامات حيث يكون الأمان أقل أهمية:

• تريد البناء على جهاز الكمبيوتر الخاص بك
• تقوم بالبناء على خادم Entreprise CI الخاص بك (مثل jenkins). في معظم الأوقات ، يتعلق الأمر بالوصول إلى مستودع خاص (nexus ، git ، npm ، إلخ) ، لذلك قد يكون لدى CI بيانات اعتمادها الخاصة بذلك.
• يمكنك استخدام جهاز افتراضي تم إنشاؤه من جهاز الإرساء وإزالته بعد ذلك.

إذا كانت هذه هي المشكلة الوحيدة ، binarytemple ، فإن إضافة العلامة docker image build --args-file ./my-secret-file يجب أن يكون حلًا سهلًا جدًا لهذه المشكلة برمتها ، أليس كذلك؟ : التفكير:

yajo يمكن أن يكون كذلك ، نعم إنه حل بديل على الأقل حتى يتم شحن buildkit مع الأسرار. اقتراح جيد. شكرا. ب

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

binarytemple الذي لن يحدث أبدًا ، لقد قتل

أكبر نقطة ألم هي التناوب السري بالنسبة لي

يجب عليك الاحتفاظ برسم بياني لسرية تبعيات الخدمات ، وتحديث مرتين لكل خدمة (للعودة إلى الاسم السري الأصلي)

لا يبدو سرد الأسرار من الخدمات أمرًا سهلاً (لقد استسلمت بعد بعض المحاولات حول docker service inspect --format='{{.Spec.TaskTemplate.ContainerSpec.Secrets}}' <some_service> ) ، وسرد تبعيات الخدمات من docker secret inspect <secret_name> سيكون مفيدًا أيضًا. لذلك أنا فقط أحافظ على الرسم البياني (التقريبي) يدويًا في الوقت الحالي.

يجب عليك أيضًا تحديد الوجهة السرية ، عندما لا تكون هي /run/secrets/<secret_name> الافتراضي في أمر تحديث خدمة عامل الإرساء

أتمنى فقط طريقة أبسط لتدوير الأسرار

caub إليك بعض مساعدة CLI:

تساعد مستندات Docker للتنسيق في الخروج ببقية تنسيق الفحص الخاص بك:

docker service inspect --format='{{range .Spec.TaskTemplate.ContainerSpec.Secrets}}{{println .SecretName}}{{end}}'

سيؤدي ذلك إلى سرد جميع الأسماء السرية في الخدمة. إذا كنت تريد كلاً من الاسم والمعرف ، فيمكنك:

docker service inspect --format='{{range .Spec.TaskTemplate.ContainerSpec.Secrets}}{{println .SecretName .SecretID}}{{end}}' nginx

لدي دائمًا CI / CD (أوامر تحديث الخدمة) أو ملفات مكدسة ترمز المسار حتى لا تواجه هذه المشكلة عند التدوير.

باستخدام الملصقات ، يمكنك جعل أتمتة CI / CD تحدد السر الصحيح إذا كنت لا تستخدم ملفات المكدس (دون الحاجة إلى الاسم السري ، والذي سيكون مختلفًا في كل مرة).

docker build --secret متاح أخيرًا في Docker 18.09 https://medium.com/@tonistiigi/build -secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066

thaJeztah هل نحن مستعدون لإغلاق هذا العدد؟

بالنسبة للإصدارات الأقدم من Docker ، فإن استخدام بناء متعدد المراحل مع نسخ الأسرار قبل أمر البناء هو خيار قابل للتطبيق ، أليس كذلك؟

""
من دبيان كما بناء
COPY ./secret.conf / path / on / image /
تشغيل build.sh
...

من دبيان
نسخ - من = بناء ...

@ andriy-f نعم ، هذا يعمل ، طالما أنك ؛

• (من الواضح) لا تنسخ السر إلى المرحلة النهائية 😉 ، أو:
• استخدم المرحلة / المرحلة build حيث يكون السر موجودًا كـ "الأصل" للصورة النهائية
• أبدا _push_ مرحلة البناء إلى التسجيل
• ثق بالمضيف الذي يعمل عليه البرنامج الخفي ؛ على سبيل المثال ، مع الأخذ في الاعتبار أن مرحلة "البناء" الخاصة بك محفوظة كصورة ؛ سيتمكن أي شخص لديه حق الوصول إلى هذه الصورة من الوصول إلى سرك.

أصبح من الممكن الآن بناء أسرار الوقت عند استخدام buildkit كمنشئ ؛ انظر منشور المدونة هنا https://medium.com/@tonistiigi/build -secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066

والوثائق. https://docs.docker.com/develop/develop-images/build_enhancements/

سيتم ترقية الخيار RUN --mount المستخدم للأسرار إلى صيغة Dockerfile الافتراضية (المستقرة) قريبًا

شكرًا لك thaJeztah ، لقد قمت المنشور السابق الآن). شكرا لك مرة أخرى!

رائع. هذا يغلق سؤال أسرار وقت البناء. أي شيء لوقت التشغيل / devtime (ssh في OS X)؟