पिंग @ewindisch @diogomonica @NathanMcCauley यह सिर्फ एक त्वरित लेखन है। यदि आपको लगता है कि यह आवश्यक है तो विवरण को संशोधित/अपडेट करने के लिए स्वतंत्र महसूस करें :)

यह उपयोगी जानकारी है:

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

जैसा यह है:

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

@ Dreamcat4 एक सामान्य "सीक्रेट एपीआई" को लागू करने की कुछ योजनाएँ हैं, जो आपको डॉकर के साथ वॉल्ट, या कीविज़ या यू-नेम-इट का उपयोग करने की अनुमति देगा, लेकिन सभी एक ही तरह से। यह सिर्फ एक प्रारंभिक विचार है, इसलिए इसके लिए अतिरिक्त शोध की आवश्यकता होगी।

@thaJeztah हाँ क्षमा करें मैं किसी भी तरह से उन प्रयासों/चर्चा से अलग नहीं होना चाहता हूं। मैं और सोच रहा हूं कि शायद यह एक उपयोगी अभ्यास भी है (उस लंबी प्रक्रिया के हिस्से के रूप में और जब हम प्रतीक्षा कर रहे हैं) यह देखने के लिए कि हम अभी कितनी दूर जा सकते हैं। फिर यह दूसरों को वर्तमान प्रक्रिया की सीमाओं और कमियों को अधिक स्पष्ट रूप से दिखाता है। जो अंतर्निहित है वह गायब है और रहस्यों को सुधारने के लिए इसे सबसे अधिक जोड़ने की आवश्यकता है।

रन-टाइम सीक्रेट्स वीएस बिल्ड-टाइम सीक्रेट्स की विभिन्न स्थितियों के बारे में भी विचार करना उचित है। जिसके लिए एक एरिया ओवरलैप एरिया भी है।

और शायद (डॉकर के लिए) हम उन समाधानों के बीच सीमाओं (पेशेवरों/विपक्ष) पर विचार करने के लायक भी हो सकते हैं जो "इन-मेमोरी" रहस्यों को संभालने के लिए एक तंत्र प्रदान करते हैं। अधिक भारी फ़ाइल-आधारित गुप्त विधियों या नेटवर्क आधारित विधियों जैसे स्थानीय गुप्त सर्वर के विपरीत। टेबल पर वर्तमान हैक कौन से हैं (उचित रहस्य एपीआई तक)। यह हमें डॉकर सीक्रेट्स एपीआई द्वारा जोड़े गए कुछ अनूठे मूल्य (उदाहरण के लिए मजबूत सुरक्षा के उदाहरण) को समझने में मदद कर सकता है जो अन्यथा वर्तमान डॉकटर फीचर सेट के शीर्ष पर हैक का उपयोग करके प्राप्त नहीं किया जा सकता है। हालांकि मैं सुरक्षा विशेषज्ञ नहीं हूं। इसलिए मैं वास्तव में उन चीजों पर इतनी निश्चितता के साथ टिप्पणी नहीं कर सकता।

@ Dreamcat4 हाँ, तुम सही हो; अल्पावधि के लिए, वे लिंक वास्तव में उपयोगी हैं।

रन-टाइम सीक्रेट्स वीएस बिल्ड-टाइम सीक्रेट्स की विभिन्न स्थितियों के बारे में भी विचार करना उचित है। जिसके लिए एक एरिया ओवरलैप एरिया भी है।

धन्यवाद! मुझे लगता है कि मेरे पास मेरे मूल विवरण में, इस प्रक्रिया में खो जाना चाहिए था। मैं एक बुलेट जोड़ूंगा

हालांकि मैं सुरक्षा विशेषज्ञ नहीं हूं।

मैं भी नहीं हूं, इसलिए मैंने सुरक्षा अनुरक्षकों को "पिंग" किया; आईएमओ, यह उनके द्वारा लिखा गया कुछ होना चाहिए

@thaJeztah महान सारांश। जब भी मुझे कुछ समय मिलेगा मैं इस पर प्रहार करने की कोशिश करूंगा।

@diogomonica हालांकि _directly_ संबंधित नहीं है, निर्माण के दौरान 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 के माध्यम से लोड करने का विचार पसंद है। ऐसा लगता है कि "बिल्ड कैश में मध्यवर्ती परतें" मुद्दे के बिना स्क्वैशिंग की तरह लगता है।

हालांकि, मैं घबराया हुआ हूं कि यह विकास को जटिल बना देगा और सादगी के लिए तीसरे डॉकरफाइल की आवश्यकता हो सकती है।

@kepkin कोई अपराध नहीं है, लेकिन इसका कोई मतलब नहीं है। रहस्य निश्चित रूप से सुरक्षित नहीं हैं, क्योंकि वे टैरबॉल में हैं और टैरबॉल उत्पादन छवि के लिए ADD एड किया जा रहा है - भले ही आप टैरबॉल को हटा दें, बिना स्क्वैश के, यह किसी परत में लीक हो जाएगा।

@TomasTomecek अगर मैं उदाहरण को सही ढंग से समझता हूं, तो https://github.com/docker-library/hello-world/blob/master/update.sh (यहां कोई रहस्य शामिल नहीं है, लेकिन बिल्ड कंटेनर का सिर्फ एक सरल उदाहरण है)

@TomasTomecek मैं डॉकर छवि बनाने के रहस्यों के बारे में बात कर रहा हूँ। उदाहरण के लिए, आपको अपने निजी गिटहब भंडार से स्रोत कोड चेकआउट करने के लिए एसएसएच कुंजी पास करने की आवश्यकता है। और टैरबॉल में केवल कलाकृतियों का निर्माण होता है लेकिन इसमें गिटहब कुंजी नहीं होती है।

@kepkin ठीक है, अब मैं आपकी पोस्ट को दोबारा पढ़ता हूं और इसे देख सकता हूं। उसके लिए माफ़ करना। दुर्भाग्य से यह समस्या का समाधान नहीं करता है जब आपको वितरण छवि की तैनाती/निर्माण के दौरान रहस्यों की आवश्यकता होती है (उदाहरण के लिए कलाकृतियों को लाना और आर्टिफैक्ट सेवा के साथ प्रमाणीकरण करना)। लेकिन निर्माण प्रक्रिया और रिलीज प्रक्रिया के बीच अलगाव के लिए यह निश्चित रूप से एक अच्छा समाधान है।

@TomasTomecek ठीक इसी तरह मैं वास्तव में कलाकृतियों को प्राप्त करता हूं।

Docker.build छवि में मैं Amazon S3 छवि से कुछ बाइनरी निर्भरता डाउनलोड करता हूं जिसके लिए AWS कुंजी और रहस्य की आवश्यकता होती है। पुनः प्राप्त करने और निर्माण करने के बाद, मैं अपनी जरूरत की हर चीज के साथ एक टैरबॉल बनाता हूं।

क्या कोई विहित "सर्वोत्तम अभ्यास" लेख है - "क्या करें" जैसा कि "क्या न करें" से अवगत कराया गया है - कि आप सभी पढ़ने की सिफारिश करेंगे?

ध्यान देने योग्य (मेरे जैसे किसी और के लिए जो इस पर ठोकर खा रहा है) कि डॉकर कंपोज़ को 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 इस प्रकार मैं docker build ssh-key पास करता हूं:

# 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

और डॉकरफाइल के अंदर जहां 172.17.0.1 डॉकर गेटवे आईपी है:

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

अगर किसी के पास कुछ आसान है तो हमें बताएं।

तो इसकी वर्तमान स्थिति क्या है?

सभी गर्मियों में लंबी बातचीत की श्रृंखलाएं थीं, जो दर्शाती हैं कि यह चिंता कितनी व्यापक है। यह मई में दायर किया गया था, और यह अभी भी खुला है। उदाहरण के लिए, मैं पोस्टग्रेज के लिए पासवर्ड कैसे सेट करूं?

@thaJeztah इसे आगे बढ़ाने के लिए क्या किया जा सकता है? मुझे लगता है कि विभिन्न डाउनस्ट्रीम परियोजनाओं में कई निगाहें इस मुद्दे पर हैं... उदा। https://github.com/rancher/rancher/issues/1269

मुझे लगता है कि यहाँ क्या किया जा रहा है _secret_ :D . रखा गया है

डॉकर को हमारे प्रोडक्शन स्टैक में एकीकृत करने के लिए यह हमारे लिए सबसे बड़ा दर्द बिंदु है। क्या कहीं कोई रोडमैप या कोई अन्य दस्तावेज़ है जो इस दिशा में किसी प्रगति की ओर इशारा करता है?

इस विषय पर k8s से कुछ प्रासंगिक सामग्री।

रन-टाइम रहस्यों को संबोधित करने के संभावित तरीके के रूप में आप इसे क्या सोचते हैं?
https://github.com/docker/docker/issues/19508

मुझे लगता है कि कुछ परिदृश्यों पर ध्यान केंद्रित करके इस मुद्दे को सबसे अच्छा संबोधित किया जाएगा, जिन्हें समर्थित करने की आवश्यकता है, और सुनिश्चित करें कि प्रत्येक के लिए निर्देशों का एक सेट है। उन्हें कैसे लागू किया जाता है, यह इस बात से कम महत्वपूर्ण है कि क्या प्रक्रिया के अंत में सुविधाओं का एक सुसंगत सेट है जिसे आवश्यकता को पूरा करने के लिए जोड़ा जा सकता है।

मैंने जो कुछ देखा है, उनमें से कुछ बहुत ही वैध चिंताओं में शामिल हैं:

रन-टाइम क्रेडेंशियल

• उपयोगकर्ता/पासवर्ड जानकारी दो कंटेनरों के बीच समन्वित होती है जो link
• जानकारी को अपने git रिपॉजिटरी से बाहर रखना आसान है
• आपकी पुश की गई छवियों से जानकारी को बाहर रखना आसान है (स्थानीय कंटेनरों के बारे में क्या?)
• जानकारी को .bash_history से बाहर रखना आसान है (संभवतः एक पुल बहुत दूर है?)
• कुछ एप्लिकेशन कॉन्फ़िगरेशन फ़ाइल के हिस्से के रूप में रहस्यों की अपेक्षा करते हैं जिसमें अन्य जानकारी होती है
• कुछ एप्लिकेशन पर्यावरण चर के रूप में रहस्यों की अपेक्षा करते हैं
• कुछ एप्लिकेशन दोनों की अनुमति देते हैं

जब मैं 'आसान' कहता हूं तो मेरा मतलब है कि इन चरों को संभालने के लिए एक एर्गोनॉमिक रूप से समझदार दृष्टिकोण है जो उपयोगकर्ता को गलती से गलत काम करने और सुरक्षा बुलेटिन को ट्रिगर करने से बचाता है। अनुभव का तनाव अक्सर गलती में शामिल उपकरणों से जुड़ा होता है (पढ़ें: दोष लगाया जाता है)।

बिल्ड-टाइम क्रेडेंशियल्स

• प्रोजेक्ट एक या अधिक निजी रिपॉजिटरी से बनाया गया है (उदा: package.json git urls की अनुमति देता है)
• पासवर्ड से सुरक्षित प्रॉक्सी के पीछे बिल्डर हो सकता है
• हो सकता है कि बिल्डर पासवर्ड से सुरक्षित कैश का इस्तेमाल कर रहा हो
• अंतिम उपयोगकर्ता केवल एक कार्यशील छवि की परवाह करता है (यानी, वे पुल या FROM का उपयोग करेंगे, कभी नहीं docker build )
• आपकी पुश की गई छवियों से जानकारी को बाहर रखना आसान है

पहला संपादित करें:

एक विशिष्ट छवि, कंटेनर में 'लीक' क्या है और क्या नहीं है, इसका दस्तावेज़ीकरण

• छवि में कौन सी फाइलें हवा में आती हैं (बस कॉपी करें और जोड़ें? कुछ और?)
• छवि बनने के बाद डॉकटर-मशीन क्या रखता है (विशेषकर boot2docker, लेकिन दूसरों के बारे में क्या?)
• छवि में पर्यावरण और कमांड लाइन चर कैसे कैप्चर किए जाते हैं, और उन्हें कहाँ कैप्चर किया जाता है
• इन व्यवहारों को बदलने के संबंध में पीआर जारीकर्ताओं से अपेक्षाएं

मुझे ऐसा लग रहा है कि मैं यहाँ कुछ बड़े लोगों को याद कर रहा हूँ। क्या किसी के पास कुछ है जो मैं भूल गया?

जो भी जेसन सेवाओं के लिए एपीआई कुंजी।

उदाहरण के लिए (और यह मेरा वास्तविक उपयोग-मामला है), डॉकर बिल्ड एक प्रोग्राम संकलित करता है, एपीआई कुंजी मुझे प्रमाणित करने और बिल्ड उत्पाद (उत्पादों) को Bintray.com पर अपलोड करने के लिए आवश्यक है।

@ dreamcat4 आप जो कह रहे हैं उससे मैं दूर हो सकता हूं, लेकिन यहां जाता है:

क्या आप निरंतर परिनियोजन बिल्ड के लिए डॉकर छवियों का उपयोग करने और सफल निर्माण के अंत में बिल्ड कलाकृतियों को संग्रह में धकेलने के बारे में बात कर रहे हैं? व्यक्तिगत रूप से मैं इसे आगे की धारा (उदाहरण के लिए, जेनकिंस में एक पोस्ट-बिल्ड स्क्रिप्ट) करना पसंद करता हूं, लेकिन यदि आप क्रॉस कंपाइलिंग कर रहे हैं तो यह थोड़ा मुश्किल हो सकता है।

मेरी दुनिया में बिल्ड एजेंट सिर्फ बायनेरिज़/अभिलेखागार बनाता है और उन्हें निर्माण प्रक्रिया के 'कलाकृतियों' के रूप में रखता है, और कुछ और उन्हें बुनियादी ढांचे में धकेलता है, गिट रिपॉजिटरी को टैग करता है, आदि। यह मुझे कलाकृतियों का एक आपातकालीन बैकअप देता है यदि मैं एक उत्पादन समस्या है और कहें, मेरा एनपीएम, डॉकर, या आर्टिफैक्टरी रिपोजिटरी अपग्रेड के लिए डाउन है, या नेटवर्क मुझ पर गड़बड़ कर रहा है।

मैं जिस बिंदु को बनाने की कोशिश कर रहा था वह सामान्य रूप से एपीआई कुंजियों के उपयोग के बारे में था। कई अलग-अलग और विविध ऑनलाइन JSON / बाकी सेवाएं हैं जिनके साथ एक कंटेनर को इंटरैक्ट करने की आवश्यकता हो सकती है (या तो निर्माण समय या रन टाइम पर) ... जिसके लिए एपीआई कुंजी की आवश्यकता होती है। विशेष रूप से निर्माण से संबंधित होने की आवश्यकता नहीं है।

@dreamcat ओह, आरईएसटी एंडपॉइंट्स के लिए

हाँ, मुझे लगता है कि सुरक्षा के न्यूनतम स्तर के आधार के मूल्यांकन के संदर्भ में उन दो प्रकारों को अलग-अलग माना जाना चाहिए।

एपीआई प्रामाणिक टोकन अक्सर होते हैं:

• पासवर्ड नहीं हैं
• निरस्त किया जा सकता है
• कुछ (बहुत कम उपसमुच्चय) एकल उपयोग हैं - फेंक दें। और अनिवार्य रूप से खुद को अमान्य कर दें।
• अक्सर एपीआई सेवाएं अपने दायरे में केवल कार्यक्षमता के सबसेट तक सीमित होती हैं। (यानी केवल पढ़ने के लिए, या केवल एक विशिष्ट क्रिया को ट्रिगर कर सकता है)।

पासवर्ड अक्सर होते हैं / होते हैं:

• अधिक पूर्ण खाता पहुंच/नियंत्रण के लिए।
• एक बार समझौता करने के बाद, हमलावर द्वारा इसे किसी और चीज़ में बदला जा सकता है (लॉक आउट)। या अन्य पिछले दरवाजे (जैसे डेटाबेस में रखे गए अन्य खातों का डीबी संशोधन, एसक्यूएल के मामले में) डाला गया।
• पासवर्ड होने के कारण अन्य खातों के बीच 'समान पासवर्ड पुन: उपयोग' का काफी अधिक जोखिम होता है। जबकि एपीआई कुंजियाँ हमेशा अद्वितीय होती हैं और किसी अन्य चीज़ के लिए उपयोग करने योग्य नहीं होती हैं।

तो इसका मतलब यह नहीं है कि उन 2 प्रकारों के लिए रहस्य समाधान _अलग होना चाहिए_। एपीआई कुंजी के लिए स्वीकार्य न्यूनतम आधारभूत सुरक्षा स्तर थोड़ा कम हो सकता है।

यह न्यूनतम स्तर मायने रखता है यदि मजबूत सुरक्षा होना सेटअप के लिए अधिक जटिल/समस्याग्रस्त है। (जो डॉकर रहस्यों के मामले में यहां सच हो सकता है, या यह निर्भर नहीं करता कि समाधान कितना व्यवहार्य/सुरुचिपूर्ण है)।

और कभी-कभी पासवर्ड की एपीआई कुंजी में मजबूत/कमजोर सुरक्षा हो सकती है। बस इतना ही कि अगर एक आकार-फिट-सब संभव नहीं है।

उदाहरण के लिए - मेरी बिंट्रे एपीआई कुंजी: जो मेरे डॉकरफाइल के समान .git रेपो में आयोजित की जाती है। तो इसे सुरक्षित रखने के लिए निजी गिट रेपो (एसएसएच के माध्यम से पहुंचा) में आयोजित किया जाता है। इसलिए एपीआई कुंजी तक पहुंच प्राप्त करना अपेक्षाकृत अच्छी तरह से सुरक्षित है। हालाँकि, डॉकटर के पास अपनी स्वयं की कोई अंतर्निहित गुप्त कार्यक्षमता / सुरक्षा नहीं है, निर्मित डॉकर छवि में हमेशा सादे पाठ में एपीआई कुंजी शामिल होती है। इसलिए परिणामी डॉकर बिल्ड इमेज को गिट रिपॉजिटरी की तरह निजी रखा जाना चाहिए ...

अब यह कई मायनों में आदर्श नहीं है। लेकिन समग्र समाधान काफी सरल है और वास्तव में काम करता है (जैसा कि: कल)। यदि भविष्य में कोई बेहतर तंत्र बनाया जाता, तो मैं उस पर स्विच करने पर विचार करता। लेकिन अगर वह तंत्र मेरे द्वारा पहले से बनाए गए मौजूदा समाधान की तुलना में सेटअप के लिए काफी अधिक महंगा/जटिल था। इसलिए केवल 1 एपीआई कुंजी के मामले में अतिरिक्त-मजबूत सुरक्षा (अल्थोग स्वागत) अधिक हो सकती है। जिसे केवल किसी नए NOCAHCE विकल्प / Dockerfile कमांड के साथ docker की इमेज लेयर कैश से बाहर रखने की आवश्यकता है।

जबकि पासवर्ड को वॉल्ट या एन्सिबल-वॉल्ट जैसी किसी चीज़ की आवश्यकता होती है, और इसे अभी तक किसी अन्य-पासवर्ड या अन्य दृढ़ता से सुरक्षित प्रमाणीकरण तंत्र के साथ एन्क्रिप्ट किया जाना चाहिए। (जिसकी हम उम्मीद नहीं करेंगे लेकिन सेटअप करने के लिए एक जटिल चीज हो सकती है)।

मुझे लगता है कि एक क्लाइंट/सर्वर मॉडल (जैसे तिजोरी में ) प्रबंधन और सुव्यवस्थित करने के लिए (पढ़ें: ऑडिटिंग, ब्रेक-ग्लास) सभी रहस्यों से संबंधित सामान अच्छा अभ्यास होगा और अधिकांश उपयोग के मामलों को कवर करेगा, अगर कार्यान्वयन सोच-समझकर किया गया था। मैं, व्यक्तिगत रूप से, गैर-समग्र दृष्टिकोण अपनाने का प्रशंसक नहीं हूं, क्योंकि यह सर्वोत्तम प्रथाओं में बार को ऊपर उठाने का अवसर है।

इसका अर्थ है एक लंबे समय तक चलने वाला क्लाइंट (उस व्यक्ति की जिम्मेदारी जो एक छवि को तैनात करता है) और/या एक बिल्ड-टाइम क्लाइंट (बिल्डर की जिम्मेदारी)। हो सकता है कि पूर्व वाले को किसी तरह डॉकटर डेमॉन में स्थानांतरित किया जा सकता है जो रन टाइम पर अधिकृत रहस्य प्रदान करता है।

दरअसल - मैं पिछली टिप्पणी से तहे दिल से सहमत हूं। ऐसा नहीं है कि मैं रचनात्मक तरीकों की प्रशंसा नहीं करता हूं जिसमें लोग समस्या को हल कर रहे हैं, लेकिन मुझे नहीं लगता कि यह ऐसा ही होना चाहिए - आइए एक समाधान के बारे में सोचें और सोचें जो सीआई/डी और रनटाइम दोनों के दौरान इस्तेमाल किया जा सके , साथ ही इस बात को ध्यान में रखते हुए कि कंटेनरों को मेसोस/कुबेरनेट्स आदि द्वारा व्यवस्थित किया जा सकता है।

खैर, मुझे लगता है कि यहां कुछ दस्तावेज अभी भी उपयोगी होंगे, क्योंकि डॉकर समस्या स्थान में कुछ अतिरिक्त किंक प्रस्तुत करता है।

