moby 🚀 - --insecure-रजिस्ट्री "docker pull" पर होनी चाहिए

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

octalthorpe 31 अक्तू॰ 2014

👍3

और जब आप रजिस्ट्री चलाने के लिए एक निश्चित पोर्ट का उपयोग नहीं करते हैं तो चिकन और अंडे की समस्या होती है।

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

proppy 31 अक्तू॰ 2014

:+1:

reinh 31 अक्तू॰ 2014

तो मुझे लगता है कि --insecure कमांड लाइन पर docker pull करना, सुरक्षा जांच को जबरदस्ती अक्षम करना, जाहिर तौर पर _this_ pull कमांड के लिए, आपको @proppy और @octalthorpe की समस्या का समाधान भी होगा? जैसा कि इस ध्वज के साथ चलने से सूचियों की जाँच नहीं होगी

abourget 31 अक्तू॰ 2014

@abourget इसे दूरस्थ API में भी समर्थित होने की आवश्यकता है।

वर्तमान में docker-py insecure_registry pull फ़ंक्शन पर https://github.com/docker/docker-py/blob/master/ docker/client.py#L794

proppy 31 अक्तू॰ 2014

अपराधी लगता है https://github.com/docker/docker/commit/6a1ff022b0744213ed588d9c16dbb13ce055eda6

लेकिन मुझे वह संबंधित पीआर या मुद्दे नहीं मिले जहां उस बदलाव पर चर्चा की गई थी।

@tiborvass कोई विचार?

proppy 31 अक्तू॰ 2014

@proppy - इसे एक प्रतिबंधित सुरक्षा भेद्यता के रूप में संभाला गया था और सार्वजनिक पीआर में चर्चा नहीं की गई थी। कोर टीम के पास इस मुद्दे पर दृश्यता और वोट था।

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

ewindisch 31 अक्तू॰ 2014

@ewindisch दूसरी ओर पहले से ही बहुत सारे localhost ।

यदि सचमुच उन सभी उपयोगकर्ताओं को --insecure-registry localhost:5000 पास करने की आवश्यकता होगी, तो आप इसे डिफ़ॉल्ट भी बना सकते हैं।

proppy 31 अक्तू॰ 2014

@ewindisch क्या आप लोगों के पास

mmdriley 31 अक्तू॰ 2014

@mmdriley -

संपादित करें: सीवीई विवरण के लिए लिंक जोड़ना: https://groups.google.com/d/msg/docker-user/oYm0i3xShJU/0QbAw9eN9qkJ

ewindisch 31 अक्तू॰ 2014

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

जैसा कि ऊपर सुझाव दिया गया है, संगतता को तोड़े बिना तुरंत सुरक्षा में सुधार करने के स्पष्ट तरीके थे। उदाहरण के लिए, index.docker.io और कुछ अन्य लोकप्रिय सार्वजनिक रजिस्ट्रियों के लिए HTTPS फ़ॉलबैक को अक्षम करने से अधिकांश उपयोगकर्ताओं के लिए समस्या प्रभावी रूप से हल हो जाती। कंसोल आउटपुट में एक चेतावनी जोड़ने से कि HTTP फ़ॉलबैक हो रहा था, इंटरैक्टिव केस को कम कर देता। HTTP फ़ॉलबैक को अगले महीने की रिलीज़ में बहिष्कृत और हटा दिया जाएगा। अंत में, लोकलहोस्ट और ::1 स्पष्ट रूप से कमजोर नहीं हैं।

फिर से, मुझे भेद्यता की सीमा में छूट नहीं देनी चाहिए थी, लेकिन मुझे चिंता है कि प्रतिक्रिया प्रक्रिया और फिक्स ने ग्राहकों को नहीं तोड़ने पर पर्याप्त मूल्य नहीं डाला।

mmdriley 31 अक्तू॰ 2014

हम वर्तमान में ऐसे वातावरण में डॉकर रजिस्ट्रियों को गतिशील रूप से बना/नष्ट कर रहे हैं जिसमें इनमें से कई उदाहरणों के लिए FQDN उपलब्ध नहीं है। रजिस्ट्री से संबंधित अनुरोधों (दूरस्थ एपीआई पर) के लिए एक --insecure-repository विकल्प का समर्थन करने से इस सुरक्षा सुधार ने हमारे लिए बनाई गई महत्वपूर्ण जटिलताओं को दूर कर दिया है।

jwthomp 3 नव॰ 2014

हमें डॉकर 1.3.1 के साथ भी ऐसी ही समस्या है। हम http://docker :5000/ पते पर स्थानीय (निजी) डॉकर रजिस्ट्री का उपयोग करते हैं। डॉकर 1.3.0 तक यह ठीक काम करता था। डॉकर संस्करण 1.3.1 के साथ यह अब और काम नहीं करता है क्योंकि डॉकर क्लाइंट स्वचालित रूप से मानता है कि रजिस्ट्री HTTPS पर उपलब्ध है। लेकिन हम HTTPS का इस्तेमाल बिल्कुल भी नहीं करते हैं।

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

kruxik 4 नव॰ 2014

@kruxik यदि आप डेमॉन शुरू करते समय --insecure-registry docker:5000 करते हैं, तो यह HTTP पर वापस आ जाएगा।

tiborvass 4 नव॰ 2014

@tiborvass सुझाव के लिए धन्यवाद। ठीक कह रहे हैं आप। लेकिन अगर आपके पास अपने वर्कस्टेशन और नोटबुक के साथ बहुत सारे डेवलपर हैं, तो प्रत्येक स्टेशन पर --insecure-registry सेट करना एक तरह से अव्यावहारिक है। कम से कम इसे पुल/पुश संचालन के लिए वैकल्पिक पैरामीटर के रूप में हमारे लिए पर्याप्त होगा;)

kruxik 4 नव॰ 2014

+1

इसने हमारे लिए 1.3.0 के साथ काम किया, लेकिन 1.3.1 . के साथ

डोकर संस्करण
....
सर्वर संस्करण: 1.3.1
....
डॉकटर पुश 10.121.4.236:5000/debian7/consul
-> ....यदि यह निजी रजिस्ट्री अज्ञात CA प्रमाणपत्र के साथ केवल HTTP या HTTPS का समर्थन करती है, तो कृपया डेमन के तर्कों में --insecure-registry 10.121.4.236:5000 जोड़ें। HTTPS के मामले में, यदि आपके पास रजिस्ट्री के CA प्रमाणपत्र तक पहुंच है, तो ध्वज की कोई आवश्यकता नहीं है; बस सीए प्रमाणपत्र को यहां रखें

ढाल
सर्वर संस्करण: 1.3.0
डॉकटर पुश 10.121.4.236:5000/debian7/consul
-> कंटेनर बिना किसी समस्या के अपलोड करता है।

epankala 5 नव॰ 2014

1.3.0 से 1.3.1 तक की समस्या वाले अन्य लोगों के लिए, मुझे OS X के लिए boot2docker के साथ निम्नलिखित परिवर्तन करने पड़े:

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

तो आप _चाहिए_ एक डोकर पुल करने में सक्षम हो।

यदि अंजीर का उपयोग कर रहे हैं, तो आपको चित्र 1.0.1 की भी आवश्यकता है और करें:

$ fig up --allow-insecure-ssl

mhamrah 5 नव॰ 2014

@ महमरा धन्यवाद! इसे ठीक करने में घंटों लगा...

jdongelmans 6 नव॰ 2014

+1 स्थानीयहोस्ट मानने के लिए सुरक्षित है। क्या वास्तव में कोई इसके खिलाफ है?

thockin 6 नव॰ 2014

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

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

jasonwatt 6 नव॰ 2014

@thocking : https://github.com/docker/docker/issues/8898 देखें

proppy 6 नव॰ 2014

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

इस चर्चा में मुझे क्या याद आ रहा है:
मुझे डेमॉन को प्रत्येक होस्ट के लिए "डिफ़ॉल्ट" सुरक्षित/असुरक्षित मोड का उपयोग करने के लिए क्यों कहना है?

क्या इस डिफ़ॉल्ट व्यवहार के साथ रजिस्ट्री को सेटअप करना अधिक उत्पादक नहीं होना चाहिए?
तो सेटअप के आधार पर यदि कोई --secure या --insecure पैरामीटर नहीं दिया जाता है तो डेमॉन को अनुरोध करना चाहिए
यदि सुरक्षित तरीका संभव है और यदि नहीं तो असुरक्षित पर फॉलबैक का उपयोग किया गया था।

डॉकर की मुख्य चीजों में से एक यह है कि इसका उपयोग करना पूरी तरह से आसान है और एक पूर्ण एनवी स्थापित करना है। कृपया इस तरह के "रिलीज / निर्णय" के साथ इस वाह प्रभाव को न मारें ...

बस मेरे 2 सेंट...

bjneuhaus 7 नव॰ 2014

@jwthomp सहित उपरोक्त लोगों के लिए भी इसी तरह के मुद्दे। मैंने इस समस्या को हल करने के लिए 10+ घंटे का अच्छा समय बिताया है और इस बीच डॉकर 1.3.0 में डाउनग्रेड किया है।