ऐसा लग रहा है कि शायद तिजोरी वाले भी इसे अपनी तरफ से देख रहे हैं। मुझे लगता है कि यह टिकट देखने वाला है:

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

शायद यह कुछ ऐसा है जिस पर सहयोग किया जा सकता है।

@jdmarshall

शायद यह कुछ ऐसा है जिस पर सहयोग किया जा सकता है।

+1

+1 डॉकर + हाशी कॉर्प वॉल्ट

क्षमा करें, लेकिन मुझे यह पसंद नहीं है कि कैसे समाधान अधिक जटिल होते जा रहे हैं क्योंकि अधिक लोग पिच करते हैं। उदाहरण के लिए हाशी कॉर्प वॉल्ट एन्क्रिप्टेड बैक एंड स्टोरेज के साथ एक पूर्ण क्लाइंट सर्वर समाधान है। यह काफी अधिक चलती भागों को जोड़ता है। मुझे यकीन है कि कुछ उपयोग के मामले इस स्तर की जटिलता की मांग करते हैं लेकिन मुझे संदेह है कि अधिकतर होगा। यदि प्रतिस्पर्धी समाधान मेजबान पर्यावरण चर का उपयोग करना है तो मुझे पूरा यकीन है कि अधिकांश डेवलपर्स द्वारा उपयोग किया जा रहा है।

मैं ऐसे समाधान को देख रहा हूं जिसमें विकास शामिल है (उदाहरण: जीथब कुंजी) और परिनियोजन (उदाहरण: nginx प्रमाणपत्र कुंजी, डीबी प्रमाण-पत्र)। मैं मेजबान को env vars या बिल्ड टूल्स के साथ प्रदूषित नहीं करना चाहता हूं और निश्चित रूप से कोई रहस्य जीथब (अनएन्क्रिप्टेड) ​​​​या एक डॉकर छवि निर्देशिका, यहां तक ​​​​कि एक निजी में भी समाप्त नहीं होना चाहिए।

@gittycat मैं आपके साथ इस अर्थ में सहमत हूं कि शायद कई अलग-अलग उपयोग-मामले हैं। जिससे कुछ समाधान दूसरों की तुलना में सरल होने चाहिए।

हालांकि हमें निश्चित रूप से ईएनवी संस्करणों का सहारा लेने से बचना चाहिए।

मेरी अपनी प्राथमिकता इस विचार की ओर झुक रही है कि सरल कुंजी भंडारण को किसी भी चीज़ के साथ "वॉल्ट" मेसीनिज़्म के समान प्राप्त किया जा सकता है। जहां आपके पास बिल्ड संदर्भ (या निर्माण संदर्भ के बाहर/साथ के स्रोत) के भीतर एक एन्क्रिप्टेड टेक्स्ट फ़ाइल है। फिर एक अनलॉक कुंजी उस फ़ाइल से जो भी प्लेनटेक्स्ट पासवर्ड या एपीआई कुंजी आदि अनलॉक कर सकती है।

मैं सिर्फ इतना कह रहा हूं कि ऐसिबल के अपने "वॉल्ट" समाधान का उपयोग करने के बाद। जो अपेक्षाकृत दर्दरहित/सरल है। हैशिकॉर्प की तिजोरी अधिक सुरक्षित है, लेकिन इसे स्थापित करना भी कठिन है और आमतौर पर अधिक जटिल है। हालांकि मुझे किसी भी तकनीकी कारण के बारे में पता नहीं है कि आप अंततः बैकएंड के रूप में उस नीचे का उपयोग क्यों नहीं कर सके (इसे छुपाएं/डॉकर-उन्मुख कमांडलाइन टूल के पीछे इसे सरल बनाएं)।

मैं स्थानीय फ़ाइल संग्रहण का सुझाव दूंगा क्योंकि यह कुछ जटिल और संभावित रूप से अविश्वसनीय HTTP कुंजी संग्रहण सर्वर को सेटअप करने की आवश्यकता से बचता है। सीक्रेट स्टोरेज बहुत अधिक सुरक्षा का मामला है इसलिए सभी उपयोगकर्ताओं को उपलब्ध होना चाहिए, न कि केवल उद्यमों के लिए। बस मेरी 2 सेंट की राय।

एक स्थानीय फ़ाइल भंडारण बैकएंड के लिए +1, अधिक उन्नत उपयोग के मामलों के लिए, हालांकि मैं एक हाशिकॉर्प वॉल्ट - जैसे समाधान की पूरी शक्ति को प्राथमिकता दूंगा। जब हम किसी संगठन में तैनाती की बात कर रहे हैं, तो तर्क यह है कि जो लोग रहस्य प्रदान करते हैं और उन्हें नियंत्रित करते हैं, वे उन लोगों के अलावा अन्य व्यक्ति हैं जो उनका उपयोग करते हैं। यह बहुत ही भरोसेमंद सुरक्षा इंजीनियरों तक सीमित नियंत्रण शक्ति वाले व्यक्तियों के सर्कल को रखने के लिए एक सामान्य सुरक्षा उपाय है...

पता नहीं है कि यह कोई उपयोग है या काम करेगा, लेकिन यहां मामले को हल करने के लिए एक बाएं क्षेत्र का सुझाव है जहां मैं रनटाइम पर एक कंटेनर में एक रहस्य इंजेक्ट करना चाहता हूं (उदाहरण के लिए एक पोस्टग्रेस पासवर्ड)

अगर मैं प्रवेश बिंदु के समय docker run पर ओवरराइड कर सकता हूं और इसे अपने चयन की एक स्क्रिप्ट पर सेट कर सकता हूं जैसे /sbin/get_secrets, जो मेरे चयन के तंत्र (जैसे केएमएस) से रहस्य प्राप्त करने के बाद, यह मूल प्रवेश बिंदु को निष्पादित करेगा (इस प्रकार एक मात्र आवरण बन गया जिसका एकमात्र उद्देश्य कंटेनर के अंदर रहस्यों के साथ पर्यावरण चर स्थापित करना था। इस तरह की स्क्रिप्ट को वॉल्यूम माउंट के माध्यम से रनटाइम पर आपूर्ति की जा सकती है। इस तरह के तंत्र में डिस्क पर कभी भी लिखे जाने वाले रहस्य शामिल नहीं होंगे ( मेरे पालतू जानवरों में से एक नफरत करता है), या डॉकर द्वारा लीक किया जा रहा है (डॉकर निरीक्षण का हिस्सा नहीं), लेकिन यह सुनिश्चित करेगा कि वे केवल कंटेनर के अंदर प्रक्रिया 1 के वातावरण के अंदर मौजूद हों, जो 12-कारकता रखता है।

आप पहले से ही ऐसा कर सकते हैं (मेरा मानना ​​​​है) यदि छवि मेटाडेटा में एंट्रीपॉइंट का उपयोग नहीं किया जाता है, लेकिन केवल cmd है, एंट्रीपॉइंट के रूप में कमांड को लपेटता है। जैसा कि बताया गया है कि रैपर को रनटाइम पर वॉलमाउंट के माध्यम से रखा जा सकता है। यदि एंट्रीपॉइंट पहले से ही छवि मेटाडेटा में उपयोग किया जाता है, तो मुझे लगता है कि आप इसे वर्तमान में तब तक पूरा नहीं कर सकते जब तक कि यह देखना संभव न हो कि कंटेनर के अंदर से मूल एंट्रीपॉइंट क्या था (cmdline ओवरराइड नहीं) - सुनिश्चित नहीं है कि आप ऐसा कर सकते हैं या नहीं .

अंत में मुझे लगता है कि पारंपरिक env var इंजेक्शन के माध्यम से एक एन्क्रिप्टेड वन-टाइम कुंजी की आपूर्ति करना भी संभव होगा जिसके साथ बाहरी /sbin/get_secrets वास्तविक रहस्यों का अनुरोध करने के लिए उपयोग कर सकता है (उदाहरण के लिए पासवर्ड पोस्ट करता है), इस प्रकार डॉकर में एक अतिरिक्त सुरक्षा जोड़ता है एकमुश्त कुंजी लीक करना।

मैं काम नहीं कर सकता अगर यह सिर्फ परतों पर परतें है, या क्या यह संभावित रूप से इस मुद्दे को हल करता है .. क्षमा करें अगर सिर्फ पहले।

@thaJeztah - मैं उपरोक्त कार्यों के समाधान की पुष्टि कर सकता हूं, रहस्य प्रकट होते हैं w/out

@gtmtech दिलचस्प। इस बात में दिलचस्पी होगी कि आपको कैसे पता चला कि मूल प्रवेश बिंदु आपके प्राप्त रहस्य बाइनरी से क्या था ..

हो सकता है कि एक उदाहरण कोड फ़ोल्डर एप्रोच को प्रदर्शित/समझने में थोड़ा आसान बना देगा।

उदाहरण कोड और कार्य परिदृश्य यहाँ @ Dreamcat4 @kaos >

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

मैं गलत हो सकता हूं, लेकिन ये जटिल तरीके क्यों? मैं मानक यूनिक्स फ़ाइल अनुमतियों पर भरोसा करता हूं। केवल रूट द्वारा पठनीय -v /etc/secrets/docker1:/etc/secrets साथ सभी रहस्यों को डॉकर को सौंपें और फिर कंटेनर स्टार्टअप पर रूट के रूप में एक स्क्रिप्ट चल रही है, जो प्रासंगिक कार्यक्रमों के लिए उपयुक्त स्थानों पर रहस्यों को पास करती है (उदाहरण के लिए अपाचे कॉन्फ़िगरेशन)। ये प्रोग्राम स्टार्टअप पर रूट अनुमतियों को छोड़ देते हैं, इसलिए यदि हैक किया जाता है, तो वे बाद में रूट-स्वामित्व वाले रहस्य को नहीं पढ़ सकते हैं। क्या मैं जिस विधि का उपयोग करता हूं वह किसी तरह त्रुटिपूर्ण है?

धन्यवाद @gtmtech :)
दुर्भाग्य से, हमारे पास कोई मानक प्रवेश बिंदु नहीं है, न ही मैं डॉकर निरीक्षण को नियंत्रित तरीके से चलाने से पहले चलाने में सक्षम हूं .. लेकिन मुझे आपका दृष्टिकोण पसंद है।

मैं गलत हो सकता हूं, लेकिन ये जटिल तरीके क्यों? मैं मानक यूनिक्स फ़ाइल अनुमतियों पर भरोसा करता हूं। -v /etc/secrets/docker1:/etc/secrets को केवल रूट द्वारा पठनीय के साथ docker को सभी रहस्यों को सौंपें और फिर कंटेनर स्टार्टअप पर रूट के रूप में एक स्क्रिप्ट चल रही है, जो प्रासंगिक कार्यक्रमों के लिए उपयुक्त स्थानों पर रहस्यों को पास करती है (उदाहरण के लिए apache कॉन्फिग)। ये प्रोग्राम स्टार्टअप पर रूट अनुमतियों को छोड़ देते हैं, इसलिए यदि हैक किया जाता है, तो वे बाद में रूट-स्वामित्व वाले रहस्य को नहीं पढ़ सकते हैं। क्या मैं जिस विधि का उपयोग करता हूं वह किसी तरह त्रुटिपूर्ण है?

नमस्ते,
मैं सहमत हूं और सोचता हूं कि इस दृष्टिकोण ^^ को आम तौर पर रनटाइम रहस्यों के लिए सर्वोत्तम तरीके के रूप में अनुशंसित किया जाना चाहिए। जब तक कि यहां किसी और को इसके खिलाफ कड़ी आपत्ति न हो। जिसके बाद बाद में किसी भी शेष कोने के मामलों (RUNTIME पर) को भी सूचीबद्ध किया जा सकता है जो उस ^^ द्वारा कवर नहीं किए जाते हैं।

दुर्भाग्य से मैं गुप्त गिलहरी को उड़ान भरते नहीं देख सकता क्योंकि अधिकांश नियमित गैर-तकनीकी व्यक्तियों के लिए इसे सीखना और कुछ लोकप्रिय रणनीति के रूप में अपनाना बहुत जटिल है।

तो फिर वह निकल जाता है (आप शायद पहले ही अनुमान लगा चुके हैं) ...
बिल्ड-टाइम सीक्रेट्स!

लेकिन मुझे लगता है कि यह एक प्रगति है! चूंकि लंबे समय के बाद वास्तव में कहीं नहीं मिल रहा है, शायद चीजों को आधा कर देता है और कुल समस्या का लगभग 45-50% हल करता है।

और यदि रहस्यों के इर्द-गिर्द अभी भी समस्याएं शेष हैं, तो कम से कम वे अधिक विशिष्ट / केंद्रित होंगी और बाद में आगे बढ़ती / उठा सकती हैं।

हां, मैं बहुत अधिक विवरण में नहीं जाऊंगा, लेकिन ये दृष्टिकोण उस स्थिति के लिए कभी काम नहीं करेंगे, जिसके साथ मैं वर्तमान में काम कर रहा हूं, क्योंकि मुझे उनके द्वारा प्रदान की जाने वाली सुरक्षा के उच्च स्तर की आवश्यकता है। उदाहरण के लिए डिस्क पर अनएन्क्रिप्टेड कोई रहस्य नहीं, लक्ष्य प्रक्रिया में डिक्रिप्ट होने के बाद कोई वैध डिक्रिप्शन कुंजी नहीं, नियमित एन्क्रिप्शन रोटेशन, और एन्क्रिप्टेड रहस्यों के लिए एकल भंडार (और सर्वरों में फैला नहीं)। तो यह उन लोगों के लिए अधिक है जिन्हें सुरक्षा के उस स्तर पर करना है कि मैंने एक संभावित दृष्टिकोण का सुझाव दिया है।

secret_squirrel वैसे भी एक ऐसी जगह में एक हैक है जहां मुझे अभी तक कोई व्यवहार्य समाधान नहीं दिख रहा है, डॉकर के आसपास अभी तक एक रहस्य एपीआई, या एक प्लग करने योग्य रहस्य-चालक प्रदान नहीं कर रहा है, जो उम्मीद है कि वे किसी बिंदु पर होंगे, लेकिन शायद यह उस सेटिंग को स्पष्ट करने के लिए कार्य करता है ईएनवी प्रक्रिया निष्पादन से पहले कंटेनर के अंदर vars, लेकिन डॉकर बनाने की प्रक्रिया (या मेटाडेटा) के हिस्से के रूप में नहीं, रहस्यों के साथ 12-कारक अनुपालन होने का एक सुरक्षित तरीका है, और शायद डॉकर विकास समुदाय उस विचार का उपयोग कर सकता है जब वे एक निर्माण शुरू करते हैं रहस्य-एपीआई/चालक अगर उन्हें लगता है कि यह एक अच्छा है!

हैप्पी डॉकिंग!

हम उस तरह के दृष्टिकोण का उपयोग कर रहे हैं जिसका वर्णन @gtmtech ने बड़ी सफलता के साथ किया है। हम पर्यावरण चर के माध्यम से केएमएस-एन्क्रिप्टेड रहस्यों को इंजेक्ट करते हैं, फिर कंटेनर के अंदर कोड को आवश्यकतानुसार डिक्रिप्ट करते हैं।

आम तौर पर जिसमें आवेदन के सामने एक साधारण शिम एंट्रीपॉइंट शामिल होता है। वर्तमान में हम उस शिम को शेल और एक छोटे गोलंग बाइनरी (https://github.com/realestate-com-au/shush) के संयोजन के साथ लागू कर रहे हैं, लेकिन मुझे प्योर-गो दृष्टिकोण की आवाज़ पसंद है।

@gtmtech @mdub मुझे निश्चित रूप से इसे और अधिक देखकर प्रसन्नता होगी।
@ Dreamcat4 मुझे लगता है कि "जटिल" की परिभाषा पथ पर निर्भर हो सकती है, जो स्पष्ट रूप से ठीक है। फिर भी, यह शायद एक अमूर्त निर्णय नहीं हो सकता। इसलिए, हालांकि, डॉकर कंटेनर के भीतर एक सुरक्षा रैपर डिजाइन स्तर पर मेरे लिए कुछ जटिल नहीं लगता है। एक अन्य पहलू सर्वोत्तम अभ्यास है: उन्हें केवल एक डेवलपर के दृष्टिकोण से नहीं बल्कि एक ऑपरेशन के नजरिए से देखा जाना चाहिए।
मेरे 2 सेंट

तिजोरी +1

तिजोरी -1। वॉल्ट में कुछ परिचालन विशेषताएं (अनसीलिंग) हैं जो इसे बहुत से लोगों के लिए वास्तव में अवांछनीय बनाती हैं।

प्लग करने योग्य एपीआई होने से सबसे ज्यादा फायदा होगा।

अंसिबल की तिजोरी भी है। बल्कि एक अलग जानवर है।

@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, जुआन इग्नासियो डोनोसो नोटिफिकेशन @github.com . पर
लिखा था:

अगर मैं सही ढंग से समझता हूं, तो /var/secrets dir को माउंट किया जाना चाहिए
वॉल्यूम सही ??
साथ ही, जब डिस्क पर रहस्य नहीं लिखे जाने के बारे में टिप्पणी होती है, तो कैसे
बुरा है उन्हें डिस्क पर लिखना और फिर उन्हें हटाना ???

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/docker/docker/issues/13490#issuecomment -191887424।

रुई मारिनहो

@gtmtech की "सीक्रेट-गिलहरी" से प्रेरित होकर, मैंने अपने सीक्रेट-मैनेजमेंट टूल "शश" को एक इमेज एंट्री-पॉइंट के रूप में प्रयोग करने योग्य बनाने के लिए बढ़ाया है:

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

यह किसी भी KMS_ENCRYPTED_xxx envariables को डिक्रिप्ट करता है, और परिणामों को वापस पर्यावरण में इंजेक्ट करता है।

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

तो सूत्र की शुरुआत इस बात से होती है कि इनमें से कोई भी काम न करें.....

... लेकिन मुझे इसके बजाय कृपया ये चीजें नहीं दिख रही हैं ... केवल विभिन्न प्रस्ताव/हैक जिन्हें ज्यादातर खारिज/बंद कर दिया गया है।

अभी के लिए आधिकारिक सर्वोत्तम अभ्यास क्या है? एक डॉकटर उपयोगकर्ता के रूप में उन चीजों की एक लंबी सूची को देखकर कुछ निराशा होती है जो हमें नहीं करनी चाहिए लेकिन फिर कोई आधिकारिक विकल्प पेश नहीं किया जाता है। क्या मैं कुछ भूल रहा हूँ? क्या कोई मौजूद नहीं है? मुझे यकीन है कि चीजें पर्दे के पीछे हो रही हैं और यह कुछ ऐसा है जिस पर डॉकर टीम काम कर रही है, लेकिन अभी के रूप में, जब तक एक विहित समाधान प्रस्तुत नहीं किया जाता है, तब तक हम गुप्त प्रबंधन को कैसे बेहतर तरीके से संभाल सकते हैं?

@alexkolson
जहां तक ​​मुझे समझ में आया, अगर आपको रनटाइम में सीक्रेट्स की जरूरत है, तो आपको या तो वॉल्यूम (फाइल सिस्टम सीक्रेट्स) या कुछ सेवाओं जैसे हाशिकॉर्प वॉल्ट (नेटवर्क सीक्रेट्स) का उपयोग करना चाहिए।

बिल्ड-टाइम सीक्रेट्स के लिए, यह अधिक जटिल है।
बिल्ड समय पर वॉल्यूम समर्थित नहीं हैं, इसलिए आपको फाइल सिस्टम को संशोधित करने वाले कमांड को निष्पादित करने के लिए कंटेनरों का उपयोग करना चाहिए, और डॉकर कमिट का उपयोग करना चाहिए।

तो क्या गायब है docker commit का उपयोग करने की आवश्यकता के बिना, डॉकरफाइल को छोड़कर कुछ भी नहीं का उपयोग करके बिल्ड समय पर रहस्यों को प्रबंधित करने की क्षमता है।

कुछ लोग यह भी कहते हैं कि रहस्यों के लिए फाइल सिस्टम का उपयोग करना सुरक्षित नहीं है, और डॉकर डेमॉन को सुरक्षित रूप से रहस्य प्रदान करने के लिए कुछ एपीआई प्रदान करनी चाहिए (नेटवर्क/फ़ायरवॉल/ऑटोमाउंट वॉल्यूम का उपयोग करके?) लेकिन किसी को इस बात का अंदाजा भी नहीं है कि यह एपीआई कैसा दिखेगा और इसका इस्तेमाल कैसे किया जाएगा।

जब मैं env vars की कमियों के बारे में सोचता हूं, तो मैं गैर-डॉकर विशिष्ट मुद्दों के बारे में सोचता हूं जैसे:

1. उत्पादन वेब सर्वर पर छोड़े गए सभी env vars या भूले हुए phpinfo को पकड़ने वाले लॉग एकत्र करना - इसलिए रहस्यों से सावधान रहें और सही तरीके से कॉन्फ़िगर करें।
2. शायद एक ट्रोजन जो env vars को उजागर करता है - इसलिए अविश्वसनीय सॉफ़्टवेयर न चलाएं।
3. हमले जो कमजोरी का फायदा उठाते हैं जैसे कि sql इंजेक्शन - इसलिए इनपुट को मान्य करें और वेब ऐप फ़ायरवॉल का उपयोग करें।

इस धागे के शीर्ष पर प्रस्तुत कमजोरियां:

कंटेनर में किसी भी प्रक्रिया द्वारा पहुँचा जा सकता है, इस प्रकार आसानी से "लीक" हो जाता है

ऊपर से 1 और 2 का क्रॉस अप्लाई करें। कानूनी लेकिन सावधान रहने के साथ संबोधित किया है ना? साथ ही, आपका डॉकटर कंटेनर पूर्ण स्टैक वेब सर्वर की तुलना में बहुत कम प्रक्रियाओं को चलाता है।

Env var में config के बारे में क्या है, लेकिन गुप्त env var में एन्क्रिप्टेड मान हैं और ऐप में कोड की कुंजी है? यह सिर्फ अस्पष्टता है, क्योंकि कुंजी कोड में है, लेकिन कुंजी और एनवी वर्र्स दोनों तक पहुंच प्राप्त करने के लिए शोषण की आवश्यकता होगी। शायद ऐप कोड के बजाय डॉकर होस्ट पर कुंजी प्रबंधित करने के लिए कॉन्फ़िगरेशन प्रबंधन का उपयोग करें। रूज प्रक्रियाओं और आकस्मिक लीक के साथ मदद कर सकता है लेकिन स्पष्ट रूप से किसी ऐसे व्यक्ति से इंजेक्शन के हमले नहीं जिसके पास चाबी है।

छवि की मध्यवर्ती परतों में संरक्षित, और डॉकटर निरीक्षण में दिखाई देता है

क्या लोग रन टाइम पर सेट करने के बजाय docker इमेज में env vars बेक कर रहे हैं या क्या मैं इसे गलत समझ रहा हूं। कलाकृतियों में रहस्य कभी वापस न करें, है ना? हाँ sudo docker inspect container_name env var देता है, लेकिन यदि आप मेरे उत्पादन सर्वर पर हैं तो iv पहले ही खो गया है। sudo docker inspect image_name पास रन टाइम पर सेट मेरे एनवी वर्र्स तक पहुंच नहीं है।

कंटेनर से जुड़े किसी भी कंटेनर के साथ साझा किया गया

इसके बजाय लिंक और नई नेटवर्किंग का उपयोग कैसे न करें?

एकमात्र मुद्दा जो डॉकर मुद्दे की तरह लगता है और सार्वभौमिक नहीं है वह लिंक है ...

मुझे उन लोगों के शिविर में रखें जिन्हें docker build दौरान रहस्यों को संभालने का एक अच्छा तरीका चाहिए। हम कुछ PHP परियोजनाओं के लिए संगीतकार का उपयोग करते हैं और निर्भरताओं के लिए कुछ निजी जीथब रेपो का संदर्भ देते हैं। इसका मतलब है कि अगर हम सब कुछ कंटेनरों के अंदर बनाना चाहते हैं तो इन निजी रेपो तक पहुंचने के लिए ssh कुंजियों की आवश्यकता होती है।

मुझे कुछ अन्य चीजों को पराजित किए बिना इस स्थिति को संभालने का एक अच्छा और समझदार तरीका नहीं मिला है जो मुझे डॉकर के बारे में फायदेमंद लगता है (देखें: docker squash )।

मुझे अब कंटेनर के बाहर एप्लिकेशन के कुछ हिस्सों को बनाने और कंटेनर में अंतिम उत्पाद लाने के लिए COPY का उपयोग करने में पीछे हटना पड़ा है। मेह।

मुझे लगता है कि docker build को रहस्य जैसे क्षणिक डेटा को संभालने के लिए कुछ कार्यक्षमता की आवश्यकता है ताकि वे अंतिम शिपिंग कंटेनर में अपना रास्ता न खोज सकें।

मुझे लगता है कि गुप्त डेटा जैसे क्षणिक डेटा को संभालने के लिए डॉकर बिल्ड को कुछ कार्यक्षमता की आवश्यकता होती है

यह एक दार्शनिक नहीं बल्कि एक तकनीकी समस्या है। इस तरह के क्षणिक डेटा डॉकर के आवश्यक लाभ को हरा देंगे: प्रतिलिपि प्रस्तुत करने योग्यता।

डॉकर का दर्शन यह है कि एक संदर्भ के साथ आपका डॉकरफाइल एक छवि बनाने के लिए पर्याप्त है।
यदि आपको परिणामी छवि के बाहर होने के लिए एक संदर्भ की आवश्यकता है, तो आपको इसे नेटवर्क से लाना चाहिए और फाइल सिस्टम पर लिखना छोड़ देना चाहिए। क्योंकि प्रत्येक डॉकरफाइल लाइन का परिणाम फाइल सिस्टम स्नैपशॉट में होता है।

यदि रहस्य एक छवि का हिस्सा नहीं होना चाहिए, तो आप एक अल्पकालिक कंटेनर चला सकते हैं, जो आपके सभी गुप्त-संरक्षित संसाधनों को प्रतिबिंबित/प्रॉक्सी करेगा और गुप्त-कम पहुंच प्रदान करेगा। मिररिंग, बीटीडब्ल्यू का एक और तर्क है: https://developers.slashdot.org/story/16/03/23/0652204/how-one-dev-broke-node-and-thousands-of-projects-in-11-lines -की-जावास्क्रिप्ट

आप स्वयं भी ssh कुंजी साझा कर सकते हैं, लेकिन आप इसके उपयोग को नियंत्रित नहीं कर पाएंगे।

@ bhamilton-idexx यदि आप सुनिश्चित करते हैं कि आपके निजी रिपॉजिटरी का प्रमाणीकरण अल्पकालिक टोकन के साथ काम करता है, तो आपको डॉकर छवि में बने रहने के रहस्य के बारे में चिंता करने की ज़रूरत नहीं है।
आपके पास बिल्ड सिस्टम 1 घंटे के टीटीएल के साथ एक टोकन उत्पन्न करता है, इसे डॉकर बिल्ड के लिए पर्यावरण चर के रूप में उपलब्ध कराएं।
आप बिल्ड आवश्यक बिल्ड विवरण प्राप्त कर सकते हैं, लेकिन आपके बिल्ड पूर्ण होने के तुरंत बाद गुप्त समय समाप्त हो जाता है, उस हमले वेक्टर को बंद कर देता है।

अब इन थ्रेड्स का एक गुच्छा पढ़ रहे हैं और एक विशेषता जो यहां कुछ उपयोगकेस को हल करेगी और रहस्यों के बाहर उपयोगकेस होगी --add docker run लिए ध्वज जो एक फ़ाइल को कंटेनर में कॉपी करता है, जैसे Dockerfiles में ADD स्टेटमेंट

यह लेख ए+ http://elasticcompute.io/2016/01/21/runtime-secrets-with-docker-containers/ है

यह वाकई एक बेहतरीन लेख है। बहुत अच्छा पढ़ा। और ठीक उसी तरह की चीज जिसे हम देखने की उम्मीद कर रहे हैं।

बीटीडब्ल्यू:

इसके अलावा कुछ अन्य गुप्त उपकरण भी मिले जो ऐसा लगता है कि लेख से छूट गए हैं। किसी भी दोहराव/दोहराव के लिए क्षमा करें। ध्यान नहीं दिया कि उनका उल्लेख यहाँ अभी तक किया गया है:

समय रहस्य बनाएँ:

https://github.com/defunctzonbie/docket

रन टाइम सीक्रेट्स:

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

लोग क्या सोचते हैं? बहुत धन्यवाद।

मेरे लिए:

ये नए उपकरण ^^ अब बहुत अच्छे लग रहे हैं। और वे निश्चित रूप से मौजूद नहीं थे जब हमने पहली बार यह टिकट शुरू किया था। लेकिन मुख्य बात जो मुझे अब महसूस हो रही है, वह अभी भी सबसे ज्यादा याद आ रही है:

DockerHub पर बिल्ड-टाइम सीक्रेट्स के लिए बेहतर क्षमता होना। जो वहां गरीब है और एक या एक विकल्प को मजबूर करता है। हमें एक समाधान के लाभों को दूसरे के लाभों के लिए छोड़ देना चाहिए। इस पर निर्भर करता है कि कौन-सी विशेषता (सुविधाओं) का समग्र सेट अधिक महत्वपूर्ण है। चूंकि स्थानीय भवन निश्चित रूप से रहस्यों को सुरक्षित रखने के लिए बेहतर है, लेकिन अन्य तरीकों से डॉकरहब से भी बदतर है।

हमने डॉकेट के समान एक और टूल लिखा है, जो नए इमेज फॉर्मेट का उपयोग करता है:

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

हमारा कार्यान्वयन पहले SECRETS टिप्पणी किए गए रहस्यों वाली एक परत बनाता है, फिर एक संशोधित FROM साथ Dockerfile की एक प्रति बनाता है, बनाता है और अंत में परिणामी छवि से सभी SECRETS परतों को हटा देता है।

इसे हैक करने के लिए हमेशा चेतावनी दी जाती है, और यह प्रफुल्लित होगा यदि डॉकटर के पास रिबासिंग या लेयर स्प्लिसिंग फंक्शनलिटी बिलिन हो। अभी मध्यवर्ती परतों को हटाना धीमा है, क्योंकि सभी समाधानों को पर्दे के पीछे docker save / docker load नृत्य करना होता है।

इसके अलावा बिल्ड कैशिंग टूटा हुआ है। अभी, हम टिप्पणी की गई गुप्त परत बनाने के लिए docker commit का उपयोग करते हैं, लेकिन इन परतों का उचित कैश रखना अभी भी काम का एक समूह है, जिसे करने की संभावना नहीं है। सीक्रेट लेयर बनाने के लिए डॉकरफाइल का उपयोग करने से यह हल हो सकता है, लेकिन लेयर पर टिप्पणी करने का कोई साधन नहीं है, जिससे यह तय करना मुश्किल हो जाता है कि बाद में क्या हटाना है।

@ वानुआन [डॉकरफाइल] में पुनरुत्पादन नहीं हो सकता है। रन कमांड गारंटी देता है कि आप और मैं दो रनों में से एक ही छवि प्राप्त करने की उचित उम्मीद नहीं कर सकते। क्यों? क्योंकि अधिकांश समय लोग RUN का उपयोग नेटवर्क संसाधनों तक पहुँचने के लिए करते हैं। यदि आप मेरे जैसी ही छवि चाहते हैं तो आपको अपनी 'FROM' मेरी छवि बनानी होगी। कोई अन्य व्यवस्था हमें समान चित्र नहीं देगी। कोई अन्य व्यवस्था हमें समान चित्र नहीं दे सकती है । सभी टिकाऊ प्रतिलिपि प्रस्तुत करने योग्यता डॉकर हब से आती है, डॉकरफाइल से नहीं।

यदि हमारे पास क्षणिक डेटा क्यों नहीं हो सकता है, इसका एकमात्र बचाव यह है कि डॉकर को लगता है कि वे सभी अल्पकालिक डेटा को हटा सकते हैं, तो आपको RUN निर्देश को हटाना होगा।

@stephank मैंने काम पर एक डॉकटर बिल्ड टूल लागू किया है जो थोड़ा अलग तरीका अपनाता है। मेरी मुख्य चिंता समय के रहस्यों को बनाने के लिए नहीं थी, लेकिन यह इसका भी ख्याल रखता है (रहस्यों को निर्मित छवि से बाहर रखना, यानी, आप पहली जगह में रहस्यों को कैसे पकड़ते हैं, यह अभी भी आप पर निर्भर है)।

और वह है एक वॉल्यूम में प्रोजेक्ट कोड के साथ "बिल्ड मैनेजर" चलाकर। प्रबंधक तब अलग-अलग कंटेनरों में किसी भी संख्या में बिल्ड टूल चलाता है जो प्रबंधक से वॉल्यूम का उपयोग करके प्रोजेक्ट कोड को माउंट करता है। तो किसी भी निर्मित कलाकृतियों और अन्य उत्पादित फाइलों को प्रबंधक मात्रा में रखा जाता है और प्रत्येक बिल्ड चरण के लिए बिल्ड पाइपलाइन के साथ चलता है। अंत में, प्रबंधक उत्पादित बिल्ड परिणाम का उपयोग करके अंतिम उत्पादन छवि बना सकता है। रास्ते में आवश्यक कोई भी रहस्य प्रबंधक और/या बिल्ड कंटेनरों में उपलब्ध है, लेकिन अंतिम छवि नहीं है। कोई डॉकर छवि विज़ार्ड का उपयोग नहीं किया गया है, और कैश का निर्माण अपेक्षित रूप से काम करता है।

बिल्ड पाइपलाइन कैसी दिखती है, बिल्ड आवश्यकताओं को कॉन्फ़िगर करने वाली एक विशिष्ट फ़ाइल का उपयोग करके पूरी तरह से प्रोजेक्ट पर निर्भर है।

तथ्य की बात के रूप में, मैं इस उपकरण के बारे में काफी उत्साहित हूं, मैं इसे ओपन सोर्स के रूप में जारी करने में सक्षम होने की प्रतीक्षा कर रहा हूं (लंबित कंपनी नीति दिशानिर्देशों को अपनाया जाना है) ..

@kaos एक तरफ, मैं स्टॉक डॉकर टूलिंग से विचलित नहीं होना चाहता था। दूसरी ओर, मुझे लगता है कि छवि निर्माण उपकरणों के बीच वास्तव में कुछ और प्रतिस्पर्धा होनी चाहिए। तो यह दिलचस्प लगता है! मैं

पर्यावरण (12-कारक) रहस्यों के लिए @thaJeztah , हम निरीक्षण के माध्यम से पर्यावरण चर के रिसाव को रोकने के लिए ट्विस्टलॉक (+ स्कैलॉक) के माध्यम से डॉकर डिमन को लॉक कर रहे हैं। यह बहुत अच्छा होगा यदि हमारे पास इसे और अधिक उचित वास्तविकता बनाने के लिए निरीक्षण के माध्यम से अधिक विशेषाधिकार प्राप्त जानकारी को लीक न करने की डॉकर-मूल क्षमता हो।

@alexkolson मुझे लगता है कि इस धागे की कुंजी "ऐसा न करें" है जब तक कि आपने एक्स, वाई, जेड को कम नहीं किया है। यह स्पष्ट रूप से एक इंजीनियरिंग थैड है - आम समस्याओं के लिए हमेशा "समाधान" होंगे। उस ने कहा, क्या नहीं करना है और क्यों महत्वपूर्ण है, इस पर शिक्षा ताकि वास्तविक समाधान शुरू हो सके। डेविल हमेशा चूक में रहता है - इसलिए हमें यह सुनिश्चित करने की आवश्यकता है कि नए उपयोगकर्ता समझें कि जोखिम क्या है।

हो सकता है कि आप में से कुछ लोग मेरी मदद कर सकें क्योंकि मुझे अभी तक डॉकटर के साथ इतना अनुभव नहीं है।
मैंने अपने रहस्यों को लाने के लिए एक हाशिकॉर्प्स वॉल्ट का इस्तेमाल किया।

मैंने मूल रूप से एक टोकन को बिल्ड तर्क के रूप में पारित किया था और टोकन का उपयोग वॉल्ट से संवेदनशील जानकारी प्राप्त करने के लिए किया जा सकता है। यह निर्मित समय पर होता है और केवल तभी सफल हो सकता है जब वॉल्ट "अनसील्ड" (डेटा लाने के लिए खुला) स्थिति हो। उपयोग किए गए टोकन के निर्माण के बाद निरस्त कर दिया गया है।

लेकिन मुझे लगता है कि मुझे अभी भी कुछ सामान्य मुद्दों का सामना करना पड़ रहा है।

• संवेदनशील डेटा में परिवर्तन होने पर मुझे नई छवियां बनानी होंगी
• अगर मेरी छवि चोरी / हैक हो गई है तो संवेदनशील डेटा छवि के भीतर है।

डॉकर निरीक्षण के साथ प्रयुक्त टोकन ढूंढना संभव है लेकिन इसका अब और उपयोग नहीं किया जा सकता है।
मैंने हैशिकॉर्प्स वॉल्ट को सील और अनसील करने का विकल्प केवल निर्माण समय पर बनाया ताकि सीक्रेट स्टोर पर जितना संभव हो सके पहुंच को सीमित किया जा सके। मैंने रनटाइम पर डेटा लाते समय सीक्रेट सेव रखने का विकल्प भी नहीं देखा।

तो मैंने यह कितना बुरा किया (यह कहना ठीक है कि अगर मैंने बड़ा समय गड़बड़ कर दिया;)) क्या किसी के पास चीजों को और अधिक सुरक्षित बनाने के लिए मेरे लिए टिप्स और ट्रिक्स हैं?

@weemen AFAIK आपकी छवि में रहस्य संग्रहीत करना भी एक अच्छा विचार नहीं है। आपकी छवि में कोई भी क्रेडेंशियल बेक नहीं होना चाहिए (वॉल्ट टोकन सहित)। इसके बजाय, लोड समय पर रहस्य प्राप्त करने के लिए अपने कंटेनरों के लिए वॉल्ट के ऐप-आईडी प्रमाणीकरण बैकएंड का उपयोग करें। आप जिस ऐप स्टैक का उपयोग कर रहे हैं, उसके आधार पर उन्हें किसी भी तरह कंटेनर की मेमोरी में स्टोर करें।

साथ ही, वॉल्ट एक एडब्ल्यूएस ऑथ बैकएंड पर काम कर रहा है जो भविष्य में उपयोगी होगा यदि आप क्लाउड प्रदाता के रूप में एडब्ल्यूएस का उपयोग कर रहे हैं।

@ jaredm4 क्या आप कृपया इस कथन को स्पष्ट कर सकते हैं ?:

"इसके बजाय, लोड समय पर रहस्य प्राप्त करने के लिए अपने कंटेनरों के लिए वॉल्ट के ऐप-आईडी ऑथ बैकएंड का उपयोग करें। आपके द्वारा उपयोग किए जा रहे ऐप स्टैक के आधार पर उन्हें किसी भी तरह कंटेनर की मेमोरी में स्टोर करें।"

मैं अभी तक स्पष्ट नहीं हूं कि वॉल्ट (या कीविज, आदि) से रहस्यों को कब/कहां पुनर्प्राप्त किया जाए। क्या यह डॉकर चलाने से पहले किया जाता है और रन कमांड को पास किया जाता है? क्या यह कंटेनर आरंभीकरण के दौरान किसी बिंदु पर हो रहा है (यदि हां, तो कोई उदाहरण)? क्या मेरे आवेदन को आवश्यकता पड़ने पर इन्हें पुनः प्राप्त करना चाहिए? उदाहरण के लिए, मेरे रेल ऐप को Google API कुंजियों की आवश्यकता है, क्या चाबियों की आवश्यकता होने पर मैं वॉल्ट पर कॉल करने के लिए रेल के अंदर कुछ लिखता हूं?

मुझे लगता है कि मैं वॉल्ट जैसी किसी चीज़ का उपयोग करने की आवश्यकता पर स्पष्ट हूं, और इसे कॉन्फ़िगर करने के तरीके के बारे में स्पष्ट हूं, मैं सेवा का उपभोग करने के तरीके पर स्पष्ट नहीं हूं और रेल बूट होने पर मेरी वाईएमएल फाइलों को अद्यतन करने के लिए तैयार हूं।

यहां किसी भी मार्गदर्शन की सराहना की जाएगी। धन्यवाद

ज़रूर @mcmatthew , हालाँकि मुझे यह कहकर प्रस्तावना देनी चाहिए कि मैं अभी भी वॉल्ट में

जिस तरह से मैं इसे कोड करने का प्रयास कर रहा हूं, वह यह है कि आपके द्वारा कंटेनर को पास की जाने वाली एकमात्र जानकारी आपके कोड को वॉल्ट के साथ प्रमाणित करने में सक्षम होने के लिए आवश्यक है। यदि आप ऐप-आईडी बैकएंड का उपयोग कर रहे हैं, तो वह स्वयं app-id और आपके वॉल्ट का पता होगा।

कंटेनर बूट पर, आपका रेल ऐप नोटिस करेगा कि इसमें अभी तक कोई रहस्य नहीं है, और उन्हें वॉल्ट से लाना होगा। इसमें app-id प्रदान किया गया है, और इसे किसी भी तरह से user-id उत्पन्न करने की आवश्यकता होगी। इस उपयोगकर्ता-आईडी पीढ़ी को आपके द्वारा निर्धारित करने की आवश्यकता होगी, लेकिन उनके दस्तावेज़ीकरण संकेत देते हैं कि "यह आम तौर पर एक मशीन के लिए अद्वितीय मूल्य है, जैसे मैक पता या इंस्टेंस आईडी, या इन अद्वितीय मानों से हैश किया गया मान।"

एक बार आपके रेल ऐप में ऐप-आईडी और उपयोगकर्ता-आईडी तैयार हो जाने के बाद, यह वॉल्ट के एपीआई का उपयोग/लॉगिन करने के लिए कर सकता है। वहां से आप अपने आवश्यक रहस्य प्राप्त करने के लिए एपीआई कॉल कर सकते हैं।

अब यह स्पष्ट करने के लिए कि स्मृति में उन्हें संग्रहीत करने के बारे में मेरा क्या मतलब है - यह आपके द्वारा उपयोग किए जा रहे ऐप के प्रकार के आधार पर भिन्न होता है, लेकिन रेल के साथ आपके रहस्यों को उपयोगकर्तालैंड परिवर्तनीय कैश में संग्रहीत करने का एक तरीका होना चाहिए जो रेल को एक्सेस करने की अनुमति देगा स्मृति से रहस्य हर अनुरोध को तिजोरी से बार-बार प्राप्त करने के बजाय (जैसा कि आप कल्पना कर सकते हैं कि यह धीमा होगा)। रेल में कैशिंग के बारे में यह मार्गदर्शिका देखें । अर्थात्, खंड 2.0, लेकिन यह सुनिश्चित करना कि यह मेमोरी_कैश का उपयोग कर रहा है न कि डिस्क का।