मैं मैराथन और डॉकर रजिस्ट्री के तहत डॉकर रजिस्ट्री चला रहा हूं वर्तमान में "एक दृश्यपटल के रूप में nginx चलाकर एसएसएल का समर्थन करता है" (देखें https://github.com/docker/docker-registry/issues/697 ) लेकिन एक दृश्यपटल के रूप में nginx का उपयोग करना है विभिन्न दास मेजबानों/बंदरगाहों पर डॉकटर रजिस्ट्री चलाने वाले मैराथन द्वारा जटिल।

मैं एसएसएल को सीधे रजिस्ट्री के भीतर सक्षम कर सकता था (GUNICORN_OPTS का उपयोग करके) लेकिन फिर यह _only_ एसएसएल बोलता है और मैराथन स्वास्थ्य जांच पास नहीं कर सकता।

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

आरसीई से बचाव के लिए यह सब बहुत अच्छा है लेकिन कुछ पिछड़ी संगतता भी होनी चाहिए। सभी रजिस्ट्रियों को असुरक्षित के रूप में निर्दिष्ट करने के लिए डॉकर डेमॉन के लिए कम से कम एक ध्वज। प्रत्येक docker pull कमांड में रजिस्ट्री नाम के भाग के रूप में http या https निर्दिष्ट करने का एक तरीका होना चाहिए। फिलहाल, 1.3.1 निजी रजिस्ट्री का उपयोग करने वाले किसी भी व्यक्ति के लिए एक बड़ा कैच -22 जैसा लगता है।

nickandrew 9 नव॰ 2014

@महमराह https://github.com/boot2docker/boot2docker/pull/630

knownasilya 14 नव॰ 2014

अच्छा।
शुक्र, 14 नवंबर, 2014 को सुबह 10:42 बजे इल्या रेडचेंको नोटिफिकेशन @github.com
लिखा था:

@महमराह https://github.com/mhamrah boot2docker/boot2docker#630
https://github.com/boot2docker/boot2docker/pull/630
-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/docker/docker/issues/8887#issuecomment -63082089।

mhamrah 14 नव॰ 2014

@mhamrah मुझे ssh कीज़ आदि को हटाने की ज़रूरत नहीं थी। मैंने अभी/var/lib/boot2docker/profile में आवश्यक लाइन जोड़ी और docker को पुनरारंभ किया। पारितोषिक के लिए धन्यवाद!

ksylvan 20 नव॰ 2014

ठंडा। मुझे ssh'ing करने में भी परेशानी हुई, मुझे लगता है कि कुछ संस्करण के कारण
डोकर आईएसओ के बीच बेमेल। मैंने वास्तव में योनि + . का उपयोग करने के लिए स्विच किया
docker समर्थन के लिए coreos, और यह अच्छी तरह से काम करता है। आपको बस सेट करने की जरूरत है
DOCKER_HOST, जो boot2docker स्वचालित रूप से करता है।

गुरु नवंबर 20 2014 को 1:52:21 पूर्वाह्न पर कायवन सिल्वन नोटिफिकेशन @github.com
लिखा था:

@mhamrah https://github.com/mhamrah मुझे हटाने की ज़रूरत नहीं थी
ssh कुंजियाँ, आदि। मैंने अभी-अभी आवश्यक पंक्ति जोड़ी है
/var/lib/boot2docker/profile और पुनरारंभ docker. पारितोषिक के लिए धन्यवाद!
-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/docker/docker/issues/8887#issuecomment -63768043।

mhamrah 20 नव॰ 2014

क्षमा करें दोस्तों, मेरा मतलब पहले जवाब देना था।

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

tiborvass 25 नव॰ 2014

आधिकारिक डॉकर रजिस्ट्री पर डॉकर रजिस्ट्री की "आधिकारिक" डॉकर आधारित छवि है। यह अनुशंसित उपयोग टीएलएस के बिना है ।

डोकर उनकी रजिस्ट्री पर सेटअप टीएलएस को उपयोगकर्ताओं के लिए यह एक आधिकारिक डोकर छवि प्रदान करके भावना "दर्द प्रेरित" एक समान और विपरीत "दर्द में कमी" के साथ संतुलित करने के लिए नहीं होगा चाहते हैं, तो यह है कि टीएलएस प्रदान करने के लिए चूक?

sroebuck 26 नव॰ 2014

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

blevine 26 नव॰ 2014

👍8

सभी निजी ips को श्वेतसूची में डालने के बारे में क्या? बीच का रास्ता?

mhamrah 26 नव॰ 2014

या प्रोटोकॉल नाम, 'http' या 'https' को पुल के लिए छवि नाम का हिस्सा बनाना।

nickandrew 26 नव॰ 2014

दोनों @sroebuck @tiborvass और @blevine महान अंक हैं। यह तेजी से घर में कंटेनर बनाने वाली दुकानों के लिए परिदृश्य बन जाएगा, और पिछले वर्कफ़्लो को तोड़ने पर रोष भी बढ़ेगा। हम सभी इसके सुरक्षा पक्ष को समझते हैं, और शायद इसे हल करने के लिए पुल सही जगह नहीं है, लेकिन जब तक आधिकारिक रजिस्ट्री छवि इस बदलाव से निपटने के लिए एक सरल, आउट ऑफ द बॉक्स तरीका प्रदान नहीं करती है, तब तक इसे करना चाहिए हल करने के लिए एक बहुत ही महत्वपूर्ण UX समस्या मानी जानी चाहिए।

justinclayton 26 नव॰ 2014

अरे @tiborvass ! यह मुद्दा इस समय हमें भी काट रहा है। मैं @nickandrew के दृष्टिकोण को पसंद करता

davidhoyt 26 नव॰ 2014

@blevine ध्यान दें कि 1.3.2 localhost डिफ़ॉल्ट रूप से श्वेतसूची में है, देखें: https://github.com/docker/docker/pull/9124

आप स्थानीयहोस्ट पर रजिस्ट्री को सुन सकते हैं: -p 127.0.0.0:5000:5000 से docker run

proppy 26 नव॰ 2014

@proppy , मुझे पूरा यकीन नहीं है कि लोकलहोस्ट पर सुनने से मुझे कैसे मदद मिलती है।

blevine 1 दिस॰ 2014

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

या यह एक वास्तविक URL बन जाना चाहिए? मुझे रजिस्ट्री प्रोटोकॉल के बारे में कुछ भी पता नहीं है, लेकिन एक उचित URL निर्दिष्ट करने के लिए वर्तमान सिंटैक्स का विस्तार करना असंगत नहीं लगता।

nickandrew 1 दिस॰ 2014

@blevine इसका मतलब है कि आप एक स्थानीय मिररिंग रजिस्ट्री सेट कर सकते हैं।

SvenDowideit 2 दिस॰ 2014

Arg, अब मुझे अपनी मशीनों को शुरू करने के लिए कोरोस के लिए अपने क्लाउड-कॉन्फ़िगरेशन को बेस 64 डीकोड करना होगा

mattwilliamson 9 दिस॰ 2014

@tiborvass वाह, यह वास्तव में दुर्भाग्यपूर्ण है। :(

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

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

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

jwthomp 9 दिस॰ 2014

@टिबोरवास +1। +1000. इसने के लिए बिल्कुल अनावश्यक जटिलता उत्पन्न की है
हमें एक अत्यधिक गतिशील विकास कार्यप्रवाह के लिए। प्रवेश में बाधा रही है
किसी ऐसी चीज़ के लिए यहाँ महत्वपूर्ण रूप से उठाया गया है जिसे केवल a . में लागू करने की आवश्यकता है
उत्पादन संदर्भ। कृपया हमारा दर्द समाप्त करें।

मंगलवार, 9 दिसंबर 2014 को, जेफ थॉम्पसन नोटिफिकेशन @
लिखा था:

@tiborvass https://github.com/tiborvass वाह, यह उनमें से एक है
वर्चुअल टेबल फ़्लिपिंग पल दुख की बात है। :(
हमारे पास विकास क्लस्टर हैं जिन्हें हम फ्लाई और पार्ट पर ऊपर और नीचे लाते हैं
हम इन समूहों को कैसे संभालते हैं, हम उस क्लस्टर के लिए एक रजिस्ट्री बनाते हैं। ए
क्लस्टर कई भौतिक नोड्स या वीएमएस हो सकता है, और यह एक पर भी हो सकता है
डेवलपर्स डेस्कटॉप मशीन या लैपटॉप (हालांकि हम आम तौर पर लॉन्च नहीं कर सकते हैं)
पूर्ण हो चुकी है)। प्रत्येक क्लस्टर पूरी तरह से स्व-निहित स्टैक और विकास है
वातावरण। हमारे पास डॉकर आधारित कमांड लाइन टूल भी हैं जो a . की अनुमति देते हैं
डेवलपर कंपनी में किसी भी विकास क्लस्टर सेटअप के साथ बातचीत करने के लिए।
इस तरह के जटिल और गतिशील वातावरण में, TLS को एक रजिस्ट्री पर बनाना
एक आवश्यकता विशाल दर्द है। डॉकर डेमॉन स्टार्टअप को संशोधित करने के बाद
हर बार जब हम सेटअप करते हैं तो हम एक नया नेटवर्क जोड़ते हैं जिस पर रजिस्ट्री हो सकती है
समान रूप से एक दर्द।
मुझे गलत मत समझो, मैं समर्थन करने के पीछे की सोच की सराहना करता हूं
टीएलएस, हालांकि ऐसे मामले हैं जहां पर्यावरण सुरक्षित रूप से हटाने का समर्थन करता है
आवश्यक दर्द और बुनियादी ढांचे में कमी के लिए टीएलएस की जटिलता
इसका समर्थन करने के लिए।
-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/docker/docker/issues/8887#issuecomment -66367681।

justinclayton 10 दिस॰ 2014

@justinclayton @jwthomp @mattwilliamson @nickandrew @blevine

क्या --insecure-registry 0.0.0.0/8 आपकी समस्या का समाधान नहीं करता है? इस तरह आप अभी भी HTTP का उपयोग कर सकते हैं।

tiborvass 10 दिस॰ 2014

यह CIDR संकेतन "--insecure-रजिस्ट्री 172.16.0.0/12" जैसी श्रेणियों को निर्दिष्ट करके "फ़ायरवॉल के पीछे" कॉन्फ़िगरेशन को सक्षम करने के लिए अधिक बारीक रूप से उपयोग किया जा सकता है। मैं इस विकल्प का उपयोग करने की बिल्कुल भी सलाह नहीं देता, लेकिन मैं अनुशंसा करता हूं कि उपयोगकर्ता इस विकल्प को चुनने के लिए 0.0.0.0/8 के साथ यथासंभव सभी पतों के बजाय अधिक चयनात्मक श्रेणी (जैसे कि उनका आईपी स्थान) का उपयोग करें।

ewindisch 10 दिस॰ 2014

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

यह हमें साझा किए गए php होस्ट के लिए php.ini फ़ाइल को बदलने के लिए कहने के बराबर है।

9 दिसंबर 2014 को 22:18 बजे, टिबोर वास नोटिफिकेशन @github.com ने लिखा:
@justinclayton @jwthomp @mattwilliamson @nickandrew @blevine
क्या --insecure-रजिस्ट्री 0.0.0.0/8 आपकी समस्या का समाधान नहीं करती है? इस तरह आप अभी भी HTTP का उपयोग कर सकते हैं।
-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

mattwilliamson 10 दिस॰ 2014

👍1

@mattwilliamson निष्पादन झंडे CoreOS के साथ विन्यास योग्य हैं। आप डॉकर के लिए सिस्टमड कॉन्फ़िगरेशन फ़ाइल को संपादित कर सकते हैं। क्लस्टर के लिए इसे कॉन्फ़िगर करने के लिए, आप क्लाउड-कॉन्फ़िगरेशन का उपयोग कर सकते हैं।

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

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

ewindisch 10 दिस॰ 2014

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

लब्बोलुआब यह है कि इसे क्लाइंट-साइड तर्क बनाना स्पष्ट रूप से कम विघटनकारी समाधान है, और इससे भी महत्वपूर्ण बात यह है कि कम निर्देशात्मक समाधान। डॉकर पहले से ही दर्जनों में एक आदिम बन गया है यदि सैकड़ों अन्य परियोजनाएं और वर्कफ़्लो नहीं हैं, और इस तरह वास्तव में इस दायरे में उपयोग के पैटर्न को निर्धारित नहीं करना चाहिए। सिर्फ इसलिए कि Git http.sslverify को अक्षम करने के लिए एक सरल रनटाइम कॉन्फ़िगरेशन विकल्प प्रदान करता है, इसका मतलब यह नहीं है कि Linus Torvalds लोगों को अपने संवेदनशील डेटा को उन संदर्भों में सुरक्षित नहीं करने के लिए प्रोत्साहित करता है जहां ऐसा करना महत्वपूर्ण है।

justinclayton 10 दिस॰ 2014

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

CIDR संकेतन यकीनन "भारी हथौड़ा" दृष्टिकोण की अनुमति देता है, और AFAIK, dns नामों के लिए मैप नहीं करता है, इसलिए भले ही मैं 10.0.0.0/16 को मास्क करता हूं, 10.0/16 जीता में some.private-registry.com खींच रहा है। टी काम। इससे भी महत्वपूर्ण बात, विन्यास तुच्छ नहीं है।

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

एक नया डेवलपर आसानी से docker pull स्निपेट को कॉपी और पेस्ट कर सकता है, लेकिन उन्हें एक boot2docker होस्ट में ssh करके, vi चलाएं, एक कॉन्फ़िग फ़ाइल संपादित करें, फिर त्रुटियों के लिए एक syslog को पूंछें ... इतना नहीं। और ओह हाँ, आप डॉकर डेमॉन को पुनरारंभ करना भूल गए।

यहाँ मैं क्या देखना चाहता हूँ:

डॉकर डेमॉन सेटिंग्स को डॉकर कमांड के माध्यम से लागू किया जाता है
डॉकर कमांड के माध्यम से निर्दिष्ट टीएलएस ओवरराइड के लिए डॉकर पुल सेटिंग्स
एक विशिष्ट रजिस्ट्रियों के लिए कमांड में संरक्षित डॉकर पुल सेटिंग्स

mhamrah 10 दिस॰ 2014

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

9 दिसंबर 2014 को 23:55 बजे, एरिक विंडिश नोटिफिकेशन @github.com ने लिखा:
निष्पादन झंडे CoreOS के साथ विन्यास योग्य हैं। आप डॉकर के लिए सिस्टमड कॉन्फ़िगरेशन फ़ाइल को संपादित कर सकते हैं। क्लस्टर के लिए इसे कॉन्फ़िगर करने के लिए, आप क्लाउड-कॉन्फ़िगरेशन का उपयोग कर सकते हैं।
डॉकर कॉन्फ़िगरेशन बदलने के उदाहरण CoreOS वेबसाइट पर हैं। इसके बजाय एक असुरक्षित-रजिस्ट्री ध्वज निर्दिष्ट करने के लिए डीबग-फ्लैग जोड़ने के निर्देशों को आसानी से संशोधित किया जा सकता है।
https://coreos.com/docs/launching-containers/build/customizing-docker/
-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

mattwilliamson 10 दिस॰ 2014

मुझे वर्तमान में हर बार जब मैं 'boot2docker up' करता हूं, तो इस श्रमसाध्य शोधित कमांड को चलाकर अपनी कंपनी के विकास के माहौल में इस मुद्दे के आसपास काम करना पड़ता है।

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

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

CleanCut 12 दिस॰ 2014

@CleanCut बहुत अच्छी तरह से रखा गया है। वास्तव में निराश था कि 1.4.0 आया और चला गया और यह मुद्दा खुला रहता है।

justinclayton 13 दिस॰ 2014

@CleanCut भयानक - मुझे boot2docker init प्रारंभिक पेलोड में अधिक जानकारी जोड़ना है, जो तब आपके लिए ऐसा करेगा।

गैर-vm-आधारित-boot2docker विशिष्ट समस्याओं का समाधान नहीं करता है, लेकिन --insecure-registry केवल साइट विशिष्ट अनुकूलन b2d उपयोगकर्ता नहीं चाहते हैं।

क्या आप इसके लिए boo2docker रेपो में पुल अनुरोध या मुद्दा बना सकते हैं?

SvenDowideit 15 दिस॰ 2014

बाधाओं को कम करने के लिए सराहना की गई परियोजना का उपयोग करने के लिए किसी के लिए वास्तव में बाधा उठाता है।

13 दिसंबर 2014 को 02:10 बजे, जस्टिन क्लेटन नोटिफिकेशन @github.com ने लिखा:
@CleanCut बहुत अच्छी तरह से रखा गया है। वास्तव में निराश था कि 1.4.0 आया और चला गया और यह मुद्दा खुला रहता है।
-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

mattwilliamson 15 दिस॰ 2014

@SvenDowideit ज़रूर बात। यह रहा

CleanCut 15 दिस॰ 2014

ऐसा लगता है कि इस सूत्र में सर्वसम्मति है कि यह कोई हल समस्या नहीं है; क्या हम कृपया इस मुद्दे को फिर से खोल सकते हैं?

justinclayton 15 दिस॰ 2014

जी बोलिये!
ले २०१४-१२-१५ १५:०५, "जस्टिन क्लेटन" नोटिफिकेशन @github.com एक लेख :

ऐसा लगता है कि इस सूत्र में सर्वसम्मति है कि यह हल नहीं है
संकट; क्या हम कृपया इस मुद्दे को फिर से खोल सकते हैं?
-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/docker/docker/issues/8887#issuecomment -67055878।

abourget 16 दिस॰ 2014

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

seanmcl 16 दिस॰ 2014

@bfirsh - यह उन उदाहरणों में से एक है जहां एक डॉकर डेमॉन कॉन्फ़िगरेशन फ़ाइल और kill -HUP <dockerdaemonpid> कमाल होगी - इसे cfg को फिर से पढ़ने के लिए ट्रिगर करें, इसे पुनरारंभ करने की आवश्यकता के बिना - इस प्रकार कंटेनर-पुनरारंभ से बचें

SvenDowideit 16 दिस॰ 2014

@SvenDowideit +1 पुनः लोड सुविधा के लिए, सरल कॉन्फ़िगरेशन द्वारा सर्वर को पुनरारंभ करना वास्तव में कष्टप्रद है।

larrycai 16 दिस॰ 2014

+1

mingfang 17 दिस॰ 2014

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

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

pohl 18 दिस॰ 2014

+1 इस चर्चा को फिर से खोलने के लिए, क्योंकि ऐसा लगता है कि समुदाय वर्तमान समाधान से वास्तव में खुश नहीं है।

dgolja 31 दिस॰ 2014

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

जब तक हम इस विषय पर एक निश्चित उत्तर नहीं सुन लेते, तब तक इसे सभी कोणों से हिट करने का प्रयास कर रहे हैं।

justinclayton 31 दिस॰ 2014

+1, वर्तमान में कॉन्फ़िगर करना और काम करना मुश्किल है।

@mhamrah महान अंक बनाता है। चीजों को बाध्य न करें, उपयोगकर्ताओं को अपनी जरूरतों के लिए निर्णय लेने और कॉन्फ़िगर करने दें।

jaytaylor 25 जन॰ 2015

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

मेरा मानना है कि इस थ्रेड पर पोस्ट किया गया हर कोई मूल्य और लाभ देखता है
डॉकटर के, इसे दैनिक उपयोग कर रहे हैं, इसे अपने में बढ़ावा देने की कोशिश कर रहे हैं
संगठन, लेकिन एक दर्दनाक और अनावश्यक समस्या का सामना कर रहे हैं कि
गोद लेने में बाधा डालता है।

जितना हम सभी docker को जानते हैं तकनीक में बहुत से लोगों के लिए यह अभी भी अज्ञात है-
विशेष रूप से उद्यम के भीतर। दस्तावेज़ीकरण मदद करता है, लेकिन हम अभी भी हैं
हुप्स के माध्यम से कूदना, और यह एक नकारात्मक समग्र के साथ एक बड़ा अवरोधक है
प्रभाव।
सूर्य पर, २५ जनवरी २०१५ को शाम ५:५४ बजे जे टेलर सूचनाएं @github.com ने लिखा:

+1, वर्तमान में कॉन्फ़िगर करना और काम करना मुश्किल है।
@mhamrah https://github.com/mhamrah महान अंक बनाता है। जबरदस्ती मत करो
चीजें, उपयोगकर्ता की अपनी जरूरतों के लिए निर्णय लेने और कॉन्फ़िगर करने दें।
-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/docker/docker/issues/8887#issuecomment -71398193।

mhamrah 26 जन॰ 2015

+1 चीजों को जल्दी से आज़माने के लिए अच्छा है

NoumanSaleem 27 जन॰ 2015

:+1:

ChiChou 29 जन॰ 2015

:+1:

jsdir 1 फ़र॰ 2015

बहुत निराशाजनक है कि हम अभी भी असुरक्षित रजिस्ट्रियों से डॉकर डेमॉन को ध्वज पारित किए बिना खींच नहीं सकते हैं। हमारे द्वारा परिनियोजित प्रत्येक नई मशीन के लिए यह एक और परेशानी है।

toddbu 11 फ़र॰ 2015

+1

कुछ विचार:

क्या हमारे पास होस्टनाम वाइल्डकार्ड हो सकते हैं? उदाहरण के लिए --insecure-registry=*.internal
क्या स्व-हस्ताक्षरित सेर्ट्स को http से अलग तरीके से व्यवहार किया जा सकता है?
2 से संबंधित, क्या डॉकर एसएसएच के समान कुछ कर सकता है और उपयोगकर्ता को एक स्व-हस्ताक्षरित प्रमाणपत्र स्वीकार करने के लिए प्रेरित कर सकता है जब भी वह कोई नया देखता है/कोई मेल नहीं खाने पर जोर से शिकायत करता है?

aidanhs 15 फ़र॰ 2015

और जब मैं सुझाव दे रहा हूं, तो क्यों न स्थानीयहोस्ट को हमेशा सुरक्षित माना जाए? (जैसा कि क्रोम करता है)

संपादित करें: आह, मैं देखता हूं कि यह पहले से ही है।

aidanhs 15 फ़र॰ 2015

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

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

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

agquick 17 फ़र॰ 2015

@agquick की टिप्पणी हाजिर है, विशेष रूप से wrt "अच्छा होना" सुविधाएँ।

seanmcl 17 फ़र॰ 2015

यह महसूस करते हुए कि यह उपयोगकर्ताओं की एक बड़ी संख्या के लिए एक निरंतर दर्द है, हम --insecure को pull जोड़ने पर पुनर्विचार कर रहे हैं। @ewindisch और मैं एक जनसंपर्क पर काम करेंगे जिसे हम इस मुद्दे से

लंबे इंतजार के लिए खेद है, और अपनी राय देने और अपने दर्द बिंदुओं को इंगित करने के लिए धन्यवाद।

tiborvass 23 फ़र॰ 2015

👍3

@tiborvass मैं कल्पना कर सकता हूं कि समान रूप से बड़ी संख्या में उपयोगकर्ता हैं जो _don't_ असुरक्षित रजिस्ट्रियों से खींचने की अनुमति देना चाहते हैं। मुझे एहसास है कि डॉकर के पास वर्तमान में अनुमतियों/कॉन्फ़िगरेशन पर बढ़िया नियंत्रण नहीं है, लेकिन अगर इसे "लॉक" करने में सक्षम होने का मौका है, तो मुझे लगता है कि यह एक अच्छा स्पर्श होगा।

thaJeztah 23 फ़र॰ 2015

ओह मेरे इसे ऐसा बनाओ! इसे स्वयं लागू करने वाला था।

बेल नेटवर्क पर मेरे ब्लैकबेरी 10 स्मार्टफोन से भेजा गया।
से: सेबस्टियन वैन स्टिजनो
भेजा गया: सोमवार, फरवरी २३, २०१५ ४:५३ अपराह्न
करने के लिए: डोकर/डॉकर
उत्तर दें: docker/docker
सीसी: क्रिस्टोफर सीप्लाकी
विषय: पुन: [डॉकर] - असुरक्षित-रजिस्ट्री "डॉकर पुल" (#8887) पर होनी चाहिए

@tibor vasshttps://github.com/tiborvass मैं कल्पना कर सकता हूं कि समान रूप से बड़ी संख्या में ऐसे उपयोगकर्ता हैं जो असुरक्षित रजिस्ट्रियों से खींचने की अनुमति नहीं देना चाहते हैं। मुझे एहसास है कि डॉकर के पास वर्तमान में अनुमतियों/कॉन्फ़िगरेशन पर बढ़िया नियंत्रण नहीं है, लेकिन अगर इसे "लॉक" करने में सक्षम होने का मौका है, तो मुझे लगता है कि यह एक अच्छा स्पर्श होगा।

-
इस ईमेल का सीधे उत्तर दें या इसे Gi tHubhttps: //github.com/docker/docker/issues/8887#issuecomment -75644600 पर देखें।

octalthorpe 24 फ़र॰ 2015

@thaJeztah मैं यह पता लगाने की कोशिश कर रहा हूं कि आप किस उपयोग के मामले के बारे में सोच रहे हैं इसका मतलब है कि हमारे पास --insecure-registry ध्वज नहीं हो सकता है docker pull ।

यदि कोई उपयोगकर्ता गलती से सुरक्षित रजिस्ट्री पर MITMed नहीं होना चाहता है, तो वे केवल --insecure-registry पास करने से बच सकते हैं
यदि कोई उपयोगकर्ता उपयोगकर्ताओं पर लागू करना चाहता है कि सभी छवियां सुरक्षित रजिस्ट्रियों (यानी 'एंटरप्राइज़ी' परिदृश्य) से आती हैं, तो वे वास्तव में इसे इस समय बिल्कुल भी लागू नहीं कर सकते हैं!

तो क्या आप विस्तार से बता सकते हैं कि docker pull --insecure-registry रोकता है?

अपने दूसरे बिंदु पर विस्तार से बताने के लिए, मैं यह नहीं देख सकता कि डॉकटर कैसे काम करता है, इस पर एक महत्वपूर्ण राशि पर पुनर्विचार किए बिना आप इसे कैसे बंद कर देंगे! docker load एक टारबॉल जिसे आप अपना खुद का रजिस्ट्री पुलर लिखकर प्राप्त कर सकते हैं, और docker run -v को बढ़ाने और डेमॉन तर्कों में कुछ जोड़ने के लिए

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

aidanhs 2 मार्च 2015

यदि कोई उपयोगकर्ता उपयोगकर्ताओं पर लागू करना चाहता है कि सभी छवियां सुरक्षित रजिस्ट्रियों (यानी 'एंटरप्राइज़ी' परिदृश्य) से आती हैं, तो वे वास्तव में इसे इस समय बिल्कुल भी लागू नहीं कर सकते हैं!

यह परिदृश्य है, हाँ।

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

मैं पूरी तरह से समझता हूं कि (इस समय) इसे बंद करने का कोई तरीका नहीं है। जिन उपयोगकर्ताओं के पास docker.sock तक पहुंच है, उनके पास प्रभावी रूप से रूट पहुंच है, इसलिए वे अपनी पसंद की कोई भी चीज़ बदल सकते हैं। इसके अलावा, वे अभी भी डेमॉन ध्वज को बदलने और डेमॉन को पुनः आरंभ करने में सक्षम होंगे।

हालांकि, यह _does_ उपयोगकर्ता को एक स्पष्ट संकेत देता है यदि docker pull --insecure-registry .. एक त्रुटि देता है ("असुरक्षित रजिस्ट्रियां अक्षम हैं"), जो _would_ उपयोगकर्ताओं को सूचित करती है कि यह वांछित नहीं है, उदाहरण के लिए, कुछ उदाहरण की कोशिश करते समय उन्होंने पाया कहीं।

तो, क्या यह सभी मामलों को कवर करेगा? नहीं। क्या यह _चोट_ होगा, मुझे भी ऐसा नहीं लगता।

thaJeztah 2 मार्च 2015

मुझे व्यक्तिगत रूप से लगता है कि यह अच्छे से ज्यादा नुकसान करेगा, सिर्फ इसलिए कि यह लोगों को यह सोचने के लिए गुमराह करता है कि "ओह देखो, डॉकर इसे लागू करता है" जब वास्तव में यह एक बहुत ही सतही सुरक्षा है। मैं आगे बढ़ सकता था, लेकिन अंत में मुझे लगता है कि यह स्वाद के मामले में आता है।

aidanhs 2 मार्च 2015

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

justinclayton 2 मार्च 2015

मैं उन मुद्दों को देखता हूं जिनमें ज्यादातर डोकर उप को मारे बिना पुनः आरंभ करने में असमर्थ हैं
कंटेनर। जो इसे कॉन्फ़िगर/पुन: कॉन्फ़िगर करना बहुत कठिन बनाता है।

बुधवार, 15 अप्रैल, 2015 को रात 8:11 बजे, जन क्रुएगर नोटिफिकेशन @github.com
लिखा था:

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

thefallentree 15 अप्रैल 2015

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

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

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

jdoliner 16 अप्रैल 2015

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

मेरा प्रोजेक्ट 'डॉकर-पुल' देखें: https://github.com/ewindisch/docker-pull

आप इसे इस तरह इस्तेमाल करेंगे:

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

सभी रजिस्ट्रियों को असुरक्षित के रूप में अनुमति देना भी संभव है:

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

मैं याद दिलाऊंगा कि यह वास्तव में ऐसा करने के लिए _still_ अत्यधिक अशुभ है।

ewindisch 16 अप्रैल 2015

@ewindisch निफ्टी हैक।

एक और बहुत अच्छा समाधान एक टीसीपी सुरंग का उपयोग करना है:

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

jdoliner 16 अप्रैल 2015

ये दोनों शानदार वर्कअराउंड हैं!

justinclayton 16 अप्रैल 2015

मैं भी डिफ़ॉल्ट को उल्टा देखना चाहूंगा।

15 अप्रैल 2015 को शाम 6:14 बजे जो डोलिनर नोटिफिकेशन @github.com ने लिखा:
मैं इस बात से बहुत निराश हूं कि इस मुद्दे पर अभी तक कोई कार्रवाई नहीं की गई है। यह स्पष्ट रूप से कई लोगों को दर्द दे रहा है।
यह स्पष्ट रूप से बड़ी संख्या में लोगों को परेशान कर रहा है, यह अभी मेरे काम को सक्रिय रूप से अवरुद्ध कर रहा है। एक असुरक्षित रजिस्ट्री से खींचने की अनुमति देने के लिए डॉकर डेमॉन को पुनरारंभ करने के बाद आप जिस स्थिति में हैं, उसके आधार पर कष्टप्रद से लेकर सर्वथा असंभव तक।
ऐसा नहीं करने का मुख्य तर्क यह प्रतीत होता है कि सिस्टम व्यवस्थापक को सिस्टम को लॉक करने में सक्षम होना चाहिए और यह सुनिश्चित करना चाहिए कि केवल सुरक्षित रेपो से छवियां खींची जा सकती हैं। वह उपयोग मामला निश्चित रूप से वास्तविक है लेकिन मुझे लगता है कि यह एक खराब डिफ़ॉल्ट बनाता है। ऐसा लगता है कि ध्वज को शुरू करने के लिए डेमॉन को पारित किया जा सकता है जैसे - नो-असुरक्षित जो पुल में - असुरक्षित-रजिस्ट्री उपयोग को अक्षम करता है। इस तरह एक व्यवस्थापक चीजों को बंद कर सकता है यदि वह वास्तव में चाहता है।
-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

jaytaylor 16 अप्रैल 2015

तो इसे फिर से खोल दिया गया है और 4 महीने के बाद की वर्तमान स्थिति कुछ भी नहीं है और वर्कअराउंड के रूप में हैक्स का एक गुच्छा उपयोग करें? :-/ क्या इस बारे में कुछ चर्चा कहीं और चल रही है या यह अभी मरा हुआ है?

और हाँ, +1

echox 16 जून 2015

+1

devsli 18 जून 2015

+1

AngryHacker 18 जून 2015

मैं यह बताना चाहूंगा कि मैंने इस पृष्ठ पर "+1" के उदाहरणों की गणना की है, और अब तक गिनती 31 हो गई है। यह अन्य सहायक टिप्पणियों की गिनती नहीं कर रहा है जो वास्तव में उस सटीक स्ट्रिंग को शामिल नहीं करते हैं।

CleanCut 18 जून 2015

यहां मुद्दा यह है कि --insecure को पुल पर सक्षम करने से नियंत्रण sysadmin से दूर हो जाता है, जहां यह संबंधित है।
सुरक्षा कठिन है, और सुरक्षा को ढीला करने के लिए परिवर्तन करना कोई छोटा निर्णय नहीं है।
साथ ही, जो लोग मौजूदा सेटअप से पूरी तरह से खुश हैं वे यहां नहीं आएंगे और -1 भी।
दूसरी ओर...
रजिस्ट्री से असुरक्षित पुल को सक्षम करने के लिए डेमॉन को फिर से कॉन्फ़िगर करना तुच्छ है।
कुछ स्व-हस्ताक्षरित कर्ट सेट करना भी तुच्छ है और यहां तक कि डॉकटर को फिर से कॉन्फ़िगर करने की भी आवश्यकता नहीं है।

cpuguy83 18 जून 2015

"सिसडमिन" डॉकटर के लिए एक उपयोग-मामला है, लेकिन मैं "डेवलपर" और "नॉन-सिसडमिन" समान रूप से मान्य उपयोग के मामले हैं। एक डेवलपर के लिए, --insecure विकल्प प्रदान करने से कार्यप्रवाह में घर्षण कम होता है।

शायद हमारे पास एक विकल्प प्रदान करके दोनों दुनिया के सर्वश्रेष्ठ हो सकते हैं जो sysadmins --insecure विकल्प के उपयोग को _deny_ के लिए निर्दिष्ट कर सकते हैं। इस तरह, sysadmins का अभी भी पूर्ण नियंत्रण है, लेकिन गैर-sysadmin मामलों को वर्कफ़्लो दर्द से निपटने की आवश्यकता नहीं है।

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

हमारे sysadmins वर्तमान में हमारी रजिस्ट्री के लिए स्व-हस्ताक्षरित प्रमाणपत्रों को स्थापित नहीं करेंगे, चाहे ऐसा करना मामूली हो या नहीं।

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

CleanCut 18 जून 2015

👍1

:+1: @CleanCut , और बाकी सभी ने यह सब कहा। मैं केवल डेवलपर मामले के साथ काम करता हूं और डॉकर डेमॉन को फिर से कॉन्फ़िगर करना हमारे लिए समय की बर्बादी है।

andrask 2 अग॰ 2015

यदि आपके पास आज डॉकर सॉकेट तक पहुंच है, तो आप एक sysadmin _are_ हैं। तुम
रूट पहले से ही है, आपके पास "डॉकर लोड" है और पहले से ही करने के लिए वर्कअराउंड है
असुरक्षित रजिस्ट्री खींचती है। ग्राहक के लिए छवि विकल्प जोड़ना नहीं होगा
यथास्थिति से कम सुरक्षित।

हालाँकि, जानबूझकर बढ़ाने के बारे में कुछ कहा जाना है
दूसरों को लुभाने के लिए गलत काम करने की कोशिश कर रहे डेवलपर्स के लिए घर्षण
उन्हें सही करने में।
18 जून 2015 को दोपहर 12:41 बजे, "ब्रायन गोफ" नोटिफिकेशन @github.com ने लिखा:

यहाँ मुद्दा यह है कि --insecure on pull को सक्षम करने से नियंत्रण दूर हो जाता है
sysadmin से, जहां यह संबंधित है।
सुरक्षा कठिन है, और ढीली सुरक्षा में परिवर्तन करना कोई छोटी बात नहीं है
फैसला।
साथ ही, जो लोग मौजूदा सेटअप से पूरी तरह खुश हैं वे नहीं जा रहे हैं
यहाँ पर आने के लिए और -1 यह या तो।
दूसरी ओर...
एक से असुरक्षित पुल को सक्षम करने के लिए डेमॉन को फिर से कॉन्फ़िगर करना तुच्छ है
रजिस्ट्री।
कुछ स्व-हस्ताक्षरित कर्ट सेट करना भी तुच्छ है और यहां तक कि यह भी नहीं है
डॉकर को फिर से कॉन्फ़िगर करें।
-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/docker/docker/issues/8887#issuecomment -113213172।

ewindisch 2 अग॰ 2015

@ewindisch @tiborvass वापस पढ़ रहा है, मैं देख रहा हूँ https://github.com/docker/docker/issues/8887#issuecomment -75638745;

यह महसूस करते हुए कि यह उपयोगकर्ताओं की एक बड़ी संख्या के लिए एक निरंतर दर्द है, हम खींचने के लिए --insecure जोड़ने पर पुनर्विचार कर रहे हैं। @ewindisch और मैं एक जनसंपर्क पर काम करेंगे जिसे हम इस मुद्दे से
लंबे इंतजार के लिए खेद है, और अपनी राय देने और अपने दर्द बिंदुओं को इंगित करने के लिए धन्यवाद।

क्या वह अभी भी वर्तमान स्थिति है? (मुझे नहीं लगता कि कोई पीआर बनाया गया था)

thaJeztah 2 अग॰ 2015

👍1

+1

eddwardo 17 अग॰ 2015

यह मुझे रोजाना परेशान और परेशान करता रहता है।

:( उदास शंकु।

sleaze 19 अग॰ 2015

--inscure एक डेवलपर पीओवी से पूरी तरह समझ में आता है। इसे सुरक्षित बनाने के लिए अपने वातावरण में डॉकटर को लागू करने वाले व्यक्ति पर।

ppiersonbt 20 अग॰ 2015

+1

tony-kerz 23 अग॰ 2015

:+1:

tim-kretschmer-c2fo 28 अग॰ 2015

_उपयोगकर्ता मतदान_

_इस चर्चा में परिवर्तन होने पर सूचना प्राप्त करने का सबसे अच्छा तरीका शीर्ष दाईं ओर सदस्यता लें बटन पर क्लिक करना है।_

नीचे सूचीबद्ध लोगों ने यादृच्छिक +1 के साथ आपकी सार्थक चर्चा की सराहना की है:

@justinclayton
@anandkumarpatel
@tangr1
@fred4jupiter
@mingfang
@djannot
@फ्रस्टी
@tobegit3hub
@testaccountspivey
@महमराह
@mwhooker
@ रयान-स्टेटलेस
@jonathanvaughn
@gollawil
@ebartz
@maelp

GordonTheTurtle 14 सित॰ 2015

+1

tjadams 15 सित॰ 2015

+1

thrap 21 सित॰ 2015

+1

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

halvorgb 21 सित॰ 2015

+1

devsli 21 सित॰ 2015

यदि यह मुद्दा अभी भी हैलोवीन द्वारा खुला है, तो मुझे लगता है कि सभी +1 में एक साल की डूब-में-हमारे-डॉकर-दुख की सालगिरह पार्टी होनी चाहिए।

mhamrah 21 सित॰ 2015

दुःख की पार्टी के लिए +1!

14 सितंबर, 2015 को दोपहर 1:32 बजे, गॉर्डन नोटिफिकेशन @github.com ने लिखा:
उपयोगकर्ता मतदान
इस चर्चा में परिवर्तन होने पर सूचना प्राप्त करने का सबसे अच्छा तरीका शीर्ष दाईं ओर सदस्यता लें बटन पर क्लिक करना है।
नीचे सूचीबद्ध लोगों ने यादृच्छिक +1 के साथ आपकी सार्थक चर्चा की सराहना की है:
@justinclayton
@anandkumarpatel
@tangr1
@fred4jupiter
@mingfang
@djannot
@फ्रस्टी
@tobegit3hub
@testaccountspivey
@महमराह
@mwhooker
@ रयान-स्टेटलेस
@jonathanvaughn
@gollawil
@ebartz
@maelp
-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

jaytaylor 21 सित॰ 2015

+1

sroebuck 21 सित॰ 2015

दुःख की पार्टी के लिए +1

लोगों को "+1" का उपयोग बंद करने के लिए कहने वाले बॉट के प्रिय स्वामी:
हम इससे निपटने के लिए +1 का उपयोग करते हैं और कहने के लिए और कुछ नहीं है।

cornfeedhobo 23 सित॰ 2015

+1

nicornk 30 सित॰ 2015

+1

sebadiaz 1 अक्तू॰ 2015

SSH सुरंगों का उपयोग करने सहित कुछ वर्कअराउंड हैं - लेकिन इसके लिए रजिस्ट्री होस्ट पर ssh खातों की आवश्यकता होती है। निम्नलिखित वर्कअराउंड, इसकी आवश्यकता नहीं है।

रजिस्ट्री पोर्ट फ़ॉरवर्डर को निम्नानुसार चलाएँ:

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

और फिर अपनी स्थानीय रजिस्ट्री से छवियों को खींचें या धक्का दें:

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

rsmoorthy 8 अक्तू॰ 2015

👍1

@rsmoorthy यह शानदार है। इस वर्तमान प्रतिबंध की निरर्थकता को संक्षेप में प्रदर्शित करने के लिए धन्यवाद।

डॉकर, कृपया इस विशेष बैटरी को फिर से शामिल करें।

justinclayton 9 अक्तू॰ 2015

+1

JasonHartmann 6 नव॰ 2015

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

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

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

टीएल; डीआर +1

supernomad 1 दिस॰ 2015

👍4

+1

Koriit 2 दिस॰ 2015

@Supernomad अच्छी तरह से कहा।

mingfang 2 दिस॰ 2015

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

belooussov 7 दिस॰ 2015

@tiborvass @ewindisch यह मुद्दा एक साल से अधिक पुराना है। 8 महीने से अधिक समय हो गया है जब आपने कहा था कि इसका पुनर्मूल्यांकन किया जाना है। क्या आपने इसका मूल्यांकन किया है? यदि हां, तो क्या निर्णय लिया गया है ? भाई को फांसी पर मत छोड़ो! :-)

चूंकि इस मुद्दे को शुरू में खोला और बंद किया गया था और फिर से खोला गया था, समुदाय ने इसे स्वयं ठीक करने के लिए कई तरीके निकाले हैं, मुख्य रूप से इस डिफ़ॉल्ट सेटिंग की निरर्थकता को प्रदर्शित करने के लिए:

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

उल्लेख नहीं है कि CoreOS अब डिफ़ॉल्ट के रूप में --insecure-registry 0.0.0.0/0 साथ जहाज करता है। ये उदाहरण स्पष्ट रूप से दिखाते हैं कि यह विचार कि "सिसडमिन" और "डेवलपर" के बीच अलग-अलग चिंताओं की रेखाएं हैं, अब 2015 में काफी हद तक मनमानी और नकली हैं। वास्तव में, कंटेनरों का विचार (जिनमें से डॉकर उनका प्रमुख है) इंजीलवादी) ने पारंपरिक ऑप्स से दूर इस प्रवृत्ति को बहुत तेज कर दिया है जो अभी भी पहली बार में किसी को भी "सिसडमिन" कहने के लिए परेशान करता है।

वैसे भी, मुझे यह देखना अच्छा लगेगा कि यह अच्छे के लिए बंद हो गया है, एक तरफ या किसी अन्य।

justinclayton 30 दिस॰ 2015

👍6

+1

jhinds 6 जन॰ 2016

+1

tdensmore 12 जन॰ 2016

+1

JonathanRosado 5 फ़र॰ 2016

मुझे अपनी एसएसएल निजी कुंजी के साथ डॉकर रजिस्ट्री पर भरोसा क्यों करना चाहिए?

अन्य CoreOS उपयोगकर्ताओं के लिए इस हस्तक्षेप से सूखने के लिए छोड़ दिया,
https://coreos.com/os/docs/latest/registry-authentication.html#using -a-registry-without-ssl-configured

dzrw 5 फ़र॰ 2016

👍2

@politician इसे खुद से बेहतर नहीं कह सकते थे। यह निश्चित रूप से, ऐसा लगता है कि डॉकर इस तथ्य को अनदेखा कर रहा है कि उनके उपयोगकर्ताओं का एक बड़ा हिस्सा कम से कम असंतुष्ट है।

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

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

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

supernomad 6 फ़र॰ 2016

👍3

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

डॉकर-मशीन आपके ca.crt ओवरराइड को डाउन/अप के बीच हटा देता है
आपकी किसी भी मूल छवि में सीआई के लिए ड्रोन जैसे प्रमाणित उपकरण शामिल नहीं हैं असंभव
डॉकर सीएलआई कर्ट के लिए एक गैर-मानक फ़ोल्डर का उपयोग करता है, इसलिए यह याद रखने के लिए कुछ और है।
यहां तक कि अगर आप इसे 18 घंटे बाद काम पर लाते हैं, तो आपको हमेशा यह महसूस होगा कि कुछ और टूट गया है

निचला रेखा: स्व-हस्ताक्षरित प्रमाणपत्र का उपयोग करने का प्रयास करते समय डॉकर आपकी ऑप्स टीम को लगातार चलने वाला दंड देता है।

यह और भी निराशाजनक है क्योंकि curl -k अनंत काल से अस्तित्व में है।

dzrw 9 फ़र॰ 2016

😕2 👍1

+1

stephenenelson 31 मार्च 2016

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

buehler 16 अप्रैल 2016

@buehler आप --insecure-registry विकल्प को अपने डेमॉन की सेटिंग में, या अपनी daemon.json कॉन्फ़िगरेशन फ़ाइल में जोड़ सकते हैं; तो आपको इसे केवल एक बार कॉन्फ़िगर करने की आवश्यकता है, और ध्वज निर्दिष्ट किए बिना खींचें

thaJeztah 16 अप्रैल 2016

👍1

हमारी ओर से बस एक अपडेट: हमने तब से रजिस्ट्री को हमारे बुनियादी ढांचे से हटा दिया है और Azure ब्लॉब स्टोरेज सपोर्ट के साथ हमारे कस्टम फोर्क ऑफ डॉगस्ट्री का उपयोग

dzrw 18 अप्रैल 2016

@buehler सिर्फ @thaJeztah के प्रस्ताव को ठोस

--insecure-registry 0.0.0.0/0

आप जो भी रजिस्ट्री चाहते हैं, उसे एक्सेस कर पाएंगे। सामान के परीक्षण के लिए अच्छी तरह से काम करता है।

@politician दोहराव तब होता है जब छवियों को अलग-अलग रिपॉजिटरी के साथ टैग किया जाता है। ब्लॉब्स को हटाने की कमी काफी बड़ा मुद्दा है।

andrask 18 अप्रैल 2016

👍1

@thaJeztah अगर यह करना इतना आसान है, लेकिन 80% (

justinclayton 20 अप्रैल 2016

@justinclayton नहीं; उस विकल्प को सेट करना मूल रूप से कहता है "रजिस्ट्री में सुरक्षित संचार के साथ किसी भी मुद्दे को अनदेखा करें", इसलिए मैन-इन-द-बीच हमलों को "बॉक्स से बाहर" या यहां तक कि डेमन को गैर-टीएलएस पर वापस गिरने दें "http://" . डॉकर _does_ पहले ही इसे 127.x.x.x रेंज में रजिस्ट्रियों के लिए डिफ़ॉल्ट के रूप में सेट कर चुका है।

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

thaJeztah 20 अप्रैल 2016

👍1

@thaJeztah मैं आपका तर्क समझता हूं, लेकिन यह इसका अंत नहीं हो सकता है। डेमॉन पक्ष में होने के परिणामस्वरूप नए डेवलपर्स के लिए उपयोगकर्ता अनुभव में एक महत्वपूर्ण अंतर है। _majority_ परिदृश्य जहां यह एक दर्द है, एक नया डेवलपर है जो अपने मैक पर डॉकर टूलबॉक्स इंस्टॉलर को डाउनलोड करने और चलाने के लिए docker.com पर निर्देशों का पालन करता है। पूरा होने पर, वे तुरंत docker pull <internally-signed-registry>/foo चलाने की कोशिश करते हैं और एक त्रुटि के साथ स्वागत किया जाता है। यही असली मुद्दा है। शायद इसका मतलब है कि इस मुद्दे का नाम बदल दिया जाना चाहिए?

ऐसे और भी बहुत से तरीके हैं जिनके लिए इसे हल किया जा सकता है; मुझे यकीन है कि समुदाय और कंपनी उनमें से किसी एक पर सहमत हो सकते हैं:

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

कृपया इस मुद्दे के 70+ प्रतिभागियों को बताएं कि आप इसे किस दिशा में ले जाने की योजना बना रहे हैं, या फिर कृपया इस मुद्दे को बंद कर दें ताकि हम लटके न रहें। धन्यवाद।

justinclayton 21 अप्रैल 2016

👍6

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

apakhomov 26 अप्रैल 2016

@apakhomov का अनुमान है कि इसे उन कॉन्फ़िगरेशन परिवर्तनों की सूची में जोड़ा जा सकता है जिन्हें https://docs.docker.com/engine/reference/commandline/daemon/#configuration -reloading को पुनरारंभ किए बिना अपडेट किया जा सकता है। क्‍या आप इसके लिए कोई अलग मुद्दा खोल सकते हैं?

thaJeztah 26 अप्रैल 2016

👍2

+1।

कुछ PaS प्रदाता डेमॉन तक पहुंच नहीं देते हैं और उपयोगकर्ता के लिए एक निजी नेटवर्क चलाते हैं (उदाहरण के लिए जेलास्टिक)।

Tails 7 मई 2016

क्या डोकर में कई असुरक्षित रजिस्ट्रियां जोड़ना संभव है?
कुछ इस तरह --insecure-रजिस्ट्री xxxx:xxxx --insecure-रजिस्ट्री zzzz:zzzz

kkorada 16 मई 2016

@kkorada --insecure-registry=0.0.0.0/0 डॉकर को पहले जैसा व्यवहार करने के लिए प्रेरित करेगा।

mingfang 16 मई 2016

@kkorada हाँ, आप कई रजिस्ट्रियों को निर्दिष्ट कर सकते हैं (ध्वज --insecure-registry=[] - वर्ग कोष्ठक इंगित करते हैं कि इसे कई बार निर्दिष्ट किया जा सकता है)।

इसके अलावा डॉकर 1.12 के लिए, हम इस विकल्प को daemon.json कॉन्फ़िगरेशन फ़ाइल में कॉन्फ़िगर करने योग्य बना देंगे, बिना डेमॉन को पुनरारंभ किए। यहां ओपन पुल अनुरोध देखें: https://github.com/docker/docker/pull/22337

thaJeztah 16 मई 2016

धन्यवाद @mingfang और @thaJeztah

kkorada 16 मई 2016

जैसा कि @mhamrah और @justinclayton ने सुझाव दिया था , मैं TLS के अलावा ssh का उपयोग करके एक समाधान की भी सिफारिश करूंगा, इसी तरह Git ssh और TLS दोनों का उपयोग करके एक रिपॉजिटरी तक पहुंच की अनुमति कैसे देता है। यह ssh वर्कअराउंड का उपयोग कर सकता है जिसे @justinclayton सूचीबद्ध करता है ।

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

इसके अलावा, docker push साथ दिनों तक लड़ने के बाद और मेरी स्थानीय, निजी रजिस्ट्री एक आंतरिक, पर्याप्त रूप से सुरक्षित वर्चुअल मशीन के अंदर चल रही है (और स्व-हस्ताक्षरित प्रमाण पत्र बनाने के लिए संघर्ष करने में अधिक समय), मैं वास्तव में सराहना करने आया हूं rkt --insecure-options=image,tls,http ।

derekmahar 12 जुल॰ 2016

👍5

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

मेरा वर्तमान उपयोग मामला: डॉकर कंपोज़ के साथ एक विकास वातावरण चलाना। पर्यावरण को स्थानीय डॉकर रजिस्ट्री की आवश्यकता है। यह पूरी तरह से स्थानीय वीएम पर चलने का इरादा है।

डॉकर तरीका: प्रत्येक डेवलपर मशीन पर असुरक्षित रजिस्ट्री को सक्षम करने के लिए डॉकर-मशीन को कॉन्फ़िगर करने का तरीका बताते हुए, संभवतः उन्हें अपनी डॉकर-मशीन को फिर से बनाने की आवश्यकता होती है यदि उनके पास पहले से ही एक है या हाथ से कॉन्फ़िगरेशन संपादित करें।

हैकी समाधान: प्रत्येक कंटेनर में चल रहा समाज जिसे रजिस्ट्री का उपयोग करने की आवश्यकता होती है, स्थानीयहोस्ट पर रीडायरेक्ट करना।

चीजों को बिल्कुल आसान नहीं बनाना...

mattmb 26 जुल॰ 2016

👍8

+1

वास्तव में अफ़सोस की बात है --insecure के लिए क्लाइंट कॉन्फ़िगरेशन नहीं होना!
यह हमारे लिए बहुत दर्द पैदा करता है और साथ ही ऊपर दिए गए कई स्पष्टीकरणों के समान है।
कृपया डिफ़ॉल्ट रूप से --insecure-registry=0.0.0.0/0 सेट करें, इसे docker कमांड के साथ-साथ docker-compose कॉन्फ़िगरेशन में पास करने का एक तरीका प्रदान करें।

luchesar 9 अक्तू॰ 2016

👍8

+1

zhao-ji 10 नव॰ 2016

+1

GongT 13 दिस॰ 2016

क्या यह वार्षिक +1 पीटी पार्टी के लिए फिर से समय है?

13 दिसंबर 2016 को पूर्वाह्न 1:00 बजे [email protected] ने लिखा:
+1
-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें, या थ्रेड को म्यूट करें।

jaytaylor 13 दिस॰ 2016

😕4

यदि छवियों की परतें हस्ताक्षरित हैं, तो सुरक्षा के लिए CA PKI का उपयोग करने की कोई आवश्यकता नहीं है। यह भी देखें कि उपयुक्त/यम कैसे काम करता है। इसके अलावा, लैन में एसएसएल का उपयोग करना थोड़ा समझ में आता है, और क्लाउड वातावरण में इसका मतलब है कि आपको एक अच्छे यादृच्छिकता स्रोत के लिए - प्रमाण पत्र से अलग - प्रावधान करना होगा (यह भी देखें: https://lukehinds.github.io/2015-03 -03-एन्ट्रॉपी-इन-द-क्लाउड/)।

लंबी कहानी छोटी: यदि यह अनावश्यक है, तो इसे उपयोगकर्ताओं पर थोपें नहीं।

मैंने अभी-अभी #२९७३६ खोला है जो संबंधित है।

gm42 27 दिस॰ 2016

👍1

+1, यदि क्लाइंट-साइड --insecure-registry ध्वज एक विकल्प नहीं है, तो docker pull और docker push लिए उपयोग किए जाने वाले विश्वसनीय प्रमाणपत्र को निर्दिष्ट करने का एक तरीका होना चाहिए। हर किसी के पास OS-स्तर पर ट्रस्ट प्रमाणपत्र तक पहुंच नहीं है, या डॉकर डेमॉन के साथ खेलने की पहुंच नहीं है।

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

ajhodges 15 मार्च 2017

+1

ericpulvino 23 मार्च 2017

@ajhodges https://docs.docker.com/registry/insecure/#using -self -signed-certificates

tiborvass 24 मार्च 2017

@tiborvass
केवल तभी काम करता है जब आपके पास सुडो एक्सेस हो ...

ajhodges 24 मार्च 2017

+1 देवों को डॉकटर का उपयोग करने से हतोत्साहित करने का अच्छा तरीका

zadam 3 अप्रैल 2017

😕1 👍1

+1, मैं docker login भी --insecure-रजिस्ट्री देखना चाहता हूं।

मैं इसे सुरक्षा के मुद्दे के रूप में भी नहीं देखता, क्योंकि आप इसे जानबूझकर कर रहे हैं। और अगर किसी को अनधिकृत रूप से रूट एक्सेस मिल गया है तो यह कोई सुरक्षा प्रदान नहीं करेगा। इस प्रतिबंध का वास्तव में क्या गुण है?

यदि आपके बुरे इरादे थे, तो आप अपनी दुर्भावनापूर्ण डॉकटर

PhilippHeuer 7 अप्रैल 2017

👍1

+1 और स्पष्ट रूप से यह दिमाग को चकरा देता है

navels 11 मई 2017

👍1

दर्द ट्रेन के लिए +1।

Ichimonji10 11 मई 2017

प्लस एफ * सीकिंग वन!

harindaka 12 मई 2017

😄2

क्या इसके लिए कोई जनसंपर्क खुला है?

jaytaylor 12 मई 2017

AFAIK नहीं। ऊपर दिए गए लिंक जेनरेट किए गए हैं क्योंकि मेरे कुछ कोड इस मुद्दे का संदर्भ देते हैं। मैं यहां स्पैम को शांत करने के लिए उस संदर्भ को कुछ समय के लिए खींचूंगा।

Ichimonji10 12 मई 2017

+1 भी ...

waldman 10 अग॰ 2017

+1

mmchen 26 सित॰ 2017

+1, सेटिंग को deamon.json जोड़ना और docker को पुनरारंभ करना बहुत असुविधाजनक है।

अलग-अलग मशीनों में अलग-अलग ओएस होते हैं। कुछ डॉकर को yum 、 apt-get , और कुछ सीधे बाइनरी का उपयोग करते हैं। तो मुझे इसका पता लगाना है और डॉकर्ड को सही ढंग से पुनरारंभ करना है .... कि 'एक आपदा'

मैं सिर्फ तनाव डॉकर पुल की जरूरत है --insecure-registry झंडा !

eromoe 10 नव॰ 2017

👍5

अभी तीन साल ही हुए हैं - चलो अब उम्मीद न खोएं

r-chris 5 दिस॰ 2017

👍13 😄9 🎉2

टक्कर

justinclayton 7 फ़र॰ 2018

+1

petr-stupka 27 मार्च 2018

+1

sherif84 18 अप्रैल 2018

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

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

बहुत कम से कम, docker daemon को ALLOW insecure रजिस्ट्री पैरामीटर के लिए कॉन्फ़िगर करने योग्य होना चाहिए। यह सुरक्षा डिज़ाइन को उचित स्थान पर ले जाता है - व्यवस्थापक के हाथों में, और स्वयं docker के बाहर।

mmpfeffer 26 अप्रैल 2018

👍10

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

mjambon 13 सित॰ 2018

👍1

+1

dmwoods38 23 अक्तू॰ 2018

:+1: +1

TintypeMolly 10 अप्रैल 2019

+1

sakethkoduru 29 अप्रैल 2019

+1

yashpatel5400 7 मई 2019

+1

zulrang 5 जुल॰ 2019

+1

csegedicsaba 22 जुल॰ 2019

इसके कई अनुरोधित कार्यान्वयन डॉकर का उपयोग करने वाली कंपनियों के लिए एसओसी अनुपालन आवश्यकताओं आदि का पालन करना असंभव बना देंगे।

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

फिर भी ऐसा होना चाहिए।

मैं अब डॉकर विकास में शामिल नहीं हूं इसलिए मैं खुद को उल्लेखों से हटा दूंगा। गुड लक येल ^_^

ewindisch 23 जुल॰ 2019

एसओसी आवश्यकता एक अच्छी बात है। उस स्थिति में, इस सुविधा को सिस्टम-वाइड डॉकटर कॉन्फ़िगरेशन में जोड़े जाने के लिए कॉन्फ़िगरेशन विकल्प के साथ सक्षम किया जाना चाहिए। इस तरह एसओसी आवश्यकताओं को बरकरार रखा जा सकता है। "ALLOW_INSECURE_REGISTY_OPTION" जैसा कुछ जो docker कमांड लाइन पर --insecure-रजिस्ट्री ध्वज को सक्षम करता है।

mmpfeffer 23 जुल॰ 2019

एसओसी अनुपालन के लिए विकल्प सक्षम नहीं होना चाहिए।

mmpfeffer 23 जुल॰ 2019

+1

shqear93 9 अक्तू॰ 2019

अभी तीन साल ही हुए हैं - चलो अब उम्मीद न खोएं

5.

grunzwei 3 नव॰ 2019

यह प्रस्ताव (अपने वर्तमान स्वरूप में) विभिन्न के लिए लागू होने की बहुत संभावना नहीं है
कारण, जिनमें से;

यह डॉकटर डेमॉन को प्रबंधित करने वाले व्यक्ति को किस कनेक्शन का प्रभारी रखता है?
डेमन को बनाने की अनुमति है। ध्यान दें कि यह विकल्प "लाइव रीलोडेड" हो सकता है,
इसलिए कॉन्फ़िगरेशन को बदलने के लिए डेमॉन को पुनरारंभ करने की आवश्यकता नहीं है।
प्रत्येक कमांड या कोड-पथ जो संभावित रूप से रजिस्ट्री के साथ इंटरैक्ट करता है, उसके पास होगा
संशोधित किया जाना; न केवल docker pull , बल्कि docker build , docker run ,
docker plugin , docker service और docker stack उपकमांड, साथ ही
स्वार्मकिट जैसे ऑर्केस्ट्रेटर, जो कार्यकर्ता नोड्स से चित्र खींचते हैं।
एसओसी अनुपालन (जैसा कि ऊपर बताया गया है)

कम से कम, docker daemon को ALLOW insecure के लिए कॉन्फ़िगर करने योग्य होना चाहिए
रजिस्ट्री पैरामीटर को पास किया जाना है। जो सुरक्षा डिज़ाइन को उचित में ले जाता है
जगह - प्रशासक के हाथों में, और डॉकटर के बाहर ही।

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

शेल स्क्रिप्ट से जेसन कॉन्फिग को पैच करना एक प्रमुख दर्द बिंदु है।

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

"ALLOW_INSECURE_REGISTY_OPTION" जैसा कुछ जो docker कमांड लाइन पर --insecure-रजिस्ट्री ध्वज को सक्षम करता है।

यदि आप किसी भी रजिस्ट्री से असुरक्षित खींचने की अनुमति देना चाहते हैं (जो समकक्ष होगा
एक --insecure-registry ध्वज जोड़ने के लिए), आप "इंटरनेट" को असुरक्षित के रूप में अनुमति दे सकते हैं
रजिस्ट्री; निम्नलिखित को किसी भी IPv4 पते को असुरक्षित रजिस्ट्री के रूप में उपयोग करने की अनुमति देनी चाहिए,
(इस प्रकार गैर-टीएलएस कनेक्शन पर वापस आते हैं);

/etc/docker/daemon.json कॉन्फ़िगरेशन फ़ाइल के माध्यम से;

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

या विकल्पों को डेमॉन पर झंडे के रूप में पास करके (जिसे सिस्टमड में सेट किया जा सकता है)
ओवरराइड फ़ाइल);

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

thaJeztah 3 नव॰ 2019

👍2

Moby: --insecure-रजिस्ट्री "docker pull" पर होनी चाहिए

सबसे उपयोगी टिप्पणी

सभी 178 टिप्पणियाँ

संबंधित मुद्दों