अंत में, सुनिश्चित करें कि हालांकि आप इसे कोड करते हैं, कि आप इसे रेल में करते हैं और विशेष डॉकर एंट्रीपॉइंट स्क्रिप्ट या इसी तरह के साथ नहीं। रेल को स्मृति में रहस्यों का पता लगाना चाहिए, और यदि मौजूद नहीं है, तो उन्हें प्राप्त करें।

मुझे आशा है कि वह मदद करेंगे। मुझे पता है, थोड़ा उच्च स्तर, लेकिन इस तरह से हमने इससे निपटने की योजना बनाई है।

यह स्पष्ट नहीं है कि क्या गुप्त रखा जाना चाहिए, ऐप-आईडी, उपयोगकर्ता-आईडी या दोनों।

ठीक है, दोनों का उत्तर है https://www.vaultproject.io/docs/auth/app-id.html
लेकिन यह अभी भी स्पष्ट नहीं है कि यह केवल सादे फायरवॉल एक्सेस से अधिक सुरक्षित क्यों है।
शायद यह है कि प्रत्येक मेजबान रहस्य को एप्लिकेशन (नीति) रहस्य से जोड़ा जाना चाहिए?
यानी यदि आपके पास होस्ट के रहस्य तक पहुंच है तो आप कुछ एप्लिकेशन तक पहुंच पाएंगे यदि आप उनके गुप्त नाम जानते हैं?

अब हमें कहीं 2 टोकन स्टोर करने की आवश्यकता है?

@ वानुआन उन दोनों को यथासंभव गुप्त रखा जाना चाहिए, हाँ।

ऐप-आईडी का मुख्य उद्देश्य नीतियों के माध्यम से वॉल्ट के अंदर कुछ रहस्यों तक पहुंच को प्रतिबंधित करना है। जिस किसी के पास ऐप-आईडी तक पहुंच है, वह उस ऐप-आईडी की नीतियों के रहस्यों तक पहुंच प्राप्त कर लेता है। ऐप-आईडी आपकी परिनियोजन रणनीति द्वारा प्रदान की जानी चाहिए। उदाहरण के लिए, यदि शेफ का उपयोग कर रहे हैं, तो आप इसे पैरामीटर बैग (या OpsWorks के लिए CustomJSON) में सेट कर सकते हैं। हालांकि, अपने आप, यह किसी को भी Vault तक पहुंचने की अनुमति नहीं देगा। तो शेफ तक पहुंच प्राप्त करने वाला कोई व्यक्ति तब वॉल्ट तक नहीं पहुंच पाएगा।

उपयोगकर्ता-आईडी शेफ द्वारा प्रदान नहीं किया गया है, और विशिष्ट मशीनों से जुड़ा होना चाहिए। यदि आपके ऐप को सभी उदाहरणों में अनावश्यक रूप से बढ़ाया गया है, तो प्रत्येक इंस्टेंस का अपना उपयोगकर्ता-आईडी होना चाहिए। यह वास्तव में कोई फर्क नहीं पड़ता कि यह उपयोगकर्ता-आईडी कहां से उत्पन्न होता है (हालांकि वे सुझाव देते हैं), लेकिन यह उसी स्थान से नहीं आना चाहिए जिसने ऐप-आईडी (यानी, शेफ) को तैनात किया था। जैसा कि उन्होंने कहा, इसे अन्य माध्यमों से ही लिपिबद्ध किया जा सकता है। इंस्टेंस को स्केल करने के लिए आप जिस भी सॉफ़्टवेयर का उपयोग करते हैं, वह इंस्टेंस/डॉकर कंटेनरों को उपयोगकर्ता-आईडी की आपूर्ति कर सकता है और उपयोगकर्ता-आईडी को ऐप-आईडी को अधिकृत कर सकता है। यह हाथ से भी किया जा सकता है यदि आप अपने उदाहरणों को गतिशील रूप से नहीं मापते हैं। हर बार जब कोई मानव एक नया उदाहरण जोड़ता है, तो वे एक नया उपयोगकर्ता-आईडी बनाते हैं, इसे ऐप-आईडी के लिए अधिकृत करते हैं, और जो भी माध्यम उन्हें सबसे अच्छा लगता है, उसे इंस्टेंस पर आपूर्ति करते हैं।

क्या यह फायरवॉल इंस्टेंस से बेहतर है? मान लीजिए कि निर्भर करता है। फ़ायरवॉलिंग वॉल्ट (afaik) में रहस्यों तक पहुंच को प्रतिबंधित नहीं करता है, और अगर किसी ने आपके उदाहरणों तक पहुंच प्राप्त की है, तो वे आसानी से आपके वॉल्ट में प्रवेश कर सकते हैं।

इस तरह, उनके लिए पहेली के सभी टुकड़े प्राप्त करना कठिन है। इसे एक कदम आगे ले जाने के लिए, ऐप-आईडी सीआईडीआर ब्लॉकों की भी अनुमति देता है जिनका आपको उपयोग करना चाहिए। अगर किसी को किसी तरह ऐप-आईडी और यूजर-आईडी मिल गई, तो भी वे उस नेटवर्क पर न होकर वॉल्ट तक नहीं पहुंच सके।

(फिर से, यह मेरी व्याख्या है जो मैं कर सकता था प्रलेखन को टटोलने के बाद)

@Vanuan @mcmatthew बढ़िया सवाल! @ jaredm4 वास्तव में इस स्पष्टीकरण के लिए धन्यवाद, यह निश्चित रूप से मेरी मदद करेगा। यह उन सभी के लिए बहुत उपयोगी है जो अधिक व्यावहारिक कार्यान्वयन की तलाश में हैं !! अगर मेरे पास आने वाले दो सप्ताहों में कुछ समय है तो मैं फिर से कोशिश करूँगा!

@thaJeztah :

कंटेनर में किसी भी प्रक्रिया द्वारा पहुँचा जा सकता है, इस प्रकार आसानी से "लीक" हो जाता है

क्या आप इस दावे का समर्थन कर सकते हैं? गैर-विशेषाधिकार प्राप्त प्रक्रियाएं गैर-अभिभावक प्रक्रियाओं के पर्यावरण चर तक नहीं पहुंच सकती हैं। https://help.ubuntu.com/community/EnvironmentVariables#Process_locality देखें

कंटेनर के लिए निर्धारित पर्यावरण चर ( --env या --env-file ) _are_ कंटेनर में किसी भी प्रक्रिया द्वारा पहुँचा जा सकता है।

बेशक, चूंकि वे प्रवेश बिंदु प्रक्रिया के बच्चे हैं। यह उस प्रक्रिया का काम है, या आप के मामले में यह एक खोल है, जितनी जल्दी हो सके गुप्त पर्यावरण चर को अनसेट करने के लिए।

जो अधिक प्रासंगिक है वह यह है कि क्या 0 के अलावा किसी अन्य उपयोगकर्ता आईडी वाली प्रक्रियाएं कंटेनर के अंदर और/या बाहर इन पर्यावरण चरों तक पहुंच सकती हैं। ऐसा भी नहीं होना चाहिए, जब आपके द्वारा कंटेनर के अंदर उपयोग किया जाने वाला सॉफ़्टवेयर विशेषाधिकारों को ठीक से छोड़ देता है।

मुझे पता है कि यह विषय से हटकर है, लेकिन क्या किसी और ने देखा है कि यह मुद्दा अब लगभग पूरे एक साल से सक्रिय है! कल इसकी बरसी है। मैं

क्या कंटेनर प्रक्रिया के लिए प्रक्रिया मेमोरी में env चर को पढ़ना और फिर उन्हें (पर्यावरण में) अन-सेट करना संभव होगा? क्या यह अधिकांश रन-टाइम सुरक्षा चिंताओं को ठीक करता है?

@davibe के साथ समस्या यह है कि यदि कंटेनर या इसकी प्रक्रिया (तों) को पुनरारंभ करता है, तो वे env var चले जाते हैं, उन्हें पुनर्प्राप्त करने का कोई तरीका नहीं होता है।

मैंने कोशिश की लेकिन ऐसा लगता है कि 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

हो सकता है कि डॉकर-रन मेरी बात को बैश के बच्चे के रूप में निष्पादित कर रहा हो? मुझे लगता है कि ऐसा नहीं होना चाहिए..

@डेविबे :

unset 'SECRET_ENV_VAR'

मुझे लगता है कि इस सब में मुख्य समस्या/विशेषता यह है कि आप डॉकर में root रूप में लॉग इन करते हैं, इस प्रकार आप कंटेनर के अंदर जो कुछ भी डालते हैं उसका निरीक्षण किया जा सकता है, चाहे वह टोकन हो, वॉल्यूम हो, एक चर हो, एक एन्क्रिप्शन कुंजी हो। .. कुछ भी।

तो एक विचार यह होगा कि आप अपने कंटेनर से sudo और su को हटा दें और किसी भी ENTRYPOINT या CMD से पहले USER कमांड जोड़ें। आपके कंटेनर को चलाने वाले किसी भी व्यक्ति को अब root रूप में चलाने का कोई मौका नहीं मिलना चाहिए (यदि मैं गलत नहीं हूं) और इस प्रकार अब आप वास्तव में उससे कुछ छुपा सकते हैं।

एक अन्य विचार (सर्वश्रेष्ठ IMHO) उपयोगकर्ताओं और समूहों की धारणा को डॉकर सॉकेट और कंटेनरों में जोड़ना होगा, ताकि आप बता सकें कि GROUP-A के पास TAG-B वाले कंटेनरों तक पहुंच है, और USER-C GROUP- से संबंधित है- ए तो उन कंटेनरों तक इसकी पहुंच है। यह प्रति ऑपरेशन की अनुमति भी हो सकती है (ग्रुप-ए के पास टैग-बी के लिए प्रारंभ/स्टॉप तक पहुंच है, ग्रुप-बी के पास निष्पादन तक पहुंच है, ग्रुप-सी के पास आरएम/निरीक्षण तक पहुंच है, और इसी तरह)।

कुछ घंटों के लिए इस पर शोध करने के बाद, मुझे विश्वास नहीं हो रहा है कि बिल्ड-टाइम सीक्रेट्स के लिए कोई आधिकारिक तौर पर अनुशंसित समाधान या समाधान नहीं है, और https://github.com/dockito/vault जैसा कुछ एकमात्र व्यवहार्य विकल्प प्रतीत होता है बिल्ड-टाइम सीक्रेट्स (पूरी परिणामी छवि को कुचलने या इसे पहले स्थान पर मैन्युअल रूप से बनाने की कमी)। दुर्भाग्य से https://github.com/dockito/vault ssh कुंजियों के लिए काफी विशिष्ट है, इसलिए मैं इसे git https क्रेडेंशियल स्टोर फ़ाइलों की मेजबानी के लिए भी अनुकूलित करने का प्रयास करने के लिए जाता हूं ...

हमेशा के लिए जैसा लगता है (मूल रूप से मैंने सुना है कि यह Q4 2015 रिलीज के लिए स्लेट किया गया था) के बाद, एडब्ल्यूएस ईसीएस अंततः आईएएम भूमिकाओं को डॉकर ऐप्स में लाने के अपने वादे पर आ गया है। यहां ब्लॉग पोस्ट भी है।

ऐसा लगता है कि कुछ केएमएस अच्छाई के साथ यह एक व्यवहार्य निकट अवधि समाधान है। सिद्धांत रूप में आपको केवल कुछ प्रधानाचार्यों/IAM भूमिकाओं से जुड़े रहस्यों को बनाना होगा ताकि गैर-प्रामाणिक भूमिकाओं को कुछ ऐसा पूछने से रोका जा सके जो उन्हें नहीं करना चाहिए और KMS को सुरक्षित भंडारण छोड़ना चाहिए।

अभी तक कोशिश नहीं की है, लेकिन यह मेरी छोटी सूची में है ...

ऐसा लगता है कि कुबेरनेट्स के पास कुछ रहस्य भी हैं जो मुझे बहुत सारे शेफ एन्क्रिप्टेड डेटाबैग की याद दिलाते हैं।

मैं समझता हूं कि यह प्लेटफॉर्म-इंडिपेंडेंट ओएसएस तरीका नहीं है जो इस धागे का पूरा बिंदु है,
लेकिन उन दो विकल्पों को उन बुनियादी ढांचे वाले स्थानों में खेलने वाले लोगों के लिए फेंकना चाहता था जिन्हें कुछ चाहिए _NOW_

मुझे बस कुछ ऐसा मिला जो इस संबंध में मदद कर सकता है: https://github.com/docker/docker/pull/13587

ऐसा लगता है कि यह docker v1.10.0 से शुरू होकर उपलब्ध है, लेकिन मैंने अब तक इस पर ध्यान नहीं दिया था। मुझे लगता है कि इस बिंदु पर मैं जिस समाधान की ओर झुक रहा हूं, वह https://www.vaultproject.io/ का उपयोग रहस्यों को संग्रहीत करने और पुनर्प्राप्त करने के लिए कर रहा है, उन्हें कंटेनर के अंदर एक tmpfs फ़ाइल सिस्टम में /secrets या उस प्रकृति के कुछ पर रखा गया है। . कंटेनरों पर IAM भूमिकाओं को सक्षम करने वाली नई ECS सुविधा के साथ, मेरा मानना ​​है कि मुझे स्वयं रहस्यों के लिए प्राधिकरण को सुरक्षित करने के लिए वॉल्ट के AWS EC2 प्रमाणन का उपयोग करने में सक्षम होना चाहिए। (प्लेटफॉर्म स्वतंत्र के लिए मैं उनके ऐप आईडी प्रमाणीकरण के साथ जाने के इच्छुक हो सकता हूं।)

किसी भी मामले में, मेरे लिए लापता टुकड़ा वह था जहां एक बार उन्हें पुनः प्राप्त करने के बाद रहस्यों को सुरक्षित रूप से रखा जाए। Tmpfs विकल्प मुझे अच्छा लगता है। केवल एक चीज गायब है कि ईसीएस अभी तक इस पैरामीटर का समर्थन नहीं करता है, इसलिए मैंने इसे आज सबमिट किया है: https://github.com/aws/amazon-ecs-agent/issues/469

सब एक साथ जो एक बहुत व्यापक समाधान IMHO की तरह लगता है।

@CameronGo , सूचक के लिए धन्यवाद। अगर मैं सही ढंग से समझूं तो इसका उपयोग बिल्ड फाइन में नहीं किया जा सकता है, या यह कर सकता है?

@NikolausDemmel क्षमा करें हाँ, आप सही हैं। यह केवल रन टाइम सीक्रेट्स का समाधान है, बिल्ड टाइम नहीं। हमारे वातावरण में, बिल्ड टाइम सीक्रेट्स का उपयोग केवल Git से कोड प्राप्त करने के लिए किया जाता है। जेनकिंस इसे हमारे लिए संभालता है और गिट एक्सेस के लिए क्रेडेंशियल्स को स्टोर करता है। मुझे यकीन नहीं है कि एक ही समाधान यहां सभी की जरूरतों को पूरा करता है, लेकिन मैं समय के रहस्यों के निर्माण के लिए अन्य उपयोग मामलों पर अस्पष्ट हूं।

जेनकिंस इसे हमारे लिए संभालता है और गिट एक्सेस के लिए क्रेडेंशियल्स को स्टोर करता है।

यह डॉकर के साथ कैसे काम करता है? या आप कंटेनर के अंदर ही git clone ?

इस मुद्दे को पूरी तरह से पढ़ने के बाद, मेरा मानना ​​है कि "बिल्ड-टाइम" और "रन-टाइम" रहस्यों के लिए अलग-अलग मुद्दों में विभाजित होने से इसे बहुत फायदा होगा, जिनकी बहुत अलग आवश्यकताएं हैं

यदि आप मेरे जैसे हैं और आप यह तय करने के लिए यहां आते हैं कि अभी क्या करना है, तो एफडब्ल्यूआईडब्ल्यू मैं उस समाधान का वर्णन करूंगा जिस पर मैंने समझौता किया था, जब तक कि कुछ बेहतर न हो जाए।

रन-टाइम सीक्रेट्स के लिए मैंने http://kubernetes.io/docs/user-guide/secrets/ का उपयोग करने का निर्णय लिया

बिल्ड-टाइम रहस्यों के संबंध में - मैं निजी कोड वितरित करने के अलावा अन्य बिल्ड-टाइम रहस्यों के उपयोग के मामले के बारे में नहीं सोच सकता। इस बिंदु पर, मुझे मेजबान पक्ष पर कुछ भी "गुप्त" करने पर भरोसा करने और जेनरेट किए गए पैकेज/जार/व्हील/रेपो/आदि को जोड़ने से बेहतर समाधान नहीं दिख रहा है। छवि को। मेजबान पक्ष पर पैकेज उत्पन्न करने वाले एक एलओसी को सहेजना एसएसएच कुंजी या प्रॉक्सी सर्वर चलाने की जटिलता को उजागर करने के लायक नहीं है जैसा कि कुछ टिप्पणियों में सुझाया गया है।

हो सकता है कि डॉकर बिल्ड में "-v" ध्वज जोड़ना, डॉकर रन ध्वज के समान अच्छा काम कर सकता है? यह अस्थायी रूप से मेजबान और छवि के बीच एक निर्देशिका साझा करेगा, लेकिन यह भी सुनिश्चित करेगा कि यह कैश में या उत्पन्न छवि में खाली दिखाई दे।

मैं वर्तमान में वॉल्ट का उपयोग करके समाधान पर काम कर रहा हूं:

1. बिल्डर मशीन में वॉल्ट स्थापित है और स्थानीय स्तर पर एक टोकन सहेजा गया है
2. जब बिल्ड शुरू होता है, तो बिल्डर मशीन एक नए अस्थायी टोकन का अनुरोध करती है जो केवल मिनटों के लिए मान्य होता है (बिल्ड के आधार पर, 1h भी स्वीकार्य होगा)
3. टोकन को बिल्ड arg . के रूप में इंजेक्ट करता है
4. डॉकर छवि में वॉल्ट भी स्थापित है (या निर्माण के दौरान इसे स्थापित और हटा देता है) और इस टोकन का उपयोग करके यह वास्तविक रहस्यों को प्राप्त कर सकता है

यह महत्वपूर्ण है कि रहस्यों को उसी कमांड के भीतर हटा दिया जाए, इसलिए जब डॉकर दी गई परत को कैश करता है तो कोई बचा नहीं होता है। (यह निश्चित रूप से केवल समय रहस्य बनाने के लिए लागू होता है)

मैंने इसे अभी तक नहीं बनाया है, लेकिन इस पर काम कर रहा हूं।

कुछ हद तक @kozikow की टिप्पणी से संबंधित: "बिल्ड-टाइम सीक्रेट्स के बारे में - मैं निजी कोड को वितरित करने के अलावा अन्य बिल्ड-टाइम सीक्रेट्स के उपयोग के मामले के बारे में नहीं सोच सकता।"

हो सकता है कि विशेष रूप से बिल्ड टाइम सीक्रेट न हो, लेकिन मेरे पास पहले से निर्मित आर्टिफैक्ट को रन कर्ल कमांड के माध्यम से डाउनलोड करने की अनुमति देने के लिए डॉकरफाइल में बिल्ड-टाइम के दौरान पासवर्ड (सुरक्षित) के लिए उपयोग-केस की आवश्यकता है। बिल्ड-टाइम डाउनलोड को आर्टिफैक्ट को हथियाने के लिए प्रमाणित करने के लिए उपयोगकर्ता क्रेडेंशियल्स की आवश्यकता होती है - इसलिए हम अभी डॉकरफाइल में एक पर्यावरण चर के रूप में पासवर्ड पास करते हैं (हम अभी भी देव में हैं)। बिल्ड स्वचालित रूप से पर्दे के पीछे हो रहे हैं, क्योंकि हम OpenShift का उपयोग करते हैं, और Dockerfile में पर्यावरण चर बिल्ड के दौरान लॉग के लिए आउटपुट होते हैं, जैसे कोई docker बिल्ड कमांड। यह पासवर्ड को हमारे डेवलपर्स सहित किसी भी व्यक्ति के लिए दृश्यमान बनाता है जिसके पास लॉग तक पहुंच है। मैं पासवर्ड भेजने का एक तरीका निकालने की सख्त कोशिश कर रहा हूं ताकि इसका उपयोग डॉकटर बिल्ड के दौरान किया जा सके, लेकिन फिर लॉग करने या किसी भी परत में समाप्त होने के लिए पासवर्ड आउटपुट नहीं है।

मैं यह भी कहता हूं कि

मुझे लगता है कि जो कुछ भी (रनटाइम) गुप्त तंत्र किसी के साथ आया है, उसके लिए कुछ परीक्षणों को परिभाषित करना सार्थक हो सकता है। क्योंकि इस धागे पर बहुत सारे लोग हैं जो बहुत कमजोर सुरक्षा की वकालत कर रहे हैं।

एक शुरुआत के रूप में मैं सुझाव देता हूं:

• डोकर निरीक्षण में रहस्य प्रकट नहीं होता है
• प्रक्रिया 1 शुरू होने के बाद, कंटेनर से पहुंच योग्य किसी भी फाइल के भीतर रहस्य उपलब्ध नहीं है (वॉल्यूम माउंटेड फाइलों सहित)
• रहस्य /proc/1/cmdline में उपलब्ध नहीं है
• गुप्त को एन्क्रिप्टेड रूप में कंटेनर में प्रेषित किया जाता है

ऊपर सुझाया गया कोई भी समाधान जो इनमें से किसी एक का उल्लंघन करता है वह समस्याग्रस्त है।

यदि हम एक परिभाषा पर सहमत हो सकते हैं कि एक रहस्य को किस व्यवहार का पालन करना चाहिए, तो कम से कम वह अंतहीन समाधान निकाल देगा जो उद्देश्य के लिए उपयुक्त नहीं हैं।

@gtmtech बढ़िया सुझाव :)

प्रक्रिया 1 शुरू होने के बाद, कंटेनर से पहुंच योग्य किसी भी फाइल के भीतर रहस्य उपलब्ध नहीं है (वॉल्यूम माउंटेड फाइलों सहित)

मुझे यकीन नहीं है कि मैं इससे सहमत हूं। जबकि मैं सहमत हूं कि यह केवल कंटेनर से पहुंच योग्य होना चाहिए (आदर्श रूप से स्मृति में) ऐसे कई मामले हैं जहां किसी एप्लिकेशन को "प्रारंभ" करने के लिए समय चाहिए और इसके नीचे से फ़ाइलों को हटाया नहीं जाना चाहिए। मुझे लगता है कि कंटेनर चलाने की अवधि के लिए स्मृति में कुछ (स्टॉप पर हटा दिया गया) थोड़ा बेहतर तरीका है।

मैं रन-टाइम आवश्यकताओं की सूची में जोड़ूंगा:

• पहला रहस्य बूटस्ट्रैप करते समय कंटेनर प्रमाणीकरण/प्राधिकरण।

उदाहरण के लिए, Vault, AppRole बैकएंड के साथ प्राधिकरण प्रदान करता है, लेकिन यह इस बारे में खुला है कि कंटेनर खुद को कैसे पहचानते हैं।

निक सुलिवन ने कुछ हफ्ते पहले क्लॉफ्लेयर की पीएएल परियोजना पर

एक आवेदन के दृष्टिकोण से इससे निपटने के तीन तरीके हैं:

1. एक पर्यावरण चर से एक रहस्य प्राप्त करें।
2. एक फ़ाइल से एक रहस्य प्राप्त करें।
3. किसी अन्य प्रणाली से एक रहस्य प्राप्त करें।

ऊपर 1 और # 2 आम तौर पर सबसे आम हैं क्योंकि अधिकांश अनुप्रयोग इस तंत्र का समर्थन करते हैं। #3 शायद अधिक आदर्श है क्योंकि यह कम से कम "crumbs" छोड़ता है, लेकिन इसके लिए एप्लिकेशन को विशेष रूप से विकसित किया जाना है और रहस्य प्राप्त करने के लिए अक्सर अभी भी एक प्रमाण पत्र होना चाहिए।

डॉकर बहुमुखी प्रतिभा के बारे में है और विभिन्न प्रकार के उपयोग के मामलों का समर्थन करता है। इस आधार पर 1. और 2. एप्लिकेशन के दृष्टिकोण से सबसे आकर्षक हैं, इस तथ्य के बावजूद कि वे दोनों सिस्टम पर "crumbs" छोड़ देते हैं।

एक सामान्य दृष्टिकोण जिसका मैं निश्चित रूप से उपयोग करता हूं, वह है एंट्रीपॉइंट स्क्रिप्ट के माध्यम से रहस्यों को इंजेक्ट करना (उदाहरण के लिए एडब्ल्यूएस में क्रेडस्टैश या प्लेन केएमएस जैसे टूल का उपयोग करें और आईएएम भूमिकाओं के साथ संयोजन करें)। इस संबंध में आप वास्तव में एंट्रीपॉइंट स्क्रिप्ट में # 3 ऊपर करते हैं, और या तो # 1 (एक पर्यावरण चर सेट करें) या # 2 (फ़ाइल में लिखें) करते हैं। यह दृष्टिकोण गतिशील है और # 1 (पर्यावरण चर) के लिए, डॉकर लॉग या डॉकर निरीक्षण में प्रमाण-पत्रों को उजागर नहीं करता है।

प्रवेश बिंदु दृष्टिकोण के बारे में अच्छी बात यह है कि आप गुप्त प्रबंधन की चिंताओं को आवेदन से अलग कर रहे हैं।

यह एक ऐसा क्षेत्र है जहां डॉकर अपनी खुद की एंट्रीपॉइंट स्क्रिप्ट को रोल करने से बचने के लिए कार्यक्षमता जोड़ सकता है। डॉकर प्लगइन्स से प्यार करता है और कंटेनर जीवनचक्र में एक हुक प्रदान कर सकता है जहां यह "रहस्य" प्रदाता प्लगइन्स का समर्थन कर सकता है, जो अनिवार्य रूप से एक मैनुअल एंट्रीपॉइंट स्क्रिप्ट का कार्य करता है और कंटेनर में रहस्यों को इंजेक्ट करता है (आंतरिक पर्यावरण चर या फ़ाइल के माध्यम से)। तो आपके पास एक हाशिकॉर्प वॉल्ट रहस्य प्रदाता, एक एडब्ल्यूएस केएमएस रहस्य प्रदाता इत्यादि हो सकता है। डॉकर शायद आरएसए एन्क्रिप्शन (डिजिटल कर्ट के माध्यम से) का उपयोग करके इसका अपना प्रदाता हो सकता है। यह पूरी अवधारणा रहस्य की कुबेरनेट्स अवधारणा के समान है, जो कंटेनर फाइल सिस्टम पर रहस्य प्रस्तुत करती है।

बेशक, आप रहस्य प्रदाता तक पहुंच को कैसे अधिकृत करते हैं, इसकी जटिलता है, जो कि आज आप जिस समस्या का सामना कर रहे हैं, उसकी परवाह किए बिना। हाशिकॉर्प के साथ आप ऑथ के लिए एक बार/समय-सीमित टोकन जारी कर सकते हैं और पास कर सकते हैं, एडब्ल्यूएस के साथ यह आईएएम भूमिकाएं हैं, डॉकर आरएसए एन्क्रिप्शन दृष्टिकोण के साथ मैंने उल्लेख किया है, यह केवल डॉकर इंजन सार्वजनिक प्रमाणपत्र का उपयोग करके एन्क्रिप्ट किए गए रहस्यों को पारित कर सकता है।

यह धागा महान है। मुझे आशा है कि हम इस तरह के और धागे देखेंगे जहां समुदाय और सभी क्षेत्रों के लोग अपने अनुभव, विचार और समाधान साझा करने में सक्षम हैं।

"गुप्त शून्य" मुद्दा एक मुश्किल है। बिल्ड-टाइम या रन-टाइम? दोनों के अपने पेशेवरों और विपक्ष हैं, और स्पष्ट सुरक्षा उपाय और खामियां हैं (और हैक्स और आसपास काम करते हैं!)।

उस ने कहा, मैं इस बारे में बहुत सोच रहा हूं कि पास/कुंजी का प्रबंधन कैसे आवेदन और/या सेवा पर आता है।

आने वाले महीनों में हम जिस चीज पर काम करेंगे, वह है कुंजी/मूल्य जोड़े के माध्यम से एक साझा, वैश्विक कॉन्फ़िगरेशन बैकिंग सेवा का निर्माण करना, जिसे कॉन्सल द्वारा वितरित किया गया और एक पर्यावरण चर के रूप में उपलब्ध कराया गया (या यदि पर्यावरण चर का उपयोग समर्थित नहीं है तो इंजेक्शन)। यह केवल आपके असुरक्षित मूल्यों का समर्थन करता है। सुरक्षित के लिए, हम वॉल्ट में जाएंगे और इसे एक बैकिंग सेवा की तरह व्यवहार करेंगे - बिल्कुल डेटाबेस या किसी अन्य निर्भरता की तरह।

कोड, कॉन्फिग और सीक्रेट्स बैकिंग सर्विस (सेवाओं) के माध्यम से प्रदान किए जाएंगे। इस मामले में, हम Stash, Consul और Vault का उपयोग करते हैं। जब तक निर्भरता ऊपर है, तब तक आवश्यकतानुसार कॉन्फ़िगरेशन और रहस्यों को खींचने की क्षमता है।

मैंने इसे कहीं भी ठोस समाधान के रूप में नहीं देखा है, इसलिए मैं इसके बारे में यहां पोस्ट कर रहा हूं। लेकिन इसे इस धागे के उद्देश्य पर वापस लाने के लिए, यह एक दृष्टिकोण है जिसे हम प्रयोग करने जा रहे हैं ताकि डॉकर/गुप्त मुद्दे को हल किया जा सके। हम उन अनुप्रयोगों का निर्माण करेंगे जो उनके आसपास के ढांचे और प्लेटफार्मों पर भरोसा करने के बजाय मूल रूप से इसका समर्थन करते हैं, जिसमें वे चलते हैं।

बिल्ड-टाइम रहस्यों के संबंध में, रॉकर का MOUNT निर्देश क्षणिक निर्देशिका और फाइलें बनाने के लिए उपयोगी साबित हुआ है जो _only_ बिल्ड-टाइम पर मौजूद हैं। उनकी कुछ टेम्पलेट विशेषताएँ भी इस स्थिति में मदद कर सकती हैं, लेकिन मैंने अभी तक उनका पूरी तरह से उपयोग नहीं किया है।

मुझे डॉकर कोर में एक बिल्डर प्लगइन के रूप में कार्यान्वित इस कार्यक्षमता को देखना अच्छा लगेगा (साथ ही साथ रॉकरफाइल्स में कुछ अन्य उपयोगी विशेषताएं हैं)!

मुझे लगता है कि ओपी में वर्तमान में सभी 4 प्रस्ताव गुप्त भंडारण के बारे में हैं

मैं कहूंगा कि डॉकर्स को एक गुप्त/पासवर्ड को _docker instance_ पास करने की सुविधा प्रदान करनी चाहिए, लेकिन इन रहस्यों को संग्रहीत/प्रबंधन करना (और होना चाहिए) डॉकर के दायरे से बाहर है।

जब _एक गुप्त_ पास करना_ मैं कहूंगा कि एक रन पैरामीटर लगभग सही है सिवाय इसके कि यह आमतौर पर लॉग होता है। तो मैं इसे एक गैर-सादे टेक्स्ट पैरामीटर सुविधा तक सीमित कर

जहां तक ​​_रहस्यों को प्रबंधित करने का सवाल है, मैं कुछ भी कहूंगा जो उपयोगकर्ता चाहता है, होमब्रे बैश स्क्रिप्ट से लेकर कुबेरनेट्स जैसे सॉफ़्टवेयर द्वारा एकीकरण तक।

रॉकर माउंट जैसे @ agilgur5 ने पहले टिप्पणी की थी? मुझे विश्वास नहीं हो रहा है कि यह बहस इतनी लंबी चली है कि एक टीम को वास्तव में आसान उपयोग के मामले को संतुष्ट करने के लिए docker build कमांड को प्रभावी ढंग से फोर्क करना पड़ा है। क्या हमें मिश्रण में एक और HTTP सर्वर की आवश्यकता है? चुम्मा।

मैंने इस सबजेट के आसपास इतने घंटे बिताए ...

अभी के लिए, बिल्ड चरण के दौरान मुझे रहस्यों को प्रबंधित करने का सबसे अच्छा तरीका दो चरणों के भीतर बनाना है, इसलिए दो डॉकर फाइलें। यहाँ एक अच्छा उदाहरण है ।

[आदत] (http://www.habitus.io/) एक और विकल्प प्रतीत होता है, लेकिन मेरे मामले में, मैं मुख्य रूप से एक और उपकरण नहीं जोड़ना चाहता क्योंकि मैं सीआई सर्वर पर और उपयोगकर्ता के कंप्यूटर पर निर्माण प्रक्रिया को रखना चाहता हूं सरल / समान।

और डॉकर-इन-डॉकर (डीएनडी) तरीके के बारे में क्या?

यहां दो चरणों का एक उदाहरण डिंड के साथ बनाया गया है जैसे मैंने अभी ऊपर बात की है: 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 के बारे में, मैं थोड़ा निराशावादी हूं जब मैंने देखा कि पिछले दो वर्षों के दौरान इस विषय के आसपास इतने सारे पीआर विफल हो गए हैं ...
मैं निर्भरता के रूप में झुंड नहीं रखना चाहता। मेरे कुछ ग्राहक दूसरे क्लस्टर ऑर्केस्ट्रेटर का उपयोग करते हैं।

@कैसियुसा :
मुझे समझ में नहीं आता तुम्हारा क्या मतलब है?
1/पासवर्ड "कंटेनर बिल्डर" को दिया गया था जो अंतिम छवि नहीं है। यह बिल्डर एक डॉकर बिल्ड करता है और Dockerfile.realase के आधार पर एक इमेज बनाता है। इस अंतिम छवि के इतिहास में कोई रहस्य संग्रहीत नहीं हैं।
2/ यदि आप कमांड लाइन को पासवर्ड पास नहीं करना चाहते हैं तो डॉकर-कंपोज़ ( उदाहरण ) का उपयोग करने के लिए स्वतंत्र महसूस करें

@BenoitNorrin मुझे लगता है कि भविष्य में इसे गैर-झुंड में विस्तारित किया जा सकता है, लेकिन @diogomonica उस पर अधिक जान सकता है

ऐसा लगता है:

यह वर्तमान में केवल झुंड मोड के लिए है क्योंकि बैकिंग स्टोर झुंड है और यह केवल लिनक्स के लिए है। यह संभावित सुधारों जैसे कि विंडोज सपोर्ट, विभिन्न बैकिंग स्टोर आदि के साथ डॉकर में भविष्य के गुप्त समर्थन की नींव है।

बहुत अच्छा होगा अगर इसे रॉकर की तरह ही लागू किया जाए, हो सकता है
सरल, 'उद्यम' होने की आवश्यकता नहीं है।

मंगलवार को, 29 नवंबर 2016, 15:53 ​​माइकल वार्केंटिन, नोटिफिकेशन @github.com
लिखा था:

ऐसा लगता है:

यह वर्तमान में केवल झुंड मोड के लिए है क्योंकि बैकिंग स्टोर झुंड है और as
ऐसा केवल Linux के लिए है। यह भविष्य में गुप्त समर्थन की नींव है
विंडोज सपोर्ट जैसे संभावित सुधारों के साथ डॉकर, अलग
बैकिंग स्टोर, आदि।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे 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 अनएन्क्रिप्टेड सभी एन्क्रिप्टेड जानकारी दिखाएगा।

दूसरी ओर, कंटेनरों के अंदर ऐप्स इस एन्क्रिप्टेड जानकारी को उनके उपयोग के लिए एक्सेस और डिक्रिप्ट करने के लिए विभिन्न तंत्र को लागू करने में सक्षम होना चाहिए।

मुझे लगता है कि एन्क्रिप्शन _is key_ :)

उद्देश्य मेरे (वास्तव में, वास्तव में, वास्तव में सामान्य) उपयोग के मामले के लिए है a
एक गिट सर्वर से सॉफ्टवेयर प्रोजेक्ट जिसके लिए प्रमाणीकरण की आवश्यकता होती है, दोनों के लिए
परियोजना और उसकी निर्भरता। घुमाव ने माउंट करने की अनुमति देकर इसे खींचा है
निर्माण के दौरान एक फ़ाइल या निर्देशिका (इस मामले में एक एसएसएच एजेंट सॉकेट)

मंगल, 3 जनवरी 2017, 4:14 Hisa पर, [email protected] लिखा है:

एक विचार एक समाधान पारित जानकारी के कुछ हिस्सों को एन्क्रिप्ट करना होगा
एक डोकर-लिखें फ़ाइल से।

उदाहरण के लिए, डॉकर निरीक्षण चलाएं और एन्क्रिप्टेड जानकारी होनी चाहिए
एन्क्रिप्टेड के रूप में प्रदर्शित/चिह्नित। फिर डॉकर निरीक्षण --एन्क्रिप्शन-कुंजी
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- सेवा-आधारित-अनुप्रयोग-द्वारा-उपयोग-अमेज़ॅन-एस 3-और-डॉकर/

डॉकर 1.13 में एक नया "डॉकर सीक्रेट" कमांड है। इस समस्या को तब बंद किया जा सकता है जब उस सुविधा के लिए प्रलेखन यहां उल्लिखित उपयोग के मामलों के लिए पर्याप्त हो।

डॉकर गुप्त आदेश केवल वर्तमान में डॉकर झुंड (यानी डॉकर सेवाओं) पर लागू होता है, इसलिए वर्तमान में जेनेरिक डॉकर कंटेनरों के लिए व्यवहार्य नहीं है।

साथ ही docker secret केवल रन टाइम सीक्रेट्स को मैनेज करता है, टाइम सीक्रेट्स को नहीं बनाता।

वाह वाह। ऐसा लगता है कि उत्पाद प्रबंधन टीम में किसी ने भी कभी विचार नहीं किया है
उपयोग के मामले में जहां कुछ भी नहीं बल्कि अनधिकृत ओपन सोर्स सॉफ्टवेयर मिलता है
एक डॉक कंटेनर या गोलांग के अलावा किसी भी भाषा में बनाया गया है, जहां सभी
निर्भरताएँ कॉपी और पेस्ट की जाती हैं, क्षमा करें, गिट रेपो में 'संस्करणित'।

मुझे समझ में नहीं आता कि लोग इतने अविश्वसनीय रूप से कुंठित कैसे होंगे। केवल
स्पष्टीकरण मैं सोच सकता हूं कि उत्पाद प्रबंधन टीम नहीं है
चिकित्सकों और उत्पाद का उपयोग कभी नहीं किया है। मैं अक्सर यह देखता हूँ
विशेषता तब प्रकट होती है जब संगठन आधार पर किराए पर लेता है
जीरा/फुर्तीली कौशल।

मैं सिर्फ 2019 तक रॉकर का इस्तेमाल करता रहूंगा या जब भी कोई समझेगा तब।

सूर्य पर, 22 जनवरी 2017, 23:47 शेन सेंटक्लेयर, नोटिफिकेशन @github.com ने लिखा:

साथ ही डॉकर सीक्रेट्स केवल रन टाइम सीक्रेट्स को मैनेज करते हैं, टाइम सीक्रेट्स को नहीं बनाते।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे 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] ने लिखा:

वाह वाह। ऐसा लगता है कि उत्पाद प्रबंधन टीम में किसी ने भी कभी विचार नहीं किया है
उपयोग के मामले में जहां कुछ भी नहीं बल्कि अनधिकृत ओपन सोर्स सॉफ्टवेयर मिलता है
एक डॉक कंटेनर या गोलांग के अलावा किसी भी भाषा में बनाया गया है, जहां सभी
निर्भरताएँ कॉपी और पेस्ट की जाती हैं, क्षमा करें, गिट रेपो में 'संस्करणित'।

मुझे समझ में नहीं आता कि लोग इतने अविश्वसनीय रूप से कुंठित कैसे होंगे। केवल
स्पष्टीकरण मैं सोच सकता हूं कि उत्पाद प्रबंधन टीम नहीं है
चिकित्सकों और उत्पाद का उपयोग कभी नहीं किया है। मैं अक्सर यह देखता हूँ
विशेषता तब प्रकट होती है जब संगठन आधार पर किराए पर लेता है
जीरा/फुर्तीली कौशल।

मैं 2019 तक या जब भी कोई समझेगा तब तक रॉकर का उपयोग करता रहूँगा
फिर।

सूर्य पर, 22 जनवरी 2017, 23:47 शेन सेंटक्लेयर, सूचनाएं @github.com
लिखा था:

साथ ही डॉकर सीक्रेट्स केवल रन टाइम सीक्रेट्स को मैनेज करते हैं, टाइम सीक्रेट्स को नहीं बनाते।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/docker/docker/issues/13490#issuecomment-274370450 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAZk5vJVJe4OeypWd1Cwqmh8Gzyn8P-mks5rU-qqgaJpZM4Eq021
.

@binarytemple हर कोई अभी सभी सुविधाएँ चाहता है। अगर सामान तैयार नहीं है तो वह तैयार नहीं है। एक नई सुविधा के दायरे को सीमित करना निश्चित रूप से कोई बुरी बात नहीं है क्योंकि सीमित दायरे में भी सुधार की गुंजाइश हमेशा बनी रहती है।

यदि कोई वास्तव में एक सुविधा प्राप्त करने के बारे में गूंजी है, तो उन्हें एक अनुरक्षक (ओं) से बात करनी चाहिए कि वे उसके लिए काम में कैसे योगदान दे सकते हैं।

मैंने @mixja जैसा ही सोचा था कि secret कमांड केवल झुंड उपयोगकर्ताओं की मदद करता है, यह अधिक सामान्य समाधान नहीं है (जैसे उन्होंने लगातार वॉल्यूम संलग्न करने के साथ किया)। आप अपने रहस्यों का प्रबंधन कैसे करते हैं (वे क्या हैं और उन तक किसकी पहुंच है) बहुत सिस्टम पर निर्भर है और यह इस बात पर निर्भर करता है कि आप अपना "प्लेटफ़ॉर्म" बनाने के लिए भुगतान किए गए और/या ओएसएस के किन बिट्स को एक साथ जोड़ते हैं। डॉकर के साथ कंपनी एक मंच प्रदान करने में आगे बढ़ रही है, मुझे आश्चर्य नहीं है कि उनका पहला कार्यान्वयन झुंड आधारित है जैसे हाशिकॉर्प वॉल्ट को एटलस में एकीकृत कर रहा है - यह समझ में आता है।

वास्तव में रहस्यों को कैसे पारित किया जाता है, यह docker run दायरे से बाहर है। एडब्ल्यूएस इस तरह का काम भूमिकाओं और नीतियों के साथ अनुमतियां देने/अस्वीकार करने के साथ-साथ एक एसडीके के साथ करता है। शेफ इसे एन्क्रिप्टेड डेटाबैग और क्रिप्टो "बूटस्ट्रैपिंग" को ऑथ के लिए उपयोग करता है। K8S का अपना संस्करण है जो अभी 1.13 में जारी किया गया है। मुझे यकीन है कि मेसोस समय पर एक समान कार्यान्वयन जोड़ देगा।

ये कार्यान्वयन 2 शिविरों में आते हैं।
1) वॉल्यूम माउंट के माध्यम से रहस्य को पास करें जो "प्लेटफ़ॉर्म" प्रदान करता है या (शेफ/डॉकर सीक्रेट/k8s .)
2) बूट पर चीजें प्राप्त करने के लिए बाहरी सेवा से बात करने के लिए क्रेडेंशियल पास करें (iam/credstash/etc)

मुझे लगता है कि मैं दूसरे विकल्प की तर्ज पर कुछ और देखने की उम्मीद कर रहा था। पहले विकल्प में, मुझे नहीं लगता कि चिंताओं का पर्याप्त अलगाव है (लॉन्चिंग करने वाली चीज की सभी चाबियों तक पहुंच भी है), लेकिन यह वरीयता है, और सिस्टम बिल्डिंग में बाकी सब कुछ की तरह, हर कोई इसे अलग करना पसंद करता है .

मुझे प्रोत्साहित किया गया है कि यह पहला कदम डॉकटर द्वारा उठाया गया है और आशा करता हूं कि docker run लिए एक और सामान्य तंत्र इससे बाहर आता है (शिविर # 2 का समर्थन करने के लिए) - जिसका दुख की बात है कि मुझे नहीं लगता कि यह धागा है प्रारंभिक मिशन पूरा हो गया है और अभी तक बंद नहीं किया जाना चाहिए।

पसंद!
वास्तव में सरल लेकिन बहुत प्रभावी डिजाइन

@bacoboy , @mixja - सिंगल नोड झुंड और एक कंटेनर सेवा इतनी खराब नहीं है
docker swarm init , docker service create replica=1

मेरे लिए यह तर्कसंगत है कि अब से कंटेनर/सेवाओं को चलाने के लिए डॉकटर झुंड डिफ़ॉल्ट होगा।

क्या मैं यह सोचने में सही हूं कि यह नया झुंड-आधारित प्रस्ताव केवल रन-टाइम रहस्यों को प्रभावित करता है? मुझे वास्तव में रन-टाइम रहस्यों के विशेष प्रबंधन की कोई आवश्यकता नहीं दिखती है, क्योंकि पहले से ही चल रहे कंटेनर में रहस्यों को लाने के कई तरीके हैं।

बिल्ड- टाइम रहस्य महत्वपूर्ण हैं, और जहां तक ​​मुझे पता है, यह प्रस्ताव उन्हें संबोधित नहीं करता है।

बिल्ड-टाइम रहस्यों को इंजेक्ट करने के लिए, अब हम निम्नलिखित को सुरक्षित रूप से करने के लिए docker build --squash का उपयोग कर सकते हैं:

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

--squash ध्वज संपूर्ण डॉकरफ़ाइल के लिए एक परत का उत्पादन करेगा: रहस्य का कोई निशान नहीं होगा।

--squash docker-1.13 में प्रायोगिक ध्वज के रूप में उपलब्ध है।

@hmalphettes इसका मतलब है कि आप बिल्ड के बीच साझा निचली परतों के लाभों को याद करते हैं।

यह निश्चित रूप से स्क्वैश का इरादा नहीं है। आईडी अभी भी इस तरह के रहस्यों को जोड़ने के बारे में बहुत सावधान रहें।

@zoidbergwill निचली परतें अभी भी साझा की गई हैं।

मैं @cpuguy83 से 100% सहमत हूं। रहस्यों को बाहर रखने के लिए बिल्ड टाइम फ्लैग पर भरोसा करना काफी जोखिम भरा होगा। निर्माण समय के लिए एक प्रस्ताव पीआर था (https://github.com/docker/docker/pull/30637) मैं अधिक प्रतिक्रिया प्राप्त करने के लिए एक रिबेस पर काम करूंगा।

@wpalmer यदि आपके पास स्वचालित छवि बनाता है, तो आपके टूलिंग को पता होना चाहिए कि बिल्ड-टाइम रहस्य कैसे प्राप्त करें।

उदाहरण के लिए, हो सकता है कि आप अपने बिल्ड-टाइम सीक्रेट्स को एक इमेज में बेक किए गए एन्सिबल एन्क्रिप्टेड वॉल्ट में रखना चाहें और उस इमेज से चलने वाले कंटेनरों को रन-टाइम सीक्रेट तक पहुंच प्रदान करें जो आपके वॉल्ट पासवर्ड को रखता है।

डब्लूडीवाईटी?

हम रनटाइम सीक्रेट्स के साथ बिल्ड-टाइम सीक्रेट्स को भ्रमित क्यों करते रहते हैं? रनटाइम रहस्य प्रदान करने के लिए डॉकटर (या कुबेरनेट्स जैसे संबंधित टूल) के लिए पहले से ही कई अच्छे तरीके हैं। केवल एक चीज जो वास्तव में गायब है वह है बिल्ड-टाइम सीक्रेट्स। इन रहस्यों का उपयोग रन टाइम के दौरान नहीं किया जाता है, इनका उपयोग इंस्टॉल समय के दौरान किया जाता है, उदाहरण के लिए यह आंतरिक भंडार हो सकता है। इस और संबंधित विषयों में मैंने देखा है कि एकमात्र कामकाजी तरीका (लेकिन इसके खिलाफ भी सलाह दी गई है), निर्माण समय के दौरान कंटेनर में एक http सर्वर को उजागर कर रहा है। http सर्वर दृष्टिकोण चीजों को वास्तव में उन रहस्यों तक पहुंचने के लिए जटिल बना देता है।

+1 बिल्ड टाइम सीक्रेट!= रन टाइम सीक्रेट

जैसा कि पॉल बताते हैं। आंतरिक भंडार को सेंकना वांछनीय नहीं है
छवि में क्रेडेंशियल।

यह समझना इतना कठिन क्यों है?

गुरु, 16 फरवरी 2017, 14:42 पॉल वैन डेर लिंडेन, नोटिफिकेशन @github.com . पर
लिखा था:

हम रनटाइम सीक्रेट्स के साथ बिल्ड-टाइम सीक्रेट्स को भ्रमित क्यों करते रहते हैं? वहां
docker (या संबंधित उपकरण जैसे कुबेरनेट्स) के लिए पहले से ही कई अच्छे तरीके हैं
रनटाइम रहस्य प्रदान करें। केवल एक चीज जो वास्तव में गायब है वह है बिल्ड-टाइम
रहस्य इन रहस्यों का उपयोग रन टाइम के दौरान नहीं किया जाता है, इनका उपयोग के दौरान किया जाता है
समय स्थापित करें, उदाहरण के लिए यह आंतरिक भंडार हो सकता है। केवल
काम करने का तरीका मैंने इसमें और संबंधित विषयों में देखा है (लेकिन सलाह भी दी है
इसके खिलाफ), निर्माण समय के दौरान कंटेनर में एक 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 सुनिश्चित नहीं है कि यह मेरे (और अन्य) मामले का उपयोग कैसे करेगा।
जब मैं डॉकर बिल्ड प्रक्रिया शुरू करता हूं तो जिन पैकेजों को स्थापित करने की आवश्यकता होती है, वे पहले से ही निर्मित होते हैं। लेकिन डॉकटर बिल्ड को इन पैकेजों को स्थापित करने की आवश्यकता होगी, इसके लिए आंतरिक एनाकोंडा रिपॉजिटरी और/या पीपीआई सर्वर (पायथन) तक पहुंच की आवश्यकता होगी। स्थान और पासवर्ड बेशक निजी हैं।
ऐसा लगता है कि #30637 एक और प्रयास है, उम्मीद है कि यह डॉकटर में समाप्त हो जाएगा!

@timka आपके संदेश का पहला भाग बिल्ड-टाइम रहस्यों का उल्लेख करता है, लेकिन दूसरी छमाही रन-टाइम रहस्यों के बारे में स्पष्ट रूप से बात करती है। रन-टाइम रहस्य सरल हैं। बिल्ड-टाइम सीक्रेट्स के लिए मेरा वर्तमान "समाधान" एक पूरी तरह से अलग कदम के रूप में प्री-रन करना है, एक कंटेनर जो रन-टाइम सीक्रेट का उपयोग करके निजी डेटा प्राप्त करता है। नियमित docker build कमांड चलाने से पहले एक और कदम इसे ट्री में मिला देता है।

वैकल्पिक, यदि बिल्ड-टाइम रहस्य एक मानक विशेषता थी, तो इन चरणों को डॉकरफाइल के भीतर चलाना होगा।

मेरा टूलींग जानता है कि इन चरणों को स्वचालित रूप से कैसे चलाया जाए, लेकिन मुझे इसे स्वयं सेंकना चाहिए, जो कि इस तरह की सामान्य इच्छा के लिए कुछ हद तक बेतुका है।

FYI करें, मैंने बिल्ड-टाइम सीक्रेट्स समस्या को हल करने के लिए https://github.com/abourget/secrets-bridge लिखा था।

यह एक फेंक-दूर कॉन्फ़िगरेशन बनाता है जिसे आप तर्क के रूप में पारित कर सकते हैं, निर्माण प्रक्रिया के दौरान, यह होस्ट से कनेक्ट होगा और रहस्यों को लाएगा, उनका उपयोग करेगा, और फिर आप होस्ट ब्रिज को मार सकते हैं। भले ही बिल्ड-आर्ग कहीं सहेजे गए हों, सर्वर के मारे जाने पर वे बेकार हो जाते हैं।

सर्वर SSH एजेंट फ़ॉरवर्डिंग का समर्थन करता है, जिसे TLS वेबसोकेट संचार के माध्यम से टनल किया जाता है। यह विंडोज़ पर भी काम करता है!

अलेक्जेंड्रे, आपने जो किया है वह बेहद रचनात्मक और कुशल है। यह बिलकुल
मुझे दुखी करता है कि इन सभी चरणों को पूरी तरह से कूदना आवश्यक है बस
अगर 'डॉकर बिल्ड' 'माउंट' का समर्थन करता है तो वही हासिल किया जा सकता है
अंध आग्रह के बजाय आदेश दें कि सब कुछ कॉपी किया जाए
कंटेनर।

मेरा मामला मैं 'डॉकर बिल्ड' को छोड़ने जा रहा हूं और इसके बजाय रॉकर का उपयोग कर रहा हूं or
कुछ अगर मेरी अपनी रचना।

गुरु, 13 जुलाई 2017, 16:23 अलेक्जेंड्रे बोर्जेट पर, सूचनाएं @github.com
लिखा था:

FYI करें, मैंने https://github.com/abourget/secrets-bridge को संबोधित करने के लिए लिखा था
बिल्ड-टाइम रहस्य समस्या।

यह एक फेंक-दूर कॉन्फ़िगरेशन बनाता है जिसे आप तर्क के रूप में पारित कर सकते हैं,
निर्माण प्रक्रिया के दौरान, यह मेजबान से जुड़ जाएगा और प्राप्त करेगा
रहस्य, उनका उपयोग करें, और फिर आप मेजबान पुल को मार सकते हैं। भले ही
बिल्ड-आर्ग कहीं सहेजे जाते हैं, सर्वर के पल में वे बेकार हो जाते हैं
उसे मारा गया।

सर्वर SSH एजेंट फ़ॉरवर्डिंग का समर्थन करता है, जिसे TLS के माध्यम से टनल किया जाता है
वेबसोकेट संचार। यह विंडोज़ पर भी काम करता है!

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे 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

मुझे लगता है कि पिछले डॉकर सीई रिलीज के अंदर शामिल नई "मल्टी-स्टेज बिल्ड" कार्यक्षमता हमारी समस्याओं का एक बड़ा हिस्सा हल करती है।

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

Dockerfile से कमांड निष्पादित करने के लिए तैयार किए गए कंटेनर पके हुए /dev साथ आते हैं और वहां किए गए कोई भी परिवर्तन एक परत में दर्ज नहीं किए जाने चाहिए। क्या डोकर उस आरोह बिंदु के माध्यम से उपयोगकर्ता रहस्य प्रदान कर सकता है? इसी तरह यह /dev/init प्रदान करता है?

यह अभी भी बहुत महत्वपूर्ण है क्योंकि तर्कों के साथ मल्टीस्टेज बिल्ड छवि में लीक नहीं होता है, लेकिन फिर भी चल रहे सिस्टम पर प्रक्रिया सूचियों के हिस्से के रूप में आपके रहस्यों को उजागर करता है, इसलिए यह वास्तव में हल नहीं होता है।

यह अगस्त 2017 है। इस बीच 2014 से मुद्दों के मूल मुद्दे लिंक में "रहस्य से निपटने के पुराने प्रस्ताव"।

बिल्ड-टाइम सीक्रेट्स के लिए अभी भी कोई अच्छा समाधान नहीं है। --build-time-secret ध्वज की पेशकश करने वाले पीआर को बिना किसी स्पष्टीकरण के बंद कर दिया गया था। "तो, क्या चाहिए?" में कुछ भी प्रस्तुत नहीं किया गया। अनुभाग लागू किया गया है।

इस दौरान

नव स्थापित सीईओ स्टीव सिंह व्यावसायिक ग्राहकों पर ध्यान केंद्रित कर रहे हैं
बिक्री, मार्केटिंग टीम बनाने में सहायता के लिए $75 मिलियन का नवीनतम दौर

यूपीडी : जैसा कि

मुझे पता है कि यह नहीं बनाया गया है, लेकिन secrets-bridge अभी के लिए बहुत अच्छा काम करता है।

@dmitriid मैं आपकी हताशा को समझता हूं कि यह सुविधा गायब है। हालांकि यह नहीं है कि एक ओपन सोर्स समुदाय (या किसी समुदाय) को कैसे संबोधित किया जाए।

मैंने ऊपर एक प्रस्ताव के लिए एक लिंक पोस्ट किया है, और मेरे अपने को छोड़कर इस पर बिल्कुल 0 टिप्पणियां देखी हैं।

यहाँ नवीनतम रहस्य प्रस्ताव है: #33343

@cpuguy83 बहुत बढ़िया! मैं इस चर्चा के अंतिम तीसरे (और कुछ अन्य) को छोड़ दिया क्योंकि यह पढ़ने के लिए बहुत सी चीजें हैं (जबकि एक ही समय में समाधान की तलाश में), इसलिए मुझे वास्तव में आपकी टिप्पणी याद आई, क्षमा करें :(

यह सिलसिला 2015 में शुरू हुआ था।

2017 है।

बिल्ड-टाइम रहस्यों का कोई समाधान क्यों नहीं है जो हैकिश और भयानक नहीं है, फिर भी? यह स्पष्ट रूप से बहुत से लोगों के लिए एक बड़ा मुद्दा है, लेकिन वास्तव में अभी भी कोई अच्छा समाधान नहीं है!

@mshape

बिल्ड-टाइम रहस्यों का कोई समाधान क्यों नहीं है जो हैकिश और भयानक नहीं है, फिर भी?

क्योंकि इसे ठीक से हल करना एक कठिन समस्या है और यह एक ऐसी चीज है जिसका उपयोग सचमुच लाखों लोग करेंगे।

कृपया मेरी टिप्पणी को अपने ऊपर देखें:

मैंने ऊपर एक प्रस्ताव के लिए एक लिंक पोस्ट किया है, और मेरे अपने को छोड़कर इस पर बिल्कुल 0 टिप्पणियां देखी हैं।
यहाँ नवीनतम रहस्य प्रस्ताव है: #33343

यदि आप कुछ लागू होते देखना चाहते हैं तो आपको शिकायत करने के अलावा और कुछ करने की आवश्यकता होगी कि कुछ लागू नहीं हुआ है। कृपया प्रस्ताव पर टिप्पणी करें!

इसे हल करना इतना आसान है। इसके लिए बस कुछ चाहिए, कुछ भी जो नहीं है
छवियों में बेक किया हुआ। और वास्तव में इसे हल करना बहुत आसान है, उपयोग करना बंद करें
'डॉकर बिल्ड' और पायथन एपीआई, रॉकर, या कुछ और का उपयोग करें।

बुधवार 23 अगस्त, 2017 को रात 9:42 बजे, ब्रायन गोफ नोटिफिकेशन @github.com
लिखा था:

@mshape https://github.com/mshape

बिल्ड-टाइम रहस्यों का कोई समाधान क्यों नहीं है जो हैकिश नहीं है और
भयानक, अभी तक?

क्योंकि इसे ठीक से हल करना एक कठिन समस्या है और यह कुछ ऐसा है जो
सचमुच लाखों लोगों द्वारा उपयोग किया जाएगा।

कृपया मेरी टिप्पणी को अपने ऊपर देखें:

मैंने ऊपर एक प्रस्ताव के लिए एक लिंक पोस्ट किया है, और इस पर बिल्कुल 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 मैंने रॉकर को एक विकल्प के रूप में

यह अजीब है। मैं लोगों से बात करता हूं और वे हर तरह की बेवकूफी भरी हैक्स कर रहे हैं
जैसे HTTP सेवा का उपयोग करना - सब कुछ फेंक देना (निगरानी/दानेदार)
अनुमतियाँ/सादगी) POSIX/SELinux कॉम्बो प्रदान करता है। मैं बस नहीं
समझना। इनकार मुझे अतार्किक लगता है।

बुधवार को, 23 अगस्त 2017, 23:03 माइकल स्कॉट शेप नोटिफिकेशन @github.com
लिखा था:

@binarytemple https://github.com/binarytemple मैंने देखना शुरू कर दिया है
एक विकल्प के रूप में घुमाव, वास्तव में...लेकिन केवल इस अजीब की वजह से
लगता है कि मानसिक ब्लॉक डॉकर में बिल्ड-टाइम सीक्रेट्स हैं।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/moby/moby/issues/13490#issuecomment-324461257 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAZk5ppZYsOhdfvgotCUk5l41Truo_EEks5sbJOLgaJpZM4Eq021
.

मल्टी-स्टेज डॉकर बिल्ड इनमें से कई मुद्दों को हल करता है।

अपने सरलतम रूप में आप बिल्ड-आर्ग के रूप में रहस्यों को इंजेक्ट कर सकते हैं, और वे केवल छवियों के छवि इतिहास का हिस्सा होंगे जो स्पष्ट रूप से कहते हैं कि उन्हें तर्क की आवश्यकता है। जैसा कि नेक्लिमदुल बताते हैं , निर्माण के दौरान प्रक्रिया सूची में रहस्य उपलब्ध होंगे। IMO कोई बड़ा मुद्दा नहीं है, लेकिन हमने एक और तरीका अपनाया है।

हमारा बिल्ड सर्वर वॉल्यूम के रूप में माउंट किए गए कुछ रहस्यों के साथ चलता है, इसलिए हमारी सीआई प्रतिलिपि f.ex. /mnt/secrets/.npmrc वर्तमान कार्य निर्देशिका में। फिर हम नीचे वाले के समान एक डॉकरफाइल का उपयोग करते हैं।

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 या इसकी सामग्री के किसी भी अंश पर नहीं।

मल्टी-स्टेज बिल्ड का उपयोग करने से आपको बिल्ड प्रक्रिया में बिल्ड टाइम सीक्रेट्स को उजागर करने का पूरा नियंत्रण मिलता है। आप वॉल्यूम के माध्यम से वॉल्ट जैसे बाहरी स्टोर से रहस्य प्राप्त कर सकते हैं (जिसे हम कुबेरनेट्स में सीक्रेट स्टोर से माउंट करते हैं), उन्हें रिपॉजिटरी, ट्रैविस सीक्रेट्स आदि में जीपीजी एन्क्रिप्ट किया गया है।

इस उपयोग के मामले के लिए मल्टी स्टेज बिल्ड का उपयोग करते समय सुनिश्चित करें कि आप यह महसूस करते हैं कि गुप्त डेटा स्थानीय डेमॉन में एक अनटैग्ड इमेज के अंदर तब तक रहेगा जब तक कि उस इमेज को हटा नहीं दिया जाता है ताकि बाद के बिल्ड में कैश बनाने के लिए इस डेटा का उपयोग किया जा सके। लेकिन अंतिम टैग की गई छवि को आगे बढ़ाते समय इसे रजिस्ट्री में नहीं धकेला जाता है।

@androa मुझे वह समाधान पसंद है लेकिन मुझे यकीन नहीं है कि मैं कार्य निर्देशिका में कॉपी किए जा रहे रहस्यों के बारे में कैसा महसूस करता हूं। यह शायद एक निजी सीआई सर्वर पर ठीक है, लेकिन यह स्थानीय भवन के लिए इतना अच्छा नहीं है जहां आप उन फाइलों की प्रतिलिपि बना रहे होंगे जिन्हें आपको संरक्षित स्थानों से बाहर नहीं करना चाहिए (उल्लेख नहीं है कि प्रतिलिपि स्वयं ही परेशान और खतरनाक दोनों है जिसमें वे गलती से समाप्त हो सकते हैं स्रोत नियंत्रण में)। दूसरा विकल्प एक व्यापक डॉकर बिल्ड संदर्भ का उपयोग करना होगा, लेकिन बहुत सारे सामान्य रहस्यों के लिए जिसका अर्थ संपूर्ण रूट वॉल्यूम हो सकता है। स्थानीय और सीआई के लिए इसे अच्छा बनाने के बारे में कोई सुझाव?

यह भयावह है। स्व-घोषित "दुनिया का अग्रणी सॉफ्टवेयर कंटेनर प्लेटफॉर्म" को पिछले 3 वर्षों से कंटेनरों में सुरक्षित रूप से बिल्ड-टाइम सीक्रेट्स पास करने की जहमत नहीं उठाई जा सकती है।

"हम बेहतर जानते हैं" और "गलतियों की अनुमति देने वाला सॉफ़्टवेयर न बनाएं" दृष्टिकोण और जिसे डिज़ाइन चरण में दुर्भाग्यपूर्ण चूक के रूप में वर्णित किया जा सकता है, देवओप्स सॉफ़्टवेयर की आवश्यक सुविधाओं में से एक के लिए कोई समर्थन और कोई दृश्यमान प्रगति नहीं है। सभी समुदाय ने सुझाव दिया और कभी-कभी यहां तक ​​​​कि विलय-तैयार होने के बिंदु तक विकसित किए गए सुधारों को किसी के दुरुपयोग के डर से बंद कर दिया जाता है। इस क्लस्टर के परिणामस्वरूप ... विफलता, केवल डॉक कंटेनर के निर्माण चरण के लिए आवश्यक निजी कुंजी को पारित करने के सभी तरीकों के लिए उन रहस्यों को निर्माण इतिहास में सहेजने की आवश्यकता होती है, या प्रक्रिया सूची में इस उम्मीद के साथ दिखाई देने की आवश्यकता होती है कि, क्रमशः, निर्माण इतिहास कभी नहीं छोड़ता है विश्वसनीय मशीन या कोई नहीं जिसे कभी भी प्रक्रिया सूची को नहीं देखना चाहिए। जिनमें से दोनों सबसे अधिक अनुमेय सुरक्षा ऑडिट में भी विफल हो जाएंगे।

यह मुद्दा 2 वर्षों से अधिक समय से खुला है, संक्षेप में बताने के लिए कि उस समय समस्या के बारे में क्या ज्ञात था और इसके बारे में क्या करना है। अभी भी कोई समाधान नहीं है। इसके द्वारा, मेरा मतलब एक व्यापक समाधान नहीं है जो बॉक्स से सबसे जटिल गुप्त प्रबंधन योजनाओं का समर्थन करेगा। कोई समाधान नहीं है, कोई होस्ट पर्यावरण चर नहीं है, बिल्ड संदर्भ के बाहर फ़ाइल पथ से कोई लोडिंग रहस्य नहीं है। कुछ भी नहीं जिसे कम से कम कड़े शब्दों में भी सुरक्षित समझा जा सकता है।

@OJezu जैसा कि मैंने इस मुद्दे पर कई बार कहा है, इस पर मूल रूप से 0 टिप्पणियों के साथ एक खुला प्रस्ताव है।
यदि आप रहस्यों को आगे बढ़ते हुए देखना चाहते हैं, तो कृपया प्रस्ताव पर टिप्पणी करने के लिए समय निकालें।

हर दिन इस पर काम करने वाले लोगों पर हमला करने के बजाय, अगली बार प्रश्न पूछने और कम से कम उस मुद्दे पर नवीनतम टिप्पणियों को पढ़ने का प्रयास करें, जिस पर आप टिप्पणी कर रहे हैं।

चीजें अक्सर रुकी हुई दिख सकती हैं, जब वास्तव में काम में मेहनती लोग होते हैं।
निर्माण के लिए, github.com/moby/buildkit देखें जहां यह अधिकांश कार्य आज हो रहा है।

धन्यवाद।

मैं थोड़ा सतर्क हूं, क्योंकि आज मैंने किसी ऐसी चीज का समाधान खोजने की कोशिश में 9 घंटे बिताए जो कोई समस्या नहीं होनी चाहिए, विशेष रूप से एक ऐसे प्रोजेक्ट में जो पूर्णकालिक रूप से काम कर रहा हो और खुद को वास्तविक मानक और गो-टू सोलशन के रूप में स्थापित कर रहा हो। . मैं बहुत कोशिश कर रहा था कि इन टिप्पणियों को लिखते समय कसम न खाऊं और खुद को नुकसान पहुंचाना बंद कर दूं।

मैंने उस मुद्दे को देखा, और दो समाधानों के संदर्भ देखे, एक अप्रैल से रुका हुआ था, दूसरा पहले से ही बंद था। मैं मदद नहीं कर सकता, लेकिन ध्यान दें, कि 0 टिप्पणियों के प्रस्ताव में 4 प्रतिभागी हैं, टिप्पणियों की समान संख्या है, और कुछ स्पष्ट आंतरिक चर्चा का उल्लेख है, मुझे लगता है कि लोग . लेकिन अगर आप किसी ऐसे व्यक्ति से अतिरिक्त प्रतिक्रिया चाहते हैं, जो जाने में भी कार्यक्रम नहीं करता है, तो मैं पिछली टिप्पणी में मैंने जिन समस्याओं को छुआ था, उन पर और अधिक विचार प्रदान कर सकता हूं।

@OJezu

कम से कम एक आसान समाधान है: कलाकृतियों के निर्माण के लिए एक समर्पित सेवा (जैसे जेनकींस पर चलाना) का उपयोग करें।
आपकी छवि पर निर्भर कलाकृतियों तक पहुँचने के लिए उस सेवा को सभी आवश्यक कुंजियों का सुरक्षित रूप से प्रावधान किया जाएगा।
खत्म होने पर कलाकृतियों को एक सुरक्षित स्थान (जैसे जेनकिंस) पर रखा जाएगा। उन कलाकृतियों में कोई रहस्य नहीं होगा, केवल बाइनरी/स्रोत/आदि के साथ एक निर्देशिका होगी।
फिर एक अन्य सेवा (उदाहरण के लिए एक अन्य जेनकिंस जॉब) उन पूर्वनिर्मित कलाकृतियों तक पहुंच बनाएगी और उन्हें एक छवि में बदल देगी, जिसे सुरक्षित रूप से एक छवि रजिस्ट्री में धकेला जा सकता है, जो बदले में डेवलपर/उत्पादन मशीनों से उन्हें एक्सेस करने के लिए rbac/keys का उपयोग करके सुरक्षित रूप से संरक्षित है।

यानी डॉकटर इमेज बिल्ड प्रोसेस किसी भी अन्य बिल्ड सिस्टम से अलग नहीं है: आपके पास एक बिल्ड पाइपलाइन होनी चाहिए।

@Vanuan पैकेजिंग और इंस्टॉलेशन के साथ सभी भाषाएं इतनी सरल नहीं हैं, बस एक आर्टिफैक्ट के साथ स्थापित करने के लिए।

उदाहरण?

पायथन परियोजनाएं अपनी आवश्यकताओं को स्थापित समय पर नहीं बल्कि स्थापित समय पर खींचती हैं। हमारे मामले में, एक निजी pypi/conda भंडार (पासवर्ड संरक्षित) से

इसलिए? स्थापना को अपनी निर्माण प्रक्रिया का हिस्सा बनाएं और फिर स्थापित पैकेजों को एक नई छवि में कॉपी करें।

आपको बस यह सुनिश्चित करने की ज़रूरत है कि आपकी बिल्ड इमेज और आपकी प्रोडक्शन इमेज एक ही पायथन बेस इमेज पर आधारित हैं।

आप वास्तव में सब कुछ वास्तव में एक नई छवि में कॉपी कर सकते हैं। हालांकि यह डॉकरफाइल के पूरे बिंदु को हटा देता है। डॉकरफाइल क्यों है यदि केवल एक चीज जिसके लिए आप इसका उपयोग कर सकते हैं वह सिर्फ निर्देशिकाओं के एक सेट की प्रतिलिपि बनाना है?

इसलिए, मेरे पास एक साधारण प्रवाह नहीं हो सकता है जिसमें मैं कहीं भी docker build . चलाता हूं - या तो देव मशीन या सीआई पर, लेकिन मुझे पैकेज बनाने के लिए सीआई पर निर्भर रहना पड़ता है। फिर भी डोकर से परेशान क्यों? मैं एक ट्रैविस फ़ाइल लिख सकता हूं, या बांस में प्रवाह को कॉन्फ़िगर कर सकता हूं।

क्या आप अपने पहले चरण के निर्माण में केवल pip install requirements.txt नहीं कर सकते हैं जो आपके निजी भंडारों से खींचने के लिए उपलब्ध रहस्यों के साथ है। फिर अगला चरण बिल्ड पहले चरण से साइट-पैकेजों की प्रतिलिपि बनाता है।

डॉकरफाइल क्यों है यदि केवल एक चीज जिसके लिए आप इसका उपयोग कर सकते हैं वह सिर्फ निर्देशिकाओं के एक सेट की प्रतिलिपि बनाना है?

क्यों नहीं? बनाने के लिए Dockerfile का उपयोग करना सुसंगत है।

छवि विनिर्देश अधिक है तो बस ज़िप की गई फ़ाइलों का एक समूह है। पर्यावरण चर, कमांड लाइन तर्क, वॉल्यूम आदि हैं

डॉकरफाइल संदर्भ पढ़ें:
https://docs.docker.com/engine/reference/builder/

ऐसा लगता है कि आप मुख्य रूप से RUN निर्देश पर ध्यान केंद्रित कर रहे हैं, यह सोचकर कि Dockerfile आपके लिए Makefile का प्रतिस्थापन है। यह नहीं। डॉकरफाइल केवल एक चीज के लिए है: कुछ स्रोत सामग्री से एक छवि बनाएं। वह स्रोत सामग्री क्या होगी - http या git रिपॉजिटरी पर डाउनलोड की गई बाइनरी - कोई फर्क नहीं पड़ता। डॉकर को आपका सीआई सिस्टम होने की आवश्यकता नहीं है, भले ही आप इसे कुछ शर्तों के तहत एक के रूप में उपयोग कर सकते हैं।

मैं एक ट्रैविस फ़ाइल लिख सकता हूं, या बांस में प्रवाह को कॉन्फ़िगर कर सकता हूं।

यदि आप अपनी निर्माण प्रक्रिया का परिणाम प्राप्त कर सकते हैं और फिर इसे किसी अन्य वातावरण में, छवियों और कंटेनरों के बिना चलाने के लिए प्राप्त कर सकते हैं, तो निश्चित रूप से आपको डॉकर से परेशान होने की आवश्यकता नहीं है। आप क्यों?

अलग, सख्ती से नियंत्रित वातावरण जो बिल्ड के बीच गारंटीकृत रीसेट प्राप्त करता है, लेकिन केवल तभी जब बिल्ड चरण बदल गए हों। इसे कहीं भी चलाने की क्षमता, न केवल सीआई सर्वर (जैसे ट्रैविस के साथ), कोड के साथ निर्माण निर्देश बांधना, जो मुझे लगता है कि विभिन्न कोड शाखाओं के लिए परिवर्तन बनाने पर अच्छा है (उदाहरण के लिए केवल एक शाखा पर रन पर्यावरण का संस्करण बदलें)। डेवलपर मशीनों पर बिल्ड कंटेनर चलाने की संभावना, डेवलपर्स को पूरे पर्यावरण को शिपिंग करने की इजाजत देता है, जो अन्यथा नहीं जानते कि अपने सिस्टम को कैसे अपग्रेड करना है, लेकिन स्थानीय रूप से सभी के समान वातावरण के साथ स्थानीय रूप से अपने परिवर्तनों के साथ एप्लिकेशन बनाने में सक्षम होंगे।

अगर मैं वह सब नहीं चाहता, तो मैं lxc + ansible से चिपक जाता, तब डॉकटर की कोई आवश्यकता नहीं होती।

इसके लिए आपको docker build आवश्यकता नहीं है।

इसके लिए आपको docker build आवश्यकता नहीं है।

बेशक आप एक आत्मनिर्भर डॉकरफाइल के बजाय प्रत्येक प्रोजेक्ट के लिए एक कस्टम Makefile या build_image.sh स्क्रिप्ट भी प्रदान कर सकते हैं, लेकिन इसके कई नुकसान हैं:

• क्रॉस प्लेटफ़ॉर्म संगतता: डॉकरफ़ाइल प्रदान करने के साथ, मुझे पता है कि कोई भी सिस्टम जो docker build सकता है वह छवि बनाने में सक्षम होगा। एक कस्टम Makefile या build_image.sh , मुझे मैन्युअल रूप से यह सुनिश्चित करना होगा कि वे सभी प्लेटफॉर्म पर काम करते हैं जिनका मैं समर्थन करना चाहता हूं।
• उपयोगकर्ताओं के लिए ज्ञात इंटरफ़ेस: यदि आप डॉकर को जानते हैं, तो आप किसी भी प्रोजेक्ट के लिए docker build के कुछ व्यवहार को जानते हैं, यहां तक ​​कि डॉकरफाइल (जैसे कैशिंग, आदि के संबंध में) को देखे बिना भी। यदि मेरे पास प्रत्येक प्रोजेक्ट के लिए एक कस्टम Makefile या build_image.sh , तो मुझे पहले यह पता लगाना होगा कि निर्माण, साफ करने के लिए क्या आदेश हैं, परिणाम कहां और किस रूप में है, यदि वहां है कुछ कैशिंग है और किस रूप में...

ओह, डॉकरफाइल आत्मनिर्भर से बहुत दूर है। खासकर विकास के माहौल के लिए।
इस पर विचार करो:

• अधिकांश डेवलपर्स docker build सभी विभिन्न विकल्पों को नहीं जानते हैं, लेकिन लगभग सभी जानते हैं कि बैश स्क्रिप्ट कैसे चलाना है
• docker build संदर्भ निर्देशिका पर निर्भर करता है। इसलिए जब तक आप प्रत्येक स्रोत लाइन परिवर्तन के लिए एक स्थान से दूसरे स्थान पर जाने के लिए गीगाबाइट डेटा (निर्भरता के साथ आपका स्रोत कोड) की प्रतीक्षा करने को तैयार नहीं हैं, तो आप इसे विकास के लिए उपयोग नहीं करेंगे।
• जब तक आप खरोंच से सब कुछ नहीं बनाते हैं, तब तक आपके पास डॉकर रजिस्ट्री पर निर्भरता है
• यह संभावना है कि आप ओएस रिपॉजिटरी (चाहे आप डेबियन या अल्पाइन-आधारित छवियों का उपयोग करें) पर निर्भर होंगे, जब तक कि आप एक कंटेनर को सीधे स्थिर रूप से निर्मित बाइनरी में बूट नहीं करते हैं
• जब तक आप सब कुछ गिट के लिए प्रतिबद्ध नहीं करते हैं, आपके पास कुछ प्रोजेक्ट-स्तरीय निर्भरताएं होंगी, चाहे वह एनपीएम, पायथन पैकेज इंडेक्स, रूबीगेम्स या कुछ और हो। तो आप कुछ बाहरी पैकेज रजिस्ट्री या उसके दर्पण पर निर्भर रहेंगे
• जैसा कि अधिकांश लोगों ने यहां देखा है कि आप अपनी निजी निर्भरताओं के लिए कुछ गुप्त पैकेज स्थान पर
• उस सुरक्षित स्थान तक पहुँचने के लिए सीक्रेट प्रोविज़निंग की आवश्यकता होती है, इसलिए आप किसी ऐसे सिस्टम पर निर्भर होंगे जो डेवलपर्स को रहस्य वितरित करेगा
• डॉकफाइल के अलावा, आपको docker-compose.yml की आवश्यकता होगी, और यह क्रॉस-प्लेटफ़ॉर्म नहीं है: आप अभी भी फ़ॉरवर्ड- /बैकस्लैश अंतर पर निर्भर हैं।

क्रॉस प्लेटफ़ॉर्म संगतता: डॉकरफ़ाइल प्रदान करने के साथ, मुझे पता है कि कोई भी सिस्टम जो डॉकर बिल्ड चला सकता है वह छवि बनाने में सक्षम होगा।

Dockerfile क्रॉस-प्लेटफ़ॉर्म संगतता सुनिश्चित नहीं करता है। आपको अभी भी कई प्लेटफार्मों के लिए कई Dockerfiles प्रदान करना है। "डॉकर बिल्ड चला सकते हैं" का अर्थ अब "लिनक्स का उपयोग करता है" नहीं है। डॉकर विंडोज मूल छवियों का भी समर्थन करता है। यदि आप Windows होस्ट पर Linux मशीनों के लिए विशेष रूप से लक्षित कुछ चलाना चाहते हैं तो आपको अभी भी Cygwin + Linux VM का उपयोग करना होगा।

ओह, और मैंने x86 बनाम एआरएम का भी उल्लेख नहीं किया ...

उपयोगकर्ताओं के लिए ज्ञात इंटरफ़ेस: यदि आप डॉकर को जानते हैं, तो आप किसी भी प्रोजेक्ट के लिए डॉकर बिल्ड के कुछ व्यवहार को जानते हैं, यहां तक ​​​​कि डॉकरफाइल को देखे बिना भी।

जब तक आप नहीं करते। हर कोई जानता है कि बिना पैरामीटर या एकल make कमांड के बैश स्क्रिप्ट कैसे चलाना है। कुछ लोग जानते हैं कि docker build , docker run या docker-compose लिए सभी अलग-अलग कमांड लाइन विकल्पों को सही तरीके से कैसे निर्दिष्ट किया जाए। यह अनिवार्य है कि आपके पास कुछ रैपर बैश या cmd स्क्रिप्ट होगी।

डॉकर लोगों ने जो किया, उसके लिए पूरे सम्मान के साथ, मुझे लगता है कि आप बहुत अधिक पूछ रहे हैं। मुझे डर है कि मोबीप्रोजेक्ट में इतना व्यापक दायरा नहीं है कि सभी विकास कार्यप्रवाहों का समर्थन किया जा सके।

मैं व्यक्तिगत रूप से आपके सभी बिंदुओं का खंडन नहीं करने जा रहा हूं। सबसे पहले, आप निश्चित रूप से हमेशा ऐसी स्थितियों का पता लगा सकते हैं जहां "एकल डॉकरफाइल" दृष्टिकोण बिल्कुल भी काम नहीं करता है। हालांकि, मैं तर्क दूंगा कि आपके द्वारा उठाए गए लगभग सभी बिंदुओं के लिए (जो सभी मान्य और प्रासंगिक हैं), "कस्टम स्क्रिप्ट या मेकफ़ाइल" दृष्टिकोण या तो उतना ही खराब या बदतर है। उदाहरण के तौर पर एक बिंदु:

अधिकांश डेवलपर्स डॉकर बिल्ड के सभी विभिन्न विकल्पों को नहीं जानते हैं, लेकिन लगभग सभी जानते हैं कि बैश स्क्रिप्ट कैसे चलाना है

अगर मैं 10 परियोजनाओं में शामिल हूं, और वे सभी डॉकरफाइल का उपयोग करते हैं, तो मुझे केवल एक बार डॉकर के बारे में जानने की जरूरत है, लेकिन आपके सुझाव से मुझे 10 पूरी तरह से अलग बिल्ड स्क्रिप्ट सीखने की जरूरत है। मैं प्रोजेक्ट फू के build_image.sh लिए कैशे को कैसे मिटा सकता हूं और स्क्रैच से फिर से कैसे शुरू करूं? यह स्पष्ट नहीं है। यदि छवि का निर्माण docker build साथ किया जाता है, तो यह स्पष्ट है (ofc मुझे यह जानने की आवश्यकता है कि docker कैसे काम करता है, लेकिन मुझे build_image.sh निकलने वाली छवि का उपयोग करने के लिए भी ऐसा करने की आवश्यकता है)।

कुल मिलाकर, मुझे लगता है कि मैं और अन्य लोग जो बनाने की कोशिश कर रहे हैं, वह यह है कि / कई / परिदृश्यों के लिए "सिंगल डॉकरफाइल" दृष्टिकोण लोगों के लिए वास्तव में अच्छी तरह से काम करता है (जो कि डॉकटर के इतना लोकप्रिय होने का एक कारण है), विशेष रूप से में ओपन सोर्स वर्ल्ड जहां आमतौर पर सभी संसाधन बिना रहस्यों के सुलभ होते हैं। लेकिन अगर आप उसी पैटर्न को लागू करने का प्रयास करते हैं जो आपको उस संदर्भ में पसंद आया है जहां आपके संसाधनों के हिस्से को एक्सेस करने के लिए क्रेडेंशियल्स की आवश्यकता होती है, तो दृष्टिकोण टूट जाता है। इसे काम करने के लिए तकनीकी रूप से बहुत जटिल तरीकों के कई सुझाव (और कार्यान्वयन) हैं, लेकिन लंबे समय से इसका कुछ भी नहीं हुआ है (यह कई बार ऊपर रखा गया है)। इसलिए हताशा।

मैं सराहना करता हूं कि लोग इसमें प्रयास कर रहे हैं, उदाहरण के लिए #33343 में लिंक किए गए प्रस्ताव के साथ। मेरी पोस्ट इस बात को प्रेरित करने के बारे में है कि कुछ लोग यहां क्या मांगते हैं और क्यों वापस आते रहते हैं।

डॉकर लोगों ने जो किया, उसके लिए पूरे सम्मान के साथ, मुझे लगता है कि आप बहुत अधिक पूछ रहे हैं। मुझे डर है कि मोबीप्रोजेक्ट में इतना व्यापक दायरा नहीं है कि सभी विकास कार्यप्रवाहों का समर्थन किया जा सके।

मुझे ऐसा लगता है कि अधिकांश लोग यहां जो कुछ भी मांग रहे हैं वह कुछ भी नहीं है, लेकिन केवल docker build में रहस्यों का उपयोग करने का एक आसान तरीका है जो आपके कस्टम build_image.sh में उनका उपयोग करने से कम सुरक्षित नहीं है

मुझे खेद है, लेकिन इस टिकट में प्रत्येक व्यक्ति का उपयोग मामला थोड़ा अलग है। वे कोने के मामले हैं और विभिन्न समाधानों की आवश्यकता है।

1. मैं विकास मशीनों पर उत्पादन छवियों को चलाने के लिए चाहता हूँ। डॉकर रजिस्ट्री का प्रयोग करें
2. मैं एक वितरित सीआई प्रणाली चाहता हूं, ताकि प्रत्येक डेवलपर के पास प्रतिलिपि प्रस्तुत करने योग्य निर्माण हो। अपनी परियोजना के निर्माण के लिए docker run का उपयोग करें, सफाई के लिए docker prune का उपयोग करें
3. मैं डोकर छवियों का निर्माण करना चाहता हूं ताकि मैं उन्हें वितरित कर सकूं। एक समर्पित सीआई सर्वर का उपयोग करें जहां आप मल्टीस्टेज बिल्ड चला सकते हैं।

@ वानुआन , इसलिए मुझे लगता है कि आपका दृष्टिकोण मूल रूप से है: मूल वातावरण से अधिक कुछ भी करने के लिए डॉकर बिल्ड का उपयोग न करें। यह एक ऐसा मुद्दा है जिसे बदलने के लिए बनाया गया है। "आपको इसे अलग तरह से करना होगा" समस्या है, समाधान नहीं।

जो लोग इस मुद्दे को आगे बढ़ाते हैं, वे डॉकर छवियों के साथ सरल और अधिक सीधा दृष्टिकोण रखना चाहते हैं, डॉकर सीमाओं के आसपास हैक नहीं करना चाहते हैं।

रुचि रखने वाले किसी भी व्यक्ति के लिए: मैंने संदर्भ बनाने के लिए FTP_PROXY जैसे "मास्क-बाय-डिफॉल्ट" बिल्ड-आर्ग का फायदा उठाने की कोशिश की थी। यह इस तथ्य के संबंध में सुरक्षित है कि docker-build उन नकाबपोश तर्कों को छवि मेटाडेटा और न ही छवि परतों को उजागर नहीं करता है।

36443 इसे SECRET जैसे नाम के एक बिल्ड-आर्ग में विस्तारित करने का एक प्रयास था ताकि हम उपयोगकर्ताओं को इसे गुप्त प्रबंधन समस्या के लिए एक सरल कार्य-आसपास के रूप में उपयोग करने के लिए प्रोत्साहित कर सकें।

हालांकि, काम को यथोचित रूप से खारिज कर दिया गया है, क्योंकि भविष्य में उन बिल्ड-आर्गों की नकाबपोश प्रकृति की गारंटी नहीं है।

उसके बाद मेरी सबसे अच्छी शर्त यह है कि @AkihiroSuda की सलाह का पालन करें, docker build --network या एक अस्थायी tcp सर्वर के माध्यम से रहस्यों को स्टोर/पास करने के लिए आदत जैसे टूल का उपयोग करें, केवल दृश्यमान बिल्ड संदर्भ एकल डॉकर डेमॉन के भीतर रहते हैं, व्यापक रूप से।

आंशिक रूप से टिप्पणी करते हुए, इसलिए मुझे अब से 5 साल बाद अधिसूचना मिलती है, जब डॉकर अंततः हमें उचित क्रेडेंशियल प्रबंधन की दिशा में एक छोटा कदम देने का फैसला करता है .... और साथ ही, उस हैक की रूपरेखा देने के लिए जिसका मैं इस समय उपयोग कर रहा हूं। , दूसरों की मदद करने के लिए, या उसमें छेद करने के लिए जिससे मैं अनजान हूँ।

निम्नलिखित @मुमोशू मुद्दे में, मुझे अंततः बिल्ड सीक्रेट्स के लिए पूर्वनिर्धारित-

तो, अनिवार्य रूप से, मैं इस तरह की मैपिंग के साथ डॉकर-कंपोज़ का उपयोग कर सकता हूं:

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

और फिर, docker-compose.yml फ़ाइल वाले फ़ोल्डर में, NEXUS_USERNAME और NEXUS_PASSWORD के कुंजी-मूल्य जोड़े के साथ ".env" नाम की एक फ़ाइल बनाएं - और वहां उचित मान।

अंत में, Dockerfile में ही, हम अपने रन कमांड को इस प्रकार निर्दिष्ट करते हैं:
रन wget --user $HTTPS_PROXY --password $NO_PROXY

और उन्हें DockerFile में ARGs के रूप में घोषित न करें।

मुझे परिणामी बिल्ड में अभी तक कहीं भी मेरे क्रेडेंशियल्स तैरते हुए नहीं मिले हैं... लेकिन मुझे नहीं पता कि मैं हर जगह देख रहा हूं... और मेरे प्रोजेक्ट के बाकी डेवलपर्स के लिए, उन्हें बस प्रत्येक को यह करना होगा उनके लिए उचित मानों के साथ .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 जैसे अपने स्वयं के तर्क नामों का उपयोग नहीं कर सकते।

इस तरह चाल काम करती है, क्योंकि डॉकर के पास पूर्वनिर्धारित-आर्ग के लिए विशेष व्यवहार होता है, जिसमें आप उन्हें घोषित किए बिना उनका उपयोग कर सकते हैं। और बिना घोषणा किए उनका उपयोग करने से वे कहीं भी लॉग इन नहीं दिखते।

डॉकर-कंपोज़ फ़ाइल के साथ, आप उन पूर्वनिर्धारित तर्कों को और अधिक उचित रूप से नामित करने के लिए मैप कर सकते हैं।

@darmbrust हाँ, उसने चाल
हालाँकि, क्या आपको नहीं लगता कि यह बदबूदार है? कोई बेहतर सुझाव?
धन्यवाद!

यह शायद उतना बदबूदार नहीं है जितना कि tcp पर आपके ssh-agent क्रेडेंशियल्स को उजागर करना
किसी भी स्थानीय प्रक्रिया को चोरी करने के लिए समाज के माध्यम से, लेकिन वास्तव में, जैसा कि किसी भी चीज़ के साथ होता है
रहस्यों से संबंधित, 'डॉकर बिल्ड' वास्तव में बहुत बदबूदार है।

दरअसल, मैं भूल गया था कि मैक के लिए डॉकर यूनिक्स डोमेन को उजागर नहीं कर सकता
osx होस्ट पर कंटेनरों को सॉकेट करता है, जिससे कि a . का और भी अधिक खुल जाता है
जटिल समस्याओं का पिटारा।

मेरा वर्तमान समाधान, Centos VM, GitHub मशीन उपयोगकर्ता खाता चलाएँ
क्रेडेंशियल इसमें जाते हैं, "रॉकर" (पदावनत) टूल का उपयोग करके निर्माण करते हैं।

गुरु, 26 जुलाई 2018 को, 21:49 समीर कुमार, नोटिफिकेशन @github.com ने लिखा:

@darmbrust https://github.com/darmbrust हां, इसने चाल चली ।
हालाँकि, क्या आपको नहीं लगता कि यह बदबूदार है? कोई बेहतर सुझाव?
धन्यवाद!

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/moby/moby/issues/13490#issuecomment-408230125 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAZk5iz1kvCpZ0s65ng4TwL7LmHa9zZvks5uKitDgaJpZM4Eq021
.

यह पूरा बग बदबूदार है। मुझे कोई बेहतर तरीका नहीं मिला... ऊपर कई अन्य दृष्टिकोण हैं, लेकिन मुझे लगता है कि अन्य सभी सुरक्षित लोगों को छवि में जानकारी फीड करने के लिए थोड़ा http सर्वर खड़े होने की आवश्यकता है। शायद कम बदबूदार, लेकिन अधिक जटिलता, अधिक उपकरण, अधिक चलने वाले हिस्से।

सुनिश्चित नहीं है कि किसी को "अच्छा" समाधान मिल गया है ... हम सभी डॉकटर लोगों पर इसके बारे में कुछ करने के लिए इंतजार कर रहे हैं ... अपनी सांस न रोकें, क्योंकि यह बग 2015 में लिखा गया था, और उन्होंने ' टी ने अभी तक एक रोडमैप का प्रस्ताव रखा है, समाधान तो बहुत कम है।

यह इतना सरल और स्पष्ट है, वॉल्यूम बढ़ाने की अनुमति दें, (फ़ाइलें या
निर्देशिका) निर्माण के दौरान कंटेनर में।

यह एक तकनीकी सीमा नहीं है, इसमें रहस्यों को अनुमति नहीं देने का निर्णय है
के व्यवहार को संरक्षित करने के लिए - चेक आउट, रन बिल्ड, समान इनपुट, समान
आउटपुट, यदि आप कैश को अमान्य करना चाहते हैं तो बिल्ड तर्क बदलें ...

समस्या यह है कि अमूर्तन तेजी से टपकता जा रहा है
एक "गुप्त" पाने के लिए सभी प्रकार के कुटिल, असुरक्षित हैक्स का उपयोग करने वाले लोगों के साथ
एक कंटेनर में।

न्यूज़फ्लैश, टीसीपी के माध्यम से आपके एसएसएच कीरिंग को उजागर करना, यहां तक ​​​​कि स्थानीयहोस्ट पर भी नहीं है
सुरक्षित, न तो पर्यावरण चर के माध्यम से क्रेडेंशियल पास कर रहा है (संकेत, रन
ps, या /proc फाइल सिस्टम में झांकना), कमांड तर्क, और पर्यावरण चर सभी, नग्न, दुनिया को देखने के लिए हैं।

गोलंग कोड के डेवलपर्स के लिए यह परंपरागत रूप से एक मुद्दा नहीं रहा है क्योंकि वे कॉपी-पेस्ट करते हैं
एक निर्भरता प्रबंधन उपकरण का उपयोग करने के बजाय उनकी परियोजनाओं में उनकी निर्भरता, गोलांग डेवलपर्स इस अभ्यास को 'विक्रेता' कहते हैं।

अन्य पारिस्थितिक तंत्र में काम करने वाले किसी भी व्यक्ति के लिए जहां निर्माण प्रणाली
Git, या रिपॉजिटरी से निर्भरता प्राप्त करता है जिसके लिए प्रमाणीकरण की आवश्यकता होती है, यह एक बड़ी समस्या है।

मुझे पूरा यकीन है कि कहीं न कहीं कुछ स्टार्टअप नियम हैं,
"यह न मानें कि आप जानते हैं, कैसे, या क्यों, आपके उपयोगकर्ता उत्पाद का उपयोग करते हैं"।

गुरु, 26 जुलाई 2018 को, 22:00 डैन आर्मब्रस्ट, नोटिफिकेशन @github.com ने लिखा:

यह पूरा बग बदबूदार है। मुझे कोई बेहतर तरीका नहीं मिला... वहाँ हैं
ऊपर कई अन्य दृष्टिकोण, लेकिन मुझे लगता है कि अन्य सभी सुरक्षित हैं
जानकारी को फीड करने के लिए थोड़ा http सर्वर खड़े होने की आवश्यकता है
छवि। शायद कम बदबूदार, लेकिन अधिक जटिलता, अधिक उपकरण, अधिक गतिशील
भागों।

सुनिश्चित नहीं है कि किसी को "अच्छा" समाधान मिल गया है ... हम सब फंस गए हैं
इसके बारे में कुछ करने के लिए डॉकर लोगों की प्रतीक्षा कर रहे हैं ... अपना मत पकड़ो
सांस, चूंकि यह बग 2015 में लिखा गया था, और उन्होंने प्रस्तावित भी नहीं किया है
एक रोडमैप अभी तक, बहुत कम समाधान।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/moby/moby/issues/13490#issuecomment-408233258 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAZk5nvbBTj4BAv5TtELNIHhJN8mU0Ctks5uKi38gaJpZM4Eq021
.

@binarytemple हर कोई जिसने कभी डॉकर/

वॉल्यूम एक ऐसा समाधान है जो अपने आप में अविश्वसनीय रूप से टपका हुआ है।
एक प्रस्ताव है, टिप्पणी स्ट्रीम का थोड़ा उल्लेख किया है, जो इसे उचित तरीके से हल करने का प्रयास करता है (https://github.com/moby/moby/issues/33343)

यहां मुख्य बात "काम करने के लिए होने वाली किसी भी अमूर्तता" के बजाय "सही" अमूर्तता प्रदान कर रही है ... हम निश्चित रूप से जानते हैं कि यह इस मामले के अलावा कई लोगों के लिए दर्दनाक है।

बिल्डर पर हाल ही में बहुत काम किया गया है जो अभी तक दिखाई नहीं दे रहा है, लेकिन इस प्रयास का फल आने वाले महीनों में दिखना शुरू हो जाएगा।
आरंभ करने के लिए, डॉकर 18.06 जहाज एक वैकल्पिक बिल्डर कार्यान्वयन के साथ https://github.com/moby/buildkit द्वारा समर्थित है
आप सोच सकते हैं "यह मेरी मदद कैसे करता है?"। बिल्डकिट बहुत सारे निम्न-स्तरीय आदिम प्रदान करता है जो हमें डॉकर बिल्डर में अधिक लचीला होने में सक्षम बनाता है। यहां तक ​​​​कि अपना खुद का बिल्ड पार्सर प्रदान करने में सक्षम होने के लिए (जो एक उन्नत डॉकरफाइल पार्सर से कुछ भी पूरी तरह से अलग हो सकता है)। पार्सर्स "डॉकरफाइल" के शीर्ष पर निर्दिष्ट हैं और केवल कोई भी छवि है जिसे आप फ़ाइल को पार्स करने के लिए उपयोग करना चाहते हैं।

यदि आप वास्तव में अभी कुछ देखना चाहते हैं, तो आप स्वयं बिल्डकिट ले सकते हैं और आज इसके साथ चल सकते हैं, यह कंटेनर के शीर्ष पर बैठता है, आप बहुत जल्दी एक कस्टम एकीकरण बना सकते हैं।

https://github.com/moby/buildkit/pull/522 में बिल्डकिट में गुप्त माउंट समर्थन जोड़ा गया था। वे tmpfs पर सख्ती से दिखाई देते हैं, उन्हें बिल्ड कैश से बाहर रखा गया है और एक कॉन्फ़िगर करने योग्य डेटा स्रोत का उपयोग कर सकते हैं। अभी तक कोई पीआर नहीं है जो इसे डॉकफाइल सिंटैक्स में उजागर करता है लेकिन एक साधारण जोड़ होना चाहिए।

रहस्यों के साथ चित्र बनाने के 2 उपाय हैं।

मल्टी-स्टेज बिल्ड:

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 .

एक छवि निर्माता का उपयोग करना: डॉकर-बिल्ड-विद-रहस्य

@BenoitNorrin क्षमा करें, लेकिन आपने उस पासवर्ड को होस्ट सिस्टम की प्रत्येक प्रक्रिया में उजागर कर दिया है। यूनिक्स सुरक्षा 101 - रहस्यों को कमांड तर्क के रूप में न रखें।

हां, लेकिन कुछ ऐसे उपयोग हैं जहां सुरक्षा थोड़ी कम मायने रखती है:

• आप अपने कंप्यूटर पर निर्माण करना चाहते हैं
• आप अपने एंटरप्राइज सीआई सर्वर (जेनकींस की तरह) पर निर्माण करते हैं। अधिकांश समय यह एक निजी भंडार (नेक्सस, गिट, एनपीएम, आदि) तक पहुंचने के बारे में है, इसलिए आपके सीआई के पास इसके लिए अपनी साख हो सकती है।
• आप डॉकर-मशीन से बनाए गए वीएम का उपयोग कर सकते हैं और इसे बाद में हटा सकते हैं।

यदि यही एकमात्र समस्या है, @binarytemple , तो बस ध्वज जोड़ना docker image build --args-file ./my-secret-file इस पूरी समस्या के लिए एक बहुत ही आसान समाधान होना चाहिए, है ना? :विचारधारा:

@yajo हो सकता है, हाँ यह कम से कम एक वर्कअराउंड है जब तक कि बिल्डकिट जहाजों के साथ रहस्य माउंट नहीं होते हैं। अच्छा सुझाव। धन्यवाद। बी

दुर्भाग्य से इनमें और कई अन्य टिकटों में उल्लिखित अधिकांश कामकाज अभी भी परिणामी छवि के रहस्यों को उजागर करते हैं, या केवल विशिष्ट भाषाओं के साथ काम करते हैं जहां आपको केवल संकलन समय के दौरान निर्भरता की आवश्यकता होती है, न कि स्थापना के दौरान।

@binarytemple जो कभी नहीं होगा, डॉकर अनुरक्षकों ने पहले से ही कम से कम एक पीआर को पूरी तरह से प्रलेखित और एक सुरक्षित गुप्त सुविधा के पूरी तरह से लागू कर दिया है। शेष इतिहास को देखते हुए (यह 3 साल पुराना टिकट सबसे पुराना नहीं है और निश्चित रूप से इस विषय पर एकमात्र टिकट/पीआर नहीं है) मुझे लगता है कि यह कहना सुरक्षित है कि डॉकर रखरखावकर्ता सुरक्षा की आवश्यकता को नहीं समझते हैं, जो एक बड़ा है संकट।

सबसे बड़ा दर्द बिंदु मेरे लिए गुप्त घुमाव है

आपको सेवा निर्भरताओं के लिए रहस्य का ग्राफ बनाए रखना होगा, और प्रत्येक सेवा को दो बार अपडेट करना होगा (मूल गुप्त नाम पर वापस जाने के लिए)

सेवाओं से रहस्य सूचीबद्ध करना आसान नहीं लगता (मैंने docker service inspect --format='{{.Spec.TaskTemplate.ContainerSpec.Secrets}}' <some_service> आसपास कुछ प्रयासों के बाद छोड़ दिया), docker secret inspect <secret_name> से सेवाओं की निर्भरता को सूचीबद्ध करना भी उपयोगी होगा। तो मैं अभी के लिए मैन्युअल रूप से उस (अनुमानित) ग्राफ को बनाए रखता हूं।

आपको गुप्त गंतव्य भी निर्दिष्ट करना होगा, जब यह docker service update कमांड में डिफ़ॉल्ट /run/secrets/<secret_name> है

मैं बस रहस्यों को घुमाने के एक आसान तरीके की आशा करता हूँ

@caub यहां कुछ सीएलआई सहायता है:

स्वरूपण सहायता के

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 स्वचालन सही रहस्य की पहचान कर सकते हैं।

docker build --secret अंततः डॉकर 18.09 में उपलब्ध है https://medium.com/@tonistiigi/build -secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066

@thaJeztah क्या हम इस मुद्दे को बंद करने के लिए तैयार हैं?

डॉकटर के पुराने संस्करणों के लिए, बिल्ड कमांड से पहले कॉपी सीक्रेट्स के साथ मल्टीस्टेज बिल्ड का उपयोग करना व्यवहार्य विकल्प है, है ना?

```
निर्माण के रूप में डेबियन से
कॉपी ./secret.conf /path/on/image/
रन बिल्ड.शो
...

डेबियन से
कॉपी --from=बिल्ड...

@ एंड्री-एफ हाँ, यह तब तक काम करता है जब तक आप;

• (जाहिर है) रहस्य को अंतिम चरण में कॉपी न करें , या:
• build चरण / चरण का उपयोग करें जिसमें अंतिम छवि के लिए "अभिभावक" के रूप में एक रहस्य मौजूद है
• रजिस्ट्री में बिल्ड-स्टेज को कभी भी _push_ नहीं करें
• उस मेजबान पर भरोसा करें जिस पर आपका डेमॉन चलता है; यानी यह ध्यान में रखते हुए कि आपका "बिल्ड" चरण एक छवि के रूप में संरक्षित है; उस छवि तक पहुंच रखने वाला कोई व्यक्ति आपके रहस्य तक पहुंच प्राप्त करने में सक्षम होगा।

बिल्डकिट को बिल्डर के रूप में उपयोग करते समय बिल्ड टाइम सीक्रेट्स अब संभव हैं; ब्लॉग पोस्ट यहाँ देखें 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 मैंने बस थोड़ी और खुदाई की और पोस्ट करने के तुरंत बाद उस लेख को पाया (पिछली पोस्ट अब हटा दी गई है)। एक बार फिर धन्यवाद!

ठंडा। यह बिल्ड टाइम सीक्रेट्स प्रश्न को बंद कर देता है। रनटाइम/डेवटाइम के लिए कुछ भी (ओएस एक्स में एसएसएच)?