Moby: डॉकर नेटवर्क फ़ायरवॉल को बायपास करता है, अक्षम करने का कोई विकल्प नहीं है

नोट: मैंने https://github.com/docker/docker/blob/master/vendor/src/github.com/docker/libnetwork/iptables/iptables.go में देखा कि स्रोत सेट करने का कोई मौजूदा विकल्प भी नहीं है। , तो यह सिर्फ स्रोत आईपी/डिवाइस के लिए iptables डिफ़ॉल्ट का उपयोग कर रहा है।

https://github.com/docker/docker/issues/14041 का डुप्लिकेट

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

मैं आपको उन सेवाओं के लिए निजी नेटवर्क स्थापित करने के लिए नई डॉकटर नेटवर्किंग सुविधाओं का उपयोग करने की सलाह दूंगा, जिन्हें आप बिल्कुल भी उजागर नहीं करना चाहते हैं, देखें https://docs.docker.com/engine/userguide/networking/

मैंने पहले यही सोचा था; लेकिन थोड़ा भ्रमित था, क्योंकि _expose_a पोर्ट ( EXPOSE ), वास्तव में कुछ भी नहीं करता है, लेकिन _publishing_ एक पोर्ट ( -p / -P ) वास्तव में इसे उजागर करता है मेज़बान।

यदि आप वास्तव में _publishing_ के बारे में बात कर रहे हैं, तो यह इस प्रकार बनाया गया है;

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

docker network create mynet

docker run -d --net=mynet --name=api api-image
docker run -d --net=mynet --name=db database-image
docker run -d --net=mynet --name=web -p 443:443 nginx

यह केवल होस्ट को "वेब" कंटेनर प्रकाशित करता है, वेब कंटेनर "एपीआई" और "डेटाबेस" कंटेनरों को उनके नाम से एक्सेस कर सकता है (यानी http://api :80/, और db:3306 (MySQL मानकर))

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

@thaJeztah समस्या अभी भी फ़ायरवॉल समर्थन के लिए नीचे आती है - इसे किसी विशिष्ट नेटवर्क तक सीमित करने के लिए

अब मैं इसे docker-compose के माध्यम से चला रहा हूं; हालाँकि, यह पूरी तरह से एक डॉकटर-कंपोज़ समस्या नहीं है क्योंकि libnetwork कार्यक्षमता में फ़ायरवॉल नियमों में नेटवर्क को सीमित करने की _no_ क्षमता है - iptables नियमों में कोई स्रोत विनिर्देश नहीं है, इस पर ध्यान दिए बिना कि कोई नेटवर्क को कैसे कॉन्फ़िगर करता है, जब तक कि कोई बनाने के लिए डॉकर पर निर्भर है। फ़ायरवॉल नियम (जो एक होना चाहिए क्योंकि यह उन्हें सही होने की अधिक संभावना है) तो यह एक मुद्दा बन जाता है। docker-compose.yml फ़ाइल में निम्नलिखित पर विचार करें:

nginx:
    build: ./docker/nginx/.
    ports:
        - "127.0.0.1:8080:80"
        - "127.0.0.1:443:443"
    environment:
        DESTINATION_HOST: repose
    links:
        - repose
repose:
    build: ./docker/repose/.
    ports:
        - "127.0.0.1:80:8080"
    environment:
        DESTINATION_HOST: phoenix
        DESTINATION_PORT: 8888
    links:
        - phoenix
curryproxy:
    build: ./docker/curryproxy/.
    ports:
        - "127.0.0.1:8081:8081"
    external_links:
        - rse_rse_1
        - rse_rse_2
        - rse_rse_3
phoenix:
    build: .
    ports:
        - '127.0.0.1:88:8888'
    links:
        - curryproxy:curry
    external_links:
        - rse_rse_1:rse
        - rse_rse_2
        - rse_rse_3
        - rse_cache_1:cache
    volumes:
        - .:/home/phoenix

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

मुझे यकीन नहीं है कि यह आपके नामकरण में कैसे अनुवाद करता है ... हो सकता है कि यह "प्रकाशन" पहलू का हिस्सा हो, और जो मैं कह रहा हूं उसे करने के लिए प्रकाशन क्षमता को विस्तारित करने की आवश्यकता है।

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

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

मैं थोड़ा भ्रमित हूं, क्या आप बाहरी रूप से कुछ उदाहरण दे सकते हैं जिससे आप जुड़ सकते हैं? बैकएंड सेवाएं (डिफ़ॉल्ट रूप से) 172.17.0.0/16 नेटवर्क पर होंगी, जिसे आप बाहरी रूप से एक्सेस नहीं कर पाएंगे, मैं पहले ऐसा नहीं सोचूंगा क्योंकि आपके पास बाहरी होस्ट से परिभाषित मार्ग नहीं होगा।

यदि आपका बाहरी आईपी भी एक निजी आईपी है तो एक संभावित समस्या है कि ट्रैफ़िक को नहीं छोड़ा जाएगा जो आंतरिक नेटवर्क के लिए रूट किया गया है (जबकि यह सार्वजनिक से निजी होना चाहिए) - क्या यह मुद्दा है?

@justincormack इसलिए मैं मुख्य रूप से उचित प्रॉक्सी स्थापित कर रहा हूं ताकि कुछ सेवाओं को केवल प्रॉक्सी (nginx - ssl समाप्ति) के माध्यम से मारा जा सके, जो तब प्रमाणीकरण प्रॉक्सी (रेपोज) के माध्यम से फ़िल्टर करता है, और अंत में दूसरी सेवा (फीनिक्स) पर जाता है। मैं कम परवाह कर सकता था अगर वे सभी 0.0.0.0 इंटरफ़ेस से बंधे हों; लेकिन मैं केवल nginx बाहरी रूप से सुलभ होना चाहता हूं (या कम से कम रेपोज भाग अगर मेरे पास यहां nginx नहीं है)। एक आसान समाधान, उदाहरण के लिए, कॉन्फ़िगरेशन में "127.0.0.1" सेट नहीं करना होगा, लेकिन एक फ़ायरवॉल अनुभाग होगा जहां यह निर्दिष्ट करना आसान है कि केवल डॉकटर नेटवर्क और स्थानीय के आधार कॉन्फ़िगरेशन के साथ फ़ायरवॉल के माध्यम से अनुमति देना है। होस्ट (लूपबैक) इंटरफेस बात करने में सक्षम - कुछ इस तरह:

firewall:
    external:
        ports:
            - 80
            - 443

अब डिफ़ॉल्ट 0.0.0.0 मैप के बजाय _host_ से 127.0.0.1 पर नेटवर्क मैपिंग को सीमित करके स्थिति को कुछ हद तक कम किया जा सकता है। ध्यान दें कि यह वही है जो वास्तव में इसे कम करता है क्योंकि अन्यथा ब्रिजिंग होस्ट पोर्ट को डॉकटर नेटवर्क में अग्रेषित कर देगा।

और हाँ, मैंने सत्यापित किया कि वह सीमित कार्य करता है; हालांकि, यह अभी भी संभावित कमजोरियों को छोड़ देता है और फ़ायरवॉल नियम मेल नहीं खाते जो वास्तव में किया जा रहा है।

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

IOW, यह सब सुरक्षा के बारे में है।

@BenjamenMeyer यदि आप नहीं चाहते कि अन्य सेवाएँ सुलभ हों, तो आप उनके पोर्ट को बिल्कुल क्यों प्रकाशित करते हैं? यानी "127.0.0.1:8081:8081" की जरूरत नहीं है अगर इसे केवल डॉकर नेटवर्क के माध्यम से एक्सेस किया जाता है (अन्य सेवाएं सीधे डॉकर नेटवर्क से जुड़ती हैं)

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

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

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

मेरे पास @SeerUK द्वारा बताई गई समस्या के समान है। जब पहले से मौजूद फ़ायरवॉल नियम प्रकाशित कंटेनर पोर्ट पर लागू नहीं होते हैं, तो अपेक्षा का एक झंझट का उल्लंघन होता है। वांछित व्यवहार इस प्रकार है (मेरे लिए कम से कम)

1. उपयोगकर्ता कनेक्शन का प्रयास INPUT कॉन्फ़िगरेशन आदि के आधार पर फ़िल्टर किया जाता है
2. ट्रैफ़िक अग्रेषण तब सामान्य रूप से होता है जो डॉकर-जोड़ा फॉरवर्ड नियमों के आधार पर होता है

क्या iptables में इसे प्राप्त करने का एक संक्षिप्त तरीका है, या यह आसानी से इस तरह के निर्माण की अनुमति नहीं देता है। मैं विशेष रूप से iptables के अपने ज्ञान में सीमित हूं इसलिए मेरे साथ रहें। मैंने हाल ही में इसके बारे में ज्ञान प्राप्त किया है, जबकि इसके साथ डॉकर की बातचीत को समझने की कोशिश कर रहा हूं।

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

@thaJeztah मैं इसे स्थानीय सिस्टम से एक्सेस करने में सक्षम होना चाहता हूं, और इसके खिलाफ आसानी से परीक्षण करना चाहता हूं। उदाहरण के लिए, एक RESTful HTTP API की स्थापना जिसमें एक स्वास्थ्य अंत-बिंदु है और स्थानीयहोस्ट का उपयोग करके इसके विरुद्ध curl को मज़बूती से चलाने में सक्षम है (मुझे इसे दूसरों के लिए दस्तावेज़ करना होगा और IP पते होने पर परिवर्तन विश्वसनीय नहीं है ) ज्यादातर मामलों में मेरे देव पर्यावरण के लिए मैं केवल कंटेनर एक दूसरे से बात करना चाहता हूं, लेकिन मैं इसे मेजबान से एक्सेस करने में सक्षम होना चाहता हूं।

@SeerUK के मामले के लिए, IP ब्लॉक (5.5.0.0/16 - iptables नियमों में स्रोत पते के लिए एक मान्य पैरामीटर) सेट करने में सक्षम होना बहुत अच्छी बात होगी। IPtables में पहले से ही सीमित करने की क्षमता है, लेकिन docker इसका लाभ नहीं उठा रहा है।

@thaJeztah मैंने इसे बाहरी नेटवर्क से दूर रखने के लिए स्पष्ट रूप से "127.0.0.1:8081:8081" सेट किया है; मुझे अपने डॉकटर कंटेनरों में खुले बंदरगाहों के माध्यम से कंटेनरों में दरार डालने की कोशिश कर रहे लोगों के लॉग मिले थे।

अभी मेरा काम है कि मैं दिन के लिए निकलने से पहले डॉकटर कंटेनरों को बंद कर दूं क्योंकि मैं यह सुनिश्चित नहीं कर सकता कि मैं वास्तव में बाहरी _is_ बाहरी होना चाहता हूं, या यह कि सुरक्षा उद्देश्यों के लिए पर्यावरण ठीक से सीमित है।

@BenjamenMeyer ऐसा करने का एक तरीका उन परीक्षणों को एक कंटेनर में चलाना है, उदाहरण के लिए

docker run --net -it --rm --net=mynetwork healthchecker 

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

@thaJeztah जो मानता है कि मैं इसे कमांड-लाइन के माध्यम से कर रहा हूं और किसी अन्य टूल का उपयोग नहीं कर रहा हूं जहां मुझे केवल एक आईपी पता सेट करना है।

उदाहरण के लिए, मैं एक एपीआई पर काम कर रहा हूँ। मेरे पास एक उपकरण है जिसका उपयोग मैं उत्पादन में उस एपीआई के साथ काम करने के लिए कर सकता हूं; उपकरण और एपीआई के विकास के लिए मैं उपकरण को केवल dockerized API पर इंगित करना चाहता हूं। उपकरण डोकर के बारे में कुछ नहीं जानता है, और न ही उसे करना चाहिए। और मैं जरूरी नहीं कि इसका उपयोग करने के लिए उपकरण को डॉकटर में रखना चाहता हूं - इसे केवल स्थानीय होस्ट के संपर्क में आने वाले पोर्ट पर इंगित करना पर्याप्त होना चाहिए।

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

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

यदि आप ऐसा करने के इच्छुक हैं, तो iptables का उपयोग करना इसे पूरी तरह से संभव बनाता है।

आप इसका उपयोग कैसे कर सकते हैं इसका एक छोटा-सा उदाहरण है: https://gist.github.com/SeerUK/b583cc6f048270e0ddc0105e4b36e480

आप देख सकते हैं कि नीचे दाईं ओर, 1.2.3.4 को स्पष्ट रूप से पोर्ट 8000 (जो डॉकर द्वारा उजागर किया गया है) तक पहुंच प्रदान की गई है, फिर उस पोर्ट पर कुछ और गिरा दिया गया है। PRE_DOCKER श्रृंखला को DOCKER श्रृंखला से पहले डाला जाता है ताकि इसे पहले मारा जा सके, जिसका अर्थ है कि DROP अवरुद्ध अनुरोधों को DOCKER श्रृंखला तक पहुंचने से रोकता है।

यह थोड़ा कष्टप्रद है कि डॉकर में यह कार्यक्षमता अंतर्निहित नहीं है, लेकिन अभी इसके आसपास काम करना संभव है।

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

मैं वास्तव में यह पता लगाने में कभी कामयाब नहीं हुआ कि UFW के साथ यह काम कैसे किया जाए। हालांकि अभी के लिए, मैं समाधान के रूप में iptables का उपयोग करके खुश हूं। ऐसा लगता है कि अब तक मेरे लिए बहुत अच्छा काम कर रहा है।

जाहिर है, यह बहुत अच्छा समाधान नहीं है यदि आपने पहले से ही UFW के आसपास फ़ायरवॉल नियमों का एक जटिल जटिल सेट बनाया है। हालाँकि, यह iptables-persistent जैसी चीज़ों का उपयोग करना काफी आसान बनाता है। आप इस तरह से एक्सेस की अनुमति देने के वैकल्पिक तरीकों का भी उपयोग कर सकते हैं जो iptables में अधिक "सामान्य" लगते हैं।

@BenjamenMeyer क्या आपने सबनेट और आईपी-रेंज विकल्प के साथ उपयोगकर्ता-परिभाषित docker network का उपयोग करने और कंटेनरों के लिए एक स्थिर आईपी-पता निर्दिष्ट करने और स्थानीय विकास के लिए उनका उपयोग करने के बारे में सोचा है ताकि आपको निर्भर न रहना पड़े एक आभासी स्थिर आईपी जैसे कि 127.0.0.1? यह उन कंटेनरों के लिए एक साथ पोर्ट-मैपिंग करने की आवश्यकता से बच जाएगा जो एक मेजबान के लिए निजी हैं।

docker network create --subnet=30.1.0.0/16 --ip-range=30.1.0.0/24 mynetwork
docker run --net=mynetwork --ip=30.1.1.1 --name=myservice1 xxxx
docker run --net=mynetwork --ip=30.1.1.2 --name=myservice2 yyyy

इस सेटअप के साथ, myservice2 myservice1 नाम से myservice1 तक पहुंच सकता है और स्थिर आईपी पर भी निर्भर होने की कोई आवश्यकता नहीं है। इसके अलावा, होस्ट पोर्ट-मैपिंग की आवश्यकता के बिना स्टैटिक-आईपी तक स्वतंत्र रूप से पहुंच सकता है।

कंपोज़ 1.7 के साथ, आप कंटेनरों के लिए स्थिर आईपी पता निर्दिष्ट कर सकते हैं और नेटवर्क सबनेट और रेंज निर्दिष्ट कर सकते हैं।

मैंने एक साधारण कामकाज का पता लगाया।

१) संपादित करें/आदि/डिफ़ॉल्ट/डॉकर: DOCKER_OPTS="--iptables=false"

2) ufw नियम जोड़ें: ufw allow to <private_ip> port <port>

इतना सरल कि यह वास्तव में मुझे आश्चर्यचकित करता है कि --iptables=false विकल्प डिफ़ॉल्ट क्यों नहीं है। ऐसी स्थिति क्यों बनाएं जब सभी डॉकटर को यह कहना है, "अरे, अगर आप फ़ायरवॉल चला रहे हैं तो आपको इसके माध्यम से एक छेद पंच करना होगा!" मुझे किसकी याद आ रही है?

https://fralef.me/docker-and-iptables.html
http://blog.viktorpetersson.com/post/101707677489/the-dangers-of-ufw-docker

मैं अपने जीवन को बचाने के लिए iptables को संशोधित करने से रोकने के लिए डॉकर नहीं प्राप्त कर सकता। Ubuntu 16.04 पर बिना किसी लाभ के / etc / default / docker को अपडेट करने का प्रयास किया

@enzeart कोशिश करें /lib/systemd/system/docker.service ।

@SeerUK आपकी आत्मा को शांति दे

@enzeart एक होस्ट पर चल रहे डेमॉन को कॉन्फ़िगर करने के लिए जो https://docs.docker.com/engine/admin/systemd/#custom -docker-daemon-options देखें।

आप daemon.json कॉन्फ़िगरेशन फ़ाइल का भी उपयोग कर सकते हैं, देखें https://docs.docker.com/engine/reference/commandline/daemon/#daemon -configuration-file

@mavenugo पहले से ही एक

@jcheroske जो काम करता है, लेकिन जैसा कि मैंने नोट किया इसका मतलब यह होगा कि _end-user_ (मुझे) को यह सुनिश्चित करना होगा कि सभी iptables नियम सही थे, जो इष्टतम नहीं है और लगभग होने की संभावना नहीं है docker होने के कारण इसे स्वचालित रूप से करें, इस प्रकार यह समस्या।

हाय, कृपया ऊपर। मुझे लगता है कि इसका मुद्दा भी है। Iptables में कंटेनर श्रृंखला को मुख्य नियमों के अनुसार होना चाहिए और डिफ़ॉल्ट रूप से दुनिया के सामने नहीं आना चाहिए।

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

उदाहरण के लिए:

nginx:
    ports:
      - "8000:8000"
    whitelist:
      - 10.6.20.2

इसका मतलब यह होगा कि केवल 10.6.20.2 का एक स्रोत आईपी इस होस्ट पर पोर्ट 8000 तक पहुंच सकता है।

@StefanPanait मुझे वास्तव में वह विचार पसंद है। यह वॉल्यूम के समान सिंटैक्स के साथ भी काम कर सकता है और सूचियों तक पहुंच/अस्वीकार कर सकता है, जैसे कुछ:

nginx:
  access:
  - "10.0.1.6:allow"
  - "deny"

यह निश्चित रूप से अभी भी अंतर-कंटेनर संचार जैसी चीजों को अनुमति देना होगा।

@SeerUK अंतर-कंटेनर संचार एक डिफ़ॉल्ट होना चाहिए, लेकिन आप एक कंटेनर को उससे बात करने से प्रतिबंधित क्यों नहीं कर सकते? यह डिबगिंग के लिए बेहद उपयोगी हो सकता है ...

हालांकि मुझे लगता है कि ऐसा करने का उचित तरीका डॉकर नेटवर्क को अलग करना होगा ... फिर भी, मुझे लगता है कि ऐसा कुछ करने में सक्षम होना:

nginx: access: - "10.0.1.6:allow" - "webapi:allow" - "database:deny" - "deny"
उपयोगी हो सकता है...प्रश्न यह है कि क्या यह उस हद तक कार्यान्वयन को उचित ठहराने के लिए पर्याप्त उपयोगी है? मुझे नहीं पता।

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

आप एक कंटेनर को उससे बात करने से प्रतिबंधित क्यों नहीं कर सकते? यह डिबगिंग के लिए बेहद उपयोगी हो सकता है

वह docker network disconnect के लिए है? आप डिबगिंग के लिए नेटवर्क से एक कंटेनर को डिस्कनेक्ट कर सकते हैं, और इसे docker network attach साथ फिर से जोड़ सकते हैं

उन लोगों के लिए जिन्होंने अभी-अभी पता लगाया है कि उनके इंटरनेट एक्सपोज़्ड सर्वर पर एक टन पोर्ट खुले थे, UFW का उपयोग करने के बाद, मैंने खोदा और खोदा और निम्नलिखित की खोज की:

UFW और Docker के साथ Ubuntu 16.04 नई चुनौतियां पेश करता है। मैंने यहां दिखाए गए सभी चरणों का पालन किया: https://svenv.nl/unixandlinux/dockerufw लेकिन मुझे 16.04 को काम करने के लिए डॉकर प्लस यूएफडब्ल्यू नहीं मिला। दूसरे शब्दों में, कोई फर्क नहीं पड़ता कि मैंने क्या किया, सभी डॉकटर पोर्ट विश्व स्तर पर इंटरनेट के संपर्क में आ गए। जब तक मुझे यह नहीं मिला: http://blog.samcater.com/how-to-set-docker-1-12-to-not-interfere-with-iptables-firewalld/
मुझे फ़ाइल बनानी थी: /etc/docker/daemon.json और इसमें निम्नलिखित डालें:

{
"आईपीटेबल्स": झूठा
}

मैंने तब sudo service docker stop जारी किया और फिर sudo service docker start अंत में डॉकर यूएफडब्ल्यू में उचित नियमों का पालन कर रहा है।

अतिरिक्त डेटा: https://chjdev.com/2016/06/08/docker-ufw/

@thaJeztah

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

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

फिर भी, यह "चलो मूल समस्या को ठीक करते हैं" का सामना नहीं करता है।

@ gts24 दिलचस्प खोज।

IMHO, पूरी समस्या यह है कि डॉकर, वस्तुतः अन्य सभी कार्यक्रमों की तरह, फ़ायरवॉल (iptables या अन्यथा) को बिल्कुल भी नहीं छूना चाहिए। जब मैं (जैसे) अपाचे स्थापित करता हूं और इसे 0.0.0.0:80 पर सुनने के लिए कहता हूं, तो यह मेरा निर्णय है कि मैं फ़ायरवॉल पर पोर्ट 80 को खोलूं या नहीं, जहां हूं जो हूं ।

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

@gcscaglia ने डेमॉन पर --iptables=false सेट किया और आपको वह मिल जाना चाहिए

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

@thaJeztah वास्तव में तलादार ने क्या कहा।

--iptables=false का नाम बदलकर --networking=false दिया जाना चाहिए क्योंकि इसके साथ आंतरिक कंटेनर-से-कंटेनर नेटवर्किंग भी काम नहीं करती है। इनबाउंड फ़ायरवॉल नियमों (यानी LISTEN ) पर छेद किए बिना कंटेनर को कुछ पोर्ट/इंटरफ़ेस संयोजन पर सुनने का विकल्प यह सब हल करेगा, पीछे की ओर संगत होगा और --iptables=true का उपयोग करने की अनुमति देगा .

इस तरह के एक सुनने के तरीके के साथ, जो लोग इसे "बस काम" करना चाहते हैं वे PUBLISH उपयोग कर सकते हैं, और जो नियंत्रण चाहते हैं वे LISTEN उपयोग कर सकते हैं।

@gcscaglia ठीक है, इसलिए यदि आप चाहते हैं कि संभाले , लेकिन "प्रकाशन" नहीं। आप --iptables सक्षम रख सकते हैं, लेकिन _don't_ उपयोग -p / --publish । आपको पोर्ट को कंटेनरों में अग्रेषित करने के लिए IPTables नियमों को मैन्युअल रूप से सेट करने में सक्षम होना चाहिए। कंटेनर पहले से ही अपने निजी आईपी-पते पर सुनता है, और बंदरगाह जो आपके कंटेनर में सेवा सुनता है।

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

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

आपका विचार केवल स्थायी होने के हास्यास्पद सरल उपयोग के मामले के लिए काम करता है, कभी भी मैन्युअल रूप से लॉन्च किए गए कंटेनर नहीं बदलते। यहां तक ​​​​कि एक साधारण --restart=always कंटेनर में भी इस सेटअप में टूट जाएगा जब तक कि कंटेनर में एक स्थिर आईपी न हो।

@taladar मैं @gcscaglia के उपयोग के मामले का जवाब दे रहा हूं, जिन्होंने एक ऐसी सुविधा का अनुरोध किया है जहां --iptables=false उपयोग करने के लिए समझाया, लेकिन इसे सक्षम रखने के लिए, लेकिन केवल -p / --publish सुविधा का उपयोग न करें (जो डॉकर को बनाने के लिए कहता है) वे पोर्ट जिन्हें IPTables के माध्यम से एक्सेस किया जा सकता है)।

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

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

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

LISTEN क्या करेगा? EXPOSE , जो आपको यह टिप्पणी करने की अनुमति देता है कि कंटेनर किस पोर्ट पर सुनता है। ट्रिगर्स के लिए, आप डॉकर को सुन सकते हैं events ।

यह नहीं कह रहा कि यहां सुधार की कोई गुंजाइश नहीं है (मुझे पता है कि इस पर गौर किया जा रहा है), बस सोच रहा था कि आप क्या उम्मीद करेंगे

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

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

1. चुने हुए होस्ट के इंटरफ़ेस पर चुने हुए पोर्ट को कंटेनर प्राइवेट IP पर चुने गए पोर्ट पर अग्रेषित करने के लिए iptables नियम बनाता है (जिसकी हम सभी अपेक्षा करते हैं क्योंकि हमने यही पूछा है)
2. iptables को दुनिया में कहीं से किसी को भी चुने हुए होस्ट के इंटरफ़ेस पर उस पोर्ट तक पहुंचने की अनुमति देने के लिए कहता है (जो काम करने के लिए अग्रेषित करने के लिए अनावश्यक है और इसलिए हम में से कई को आश्चर्यचकित करता है)

मैं जो प्रस्तावित कर रहा हूं वह एक विशेषता है (नाम LISTEN या अन्यथा) जो केवल "1" करता है और उपयोगकर्ता के विवेक पर "2" देता है, जैसे अन्य सभी सेवाएं/कार्यक्रम आमतौर पर करते हैं।

EXPOSE , AFAIK डॉकर छवियों में केवल मेटाडेटा है, इसलिए डेमॉन जानता है कि जब उपयोगकर्ता -P निर्दिष्ट करता है तो क्या करना है (सब कुछ प्रकाशित करें)। शायद मैं इसके बारे में गलत हूं, और "उजागर" बंदरगाहों को पुनरारंभ-प्रतिरोधी फैशन (डब्ल्यू/ओ विश्वव्यापी पहुंच) में अग्रेषित किया जा सकता है?

--विषय से परे--

आईएमएचओ इस मुद्दे का ओपी पूछ रहा है कि क्यों -p "2" करता है और डॉकर को इसे करने से कैसे रोकें। जबकि एक डेमॉन-स्तरीय सेटिंग (नेटवर्किंग को अक्षम करने के अलावा) इसे हल कर सकती है, चीजों को पिछड़ा-संगत रखने के लिए, एक नई सुविधा सबसे अच्छी होगी (यानी LISTEN या कोई अन्य नाम)।

जबकि इस तरह के कई उपयोगकर्ता "बॉक्स से बाहर काम करते हैं" प्रभाव, कोई भी sysadmin अपने iptables / फ़ायरवॉल के अलावा अन्य प्रोग्रामों को फ़ायरवॉल पर पोर्ट खोलने की अपेक्षा नहीं करता है, इससे भी कम एक तरह से उनका फ़ायरवॉल प्रबंधन सॉफ़्टवेयर रिपोर्ट नहीं करता है।

मैं देखता हूं कि तीन प्रमुख समस्याएं हैं:

1. बंदरगाहों को प्रकाशित/उजागर करने का डॉकर का तरीका यूएफडब्ल्यू जैसे सामान्य फ़ायरवॉल नियमों को छोड़ देता है।
2. उपरोक्त तथ्य अच्छी तरह से प्रलेखित प्रतीत नहीं होता है (यह पूरी तरह से अप्रत्याशित है क्योंकि कोई अन्य लिनक्स सेवाओं को मैं स्वयं बाईपास फ़ायरवॉल नियमों के बारे में नहीं जानता)।
3. iptables को Docker के बंदरगाहों को प्रकाशित करने/उजागर करने के तरीके के अनुकूल बनाने का कोई आसान तरीका नहीं है या जिस तरह से लोग जानते हैं उसे स्वचालित करना आसान नहीं है और कोई भी दस्तावेज नहीं है।

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

उदाहरण के लिए "इलास्टिक्स खोज" प्रकाशन पोर्ट 9200 नामक कंटेनर के लिए allow: "tcp:{your_trusted_ip}" कुछ ऐसा कर सकता है:

iptables -t mangle -N DOCKER-elasticsearch
iptables -t mangle -A DOCKER-elasticsearch -s {your_trusted_ip} -j RETURN
iptables -t mangle -A DOCKER-elasticsearch -j DROP
iptables -t mangle -I PREROUTING -p tcp --dport 9200 -j DOCKER-elasticsearch

मुझे यह डॉकर डॉक्स से बहुत उपयोगी लगा: https://docs.docker.com/engine/userguide/networking/default_network/container-communication/#communicating -to-the-outside-world

डॉकर के फॉरवर्ड नियम डिफ़ॉल्ट रूप से सभी बाहरी स्रोत आईपी की अनुमति देते हैं। केवल एक विशिष्ट IP या नेटवर्क को कंटेनरों तक पहुँचने की अनुमति देने के लिए, DOCKER फ़िल्टर श्रृंखला के शीर्ष पर एक नकारात्मक नियम डालें। उदाहरण के लिए, बाहरी पहुंच को प्रतिबंधित करने के लिए जैसे कि केवल स्रोत आईपी 8.8.8.8 कंटेनरों तक पहुंच सकता है, निम्नलिखित नियम जोड़ा जा सकता है:

$ iptables -I DOCKER -i ext_if! -एस 8.8.8.8 -जे ड्रॉप

@jmimico हाँ मैं इससे पहले आया हूँ। आप 2 या अधिक IP से एक्सेस को कैसे प्रतिबंधित करेंगे?

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

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

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

@StefanPanait अच्छा सवाल है। मेरी शर्त यह है कि आपको वस्तु-समूहों के उपयोग का लाभ उठाने की आवश्यकता होगी। ऑब्जेक्ट-ग्रुप्स को व्हाइट-लिस्टेड IP के साथ पॉप्युलेट करें और फिर उस ऑब्जेक्ट-ग्रुप को DOCKER चेन की पहली लाइन में इस्तेमाल करें।

उदाहरण:
iptables -N docker-allow
iptables -एक डॉकटर-अनुमति -s 1.1.1.1 -j ACCEPT
iptables -एक डॉकटर-अनुमति -s 2.2.2.2 -j ACCEPT
iptables -एक डॉकटर-अनुमति -s 3.3.3.3 -j ACCEPT
iptables -ए डॉकर-अनुमति -j ड्रॉप

iptables -I DOCKER -i ext_if -j docker-allow

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

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

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

DOCKER-USER श्रृंखला में ड्रॉपिंग नियम जोड़ना इसे डॉकटर पुनरारंभ में लगातार बनाने में बेहतर काम करता प्रतीत होता है।

डॉकर v.17.06 के साथ DOCKER-USER नामक एक नई iptables श्रृंखला है। यह आपके कस्टम नियमों के लिए है, सर्वरफॉल्ट पर मेरा उत्तर देखें: https://serverfault.com/questions/704643/steps-for-limiting-outside-connections-to-docker-container-with-iptables/886257#886257

जैसा कि मैंने एसएफ पर टिप्पणी की, मुझे याद आती है कि यह डॉकर-यूजर श्रृंखला किसी भी अन्य उपयोगकर्ता-जोड़ा श्रृंखला से अलग क्यों है .. इसमें कोई फ़िल्टर पूर्व-लागू नहीं है और यह सभी ट्रैफ़िक को फ़िल्टर करता है न कि केवल डॉकर-कंटेनर-डेस्टिनेटेड ट्रैफ़िक को इसलिए आपको अभी भी इंटरफ़ेस नाम स्वयं निर्दिष्ट करना होगा और यह अभी भी गैर-iptables विशेषज्ञ द्वारा गंभीर गलतियाँ करने के लिए प्रवण है।

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

ठीक है, इसलिए DOCKER-USER का उपयोग करके यह सुनिश्चित करके कि यह हमेशा अन्य Docker- संबंधित नियमों से पहले श्रृंखला में आता है, आवेषण के क्रम के मुद्दे को हल करता है। हालांकि, यह पोर्ट नंबर द्वारा एक कंटेनर में श्वेतसूची यातायात को बहुत आसान नहीं बनाता है क्योंकि इस बिंदु पर --dport डॉकटर कंटेनर के अंदर सेवा का बंदरगाह है, न कि खुला बंदरगाह। उदाहरण:

9000 पर आंतरिक रूप से सुनने वाली डॉकटर सेवा को उजागर करने के लिए पोर्ट 9900 प्रकाशित करें।

$ sudo iptables -A DOCKER-USER -m limit --limit 20/min -j LOG --log-prefix "IPTables: "
$ docker run --rm -it -p '192.168.56.101:9900:9000' alpine nc -l 9000

नेटवर्क पर किसी अन्य मशीन से:

$ telnet 192.168.56.101 9900

क्या लॉग हो जाता है:

IPTables: IN=enp0s8 OUT=docker0 MAC=08:00:27:b6:8d:d6:0a:00:27:00:00:04:08:00 SRC=192.168.56.1 DST=172.17.0.2 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=14127 DF PROTO=TCP SPT=51208 DPT=9000 WINDOW=64240 RES=0x00 SYN URGP=0
IPTables: IN=docker0 OUT=enp0s8 PHYSIN=veth05ba007 MAC=02:42:0f:f9:76:4c:02:42:ac:11:00:02:08:00 SRC=172.17.0.2 DST=192.168.56.1 LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=23041 DF PROTO=TCP SPT=9000 DPT=51208 WINDOW=0 RES=0x00 ACK RST URGP=0

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

$ docker run -d -p 7777:6379 --name data1 redis
$ docker run -d -p 8888:6379 --name data2 redis

हालाँकि, मैं DOCKER-USER का उपयोग नहीं कर सकता (कृपया मुझे सही करें अगर मैं गलत हूं) डेटा 1 पर ट्रैफ़िक को प्रभावित किए बिना डेटा 2 पर ट्रैफ़िक को प्रभावित किए बिना जब तक कि मैं गंतव्य कंटेनर आईपी की खोज के लिए किसी प्रकार के आत्मनिरीक्षण का उपयोग नहीं करता जो क्षणिक है जो आपको वापस लाता है स्क्रिप्टिंग और आत्मनिरीक्षण के बिना प्रकाशित सेवाओं को फ़ायरवॉल करने के लिए एक सरल, विश्वसनीय तरीका खोजने पर वर्ग एक।

स्पष्ट होने के लिए, यह काम नहीं करता है:

$ sudo iptables -A DOCKER-USER -p tcp -m tcp -s 192.168.56.0/24 --dport 7777 -j RETURN
$ sudo iptables -A DOCKER-USER -p tcp -m tcp -s 10.0.24.0/24 --dport 8888 -j RETURN
$ sudo iptables -A DOCKER-USER -p tcp -m tcp --dport 7777 -j DROP
$ sudo iptables -A DOCKER-USER -p tcp -m tcp --dport 8888 -j DROP

यह काम करता है, लेकिन परिणाम यह है कि दोनों सेवाएं श्वेतसूचीबद्ध दोनों सीआईडीआर के संपर्क में हैं:

$ sudo iptables -A DOCKER-USER -p tcp -m tcp -s 192.168.56.0/24 --dport 6379 -j RETURN
$ sudo iptables -A DOCKER-USER -p tcp -m tcp -s 10.0.24.0/24 --dport 6379 -j RETURN
$ sudo iptables -A DOCKER-USER -p tcp -m tcp --dport 6379 -j DROP

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

@SeerUK
https://gist.github.com/SeerUK/b583cc6f048270e0ddc0105e4b36e480 में पोस्ट किया गया समाधान मेरे काम नहीं आया। क्या आप मदद कर सकतें है?

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

यदि आप डॉकटर के चलने पर iptables बदलते हैं तो यह iptables में अजीब व्यवहार करता है। यदि आप docker set iptables को रोकते हैं और सभी docker को पूर्वाभास के रूप में पुनः आरंभ करते हैं। मेरी चिंता है ... अगर मुझे उत्पादन में iptables बदलना है?

यदि आप डॉकटर के चलने पर iptables बदलते हैं तो यह iptables में अजीब व्यवहार करता है।

iptables iptables है, इससे कोई फर्क नहीं पड़ता कि डॉकर चल रहा है या नहीं ..

यह बेहतर है कि आप पहले बहुत सारे परीक्षण करें ... iptables को यह बताना कि iptables सिर्फ एक तनातनी है। यह मेरा सुझाव है :)

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

मुझे नहीं लगता कि DOCKER-USER इसका समाधान क्यों नहीं करता है।
आप अपनी पसंद के अनुसार फ़िल्टर करने के लिए iptables का उपयोग करते हैं: स्रोत पोर्ट, लक्ष्य पोर्ट, स्रोत योजक, गैर-स्थानीय ट्रैफ़िक, आदि।

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

@ cpuguy83 मुख्य मुद्दा यह है कि

DOCKER-USER इसका समाधान नहीं कर सकता क्योंकि यह docker नेटवर्क को किसी विशिष्ट नेटवर्क इंटरफ़ेस या विशिष्ट IP (fe 127.0.0.1) से भी नहीं जोड़ता है।

मेरे मूल अनुरोध के अनुसार:
1.डॉकर को खुद को एक विशिष्ट आईपी से जोड़ना चाहिए - डॉकर नेटवर्क कॉन्फ़िगरेशन के आधार पर - और फिर उपयोगकर्ता को कंटेनर ऑफ-सिस्टम (अपनी पसंद के टूलिंग का उपयोग करके) को उजागर करने के लिए नियम जोड़ने की अनुमति दें; डिफ़ॉल्ट रूप से कंटेनर को ऑफ-सिस्टम उजागर नहीं किया जाना चाहिए।

1. ऐतिहासिक व्यवहार पर भरोसा करने वाले कम से कम कुछ लोगों के कारण संक्रमण अवधि के बिना ऐसा नहीं किया जा सकता है।

IMHO, पूरी समस्या यह है कि डॉकर, वस्तुतः अन्य सभी कार्यक्रमों की तरह, फ़ायरवॉल (iptables या अन्यथा) को बिल्कुल भी नहीं छूना चाहिए। जब मैं (जैसे) अपाचे स्थापित करता हूं और इसे 0.0.0.0:80 पर सुनने के लिए कहता हूं, तो यह मेरा निर्णय है कि मैं फ़ायरवॉल पर पोर्ट 80 को खोलना चाहता हूं या नहीं, जहां मैं इसके लिए कोई भी नियम निर्दिष्ट कर सकता हूं जो मैं चाहता हूं।
डॉकटर (और/या कंपोज़) कॉन्फ़िगरेशन फ़ाइलों पर फ़ायरवॉल नियमों को फिर से स्थापित करने के बजाय, संपूर्ण PUBLISH सुविधा को हटा दिया जाना चाहिए, और अन्य सभी प्रोग्रामों की तरह काम करने के लिए बनाई गई एक नई LISTEN सुविधा। सबसे अच्छा, डॉकटर प्रत्येक पोर्ट/कंटेनर के लिए डिफ़ॉल्ट फ़ायरवॉल सेवाओं द्वारा अक्षम बना सकता है, जो सिस्टम का उपयोग करता है।

अच्छा कहा @gcscaglia ! इससे भी अधिक चौंकाने वाली बात यह है कि https://docs.docker.com/engine/reference/run/#expose -incoming-ports में इस सब का बहुत कम या कोई उल्लेख नहीं है, जो मुझे लगता है कि वह जगह है जहां ज्यादातर लोग इसकी तलाश करते हैं। सीखने-दर-उदाहरण के पूरक के लिए दस्तावेज़ीकरण का एक छोटा सा अंत समाप्त होता है। पहले से मौजूद iptables नियमों को ओवरराइड करने वाले डॉकर के जोखिमों की व्याख्या करते हुए कहीं न कहीं एक चमकदार लाल बॉक्स होना चाहिए।

यदि आप नहीं चाहते कि docker iptables को प्रबंधित करे, तो --iptables-=false
यदि आप केवल डॉकटर को एक विशिष्ट इंटरफ़ेस पर पोर्ट खोलना चाहते हैं, तो आप इसे डेमॉन कॉन्फिगरेशन में भी सेट कर सकते हैं।

@बेंजामेनमेयर
आप DOCKER-USER में सभी ट्रैफ़िक को ब्लॉक कर सकते हैं और केवल वही कर सकते हैं जो आप चाहते हैं।

आप DOCKER-USER में सभी ट्रैफ़िक को ब्लॉक कर सकते हैं और केवल वही कर सकते हैं जो आप चाहते हैं।

@ cpuguy83 कृपया मुझे बताएं कि क्या मैं यहां जो कुछ भी कह रहा हूं वह गलत है:

$ docker run -d -p 7777:6379 --name data1 redis
$ docker run -d -p 8888:6379 --name data2 redis

हालाँकि, मैं DOCKER-USER का उपयोग नहीं कर सकता (कृपया मुझे सही करें अगर मैं गलत हूं) डेटा 1 पर ट्रैफ़िक को प्रभावित किए बिना डेटा 2 पर ट्रैफ़िक को प्रभावित किए बिना जब तक कि मैं गंतव्य कंटेनर आईपी की खोज के लिए किसी प्रकार के आत्मनिरीक्षण का उपयोग नहीं करता जो क्षणिक है जो आपको वापस लाता है स्क्रिप्टिंग और आत्मनिरीक्षण के बिना प्रकाशित सेवाओं को फ़ायरवॉल करने के लिए एक सरल, विश्वसनीय तरीका खोजने पर वर्ग एक।

स्पष्ट होने के लिए, यह काम नहीं करता है:

$ sudo iptables -A DOCKER-USER -p tcp -m tcp -s 192.168.56.0/24 --dport 7777 -j RETURN
$ sudo iptables -A DOCKER-USER -p tcp -m tcp -s 10.0.24.0/24 --dport 8888 -j RETURN
$ sudo iptables -A DOCKER-USER -p tcp -m tcp --dport 7777 -j DROP
$ sudo iptables -A DOCKER-USER -p tcp -m tcp --dport 8888 -j DROP

यह काम करता है, लेकिन परिणाम यह है कि दोनों सेवाएं श्वेतसूचीबद्ध दोनों सीआईडीआर के संपर्क में हैं:

$ sudo iptables -A DOCKER-USER -p tcp -m tcp -s 192.168.56.0/24 --dport 6379 -j RETURN
$ sudo iptables -A DOCKER-USER -p tcp -m tcp -s 10.0.24.0/24 --dport 6379 -j RETURN
$ sudo iptables -A DOCKER-USER -p tcp -m tcp --dport 6379 -j DROP

इसलिए DOCKER-USER का उपयोग करके डेटा2 कंटेनर से स्वतंत्र रूप से डेटा1 कंटेनर में/से ट्रैफ़िक को नियंत्रित करने का कोई तरीका नहीं है। मेरे लिए यह DOCKER-USER अधिक समाधान नहीं बनाता है।

@colinmollenhour

यदि आपके पास DOCKER-USER में एक सामान्य ड्रॉप नियम है, तो यह कैसे अलग है यदि डॉकर संलग्न बनाम प्रीपेड यह मुख्य कूद नियम है?

@ cpuguy83 मेरी बात ओवरराइड प्रति-से के खिलाफ नहीं है। मैं जो कह रहा हूं वह यह है कि डॉकर पहले से मौजूद iptables नियमों को ओवरराइड करता है, निश्चित रूप से एक ऑप्ट-इन फीचर होना चाहिए, ऑप्ट-आउट फीचर नहीं।

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

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

मुझे उम्मीद है कि डॉकर केवल सुनने के दृष्टिकोण पर आगे बढ़ेगा , जैसा कि

यदि आपके पास DOCKER-USER में एक सामान्य ड्रॉप नियम है, तो यह कैसे अलग है यदि docker को जोड़ा गया है बनाम यह मुख्य कूद नियम है?

मुझे नहीं लगता कि मैं आपका प्रश्न समझता हूं... कृपया मेरी 22 अप्रैल, 2017 की टिप्पणी को अनदेखा करें क्योंकि यह केवल उस दृढ़ता के संबंध में है जिसे DOCKER-USER वास्तव में हल करता है। मैं जिस समस्या की ओर इशारा कर रहा हूं वह दृढ़ता के बारे में नहीं है।

@taladar आप थम्स डाउनिंग क्या कर रहे हैं, बिल्कुल?

@jacoscaz

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

हालाँकि, हमें iptables (या ebpf, या कुछ अन्य नेटिंग समाधान) का उपयोग करने की आवश्यकता नहीं हो सकती है और -p द्वारा प्रदान की जाने वाली कार्यक्षमता प्रदान करते हैं ... फ्लिप साइड, यदि आप लोगों को फ़ायरवॉल में छेद करने से रोकना चाहते हैं, उन्हें -p का उपयोग करने से रोकें।

संक्षेप में, आप कर सकते हैं:

1. डॉकर को (डिफ़ॉल्ट रूप से) एक विशिष्ट पते से बांधें (डिफ़ॉल्ट पता निश्चित रूप से 0.0.0.0 या सभी इंटरफेस है) ... हालांकि यह किसी को मैन्युअल रूप से -p में पता निर्दिष्ट करने से नहीं रोकेगा -p 1.2.3.4:80:80 )
2. कस्टम नियमों को DOCKER-USER में इंजेक्ट करें, जिसमें सभी को अस्वीकार करना शामिल है
3. --iptables=false साथ iptables प्रबंधन अक्षम करें

क्या आप कुछ और सुझाव दे सकते हैं जिसमें मौजूदा उपयोगकर्ताओं को तोड़ना शामिल नहीं है?

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

जहां तक ​​चीजें अब की जा सकती हैं, इसके बारे में अतिरिक्त दस्तावेज सबसे पहले और सबसे महत्वपूर्ण होना चाहिए। docker.com के अनुरक्षकों के साथ इसे बढ़ाने के लिए सबसे उपयुक्त चैनल कौन सा होगा?

उनकी ओर से रुचि की अनुपस्थिति में, इस बातचीत को जीवित रखना संभवतः इस व्यवहार के अधिक व्यापक रूप से ज्ञात होने की संभावना को अधिकतम करने का सबसे अच्छा तरीका है।

मैं इस कार्यक्षमता के लिए अतिरिक्त दस्तावेज़ जोड़ने के लिए कॉल से सहमत हूं। जहाँ तक मैं बता सकता हूँ इसका उल्लेख केवल https://docs.docker.com/network/iptables/ पर किया गया है

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

जैसा कि सुझाव दिया गया था कि मैंने कंटेनर को गलती से बाहर के संपर्क में आने से रोकने के लिए DOCKER-USER में एक DROP नियम जोड़ा (जो खतरनाक रूप से हुआ)।

हालांकि, अब मेरे पास एक सेवा है जिसे मैं उजागर करना चाहता हूं। लेकिन जैसा कि @colinmollenhour ने समझाया है, क्योंकि NAT फ़िल्टरिंग से पहले होता है, मैं केवल docker ip (जो तय नहीं है) और आंतरिक पोर्ट नंबर (जो कई कंटेनरों के लिए समान हो सकता है) पर फ़िल्टर कर सकता हूं।

तो मैं इस एक सेवा को कैसे उजागर कर सकता हूं?

@SystemParadox यह कई कारणों में से एक है कि DOCKER-USER समस्या का वास्तविक समाधान नहीं है।

@cpuguy83
मुझे प्रस्तावित LISTEN समाधान पसंद है, और मैंने कभी भी एक रिलीज़ से दूसरे रिलीज़ में ब्रेकिंग परिवर्तन की वकालत नहीं की है; बल्कि उचित नोटिस के साथ संस्करणों की एक श्रृंखला में परिवर्तन करने की वकालत की बी/सी मुझे एहसास है कि बहुत से लोग डॉकर का उपयोग करते हैं और एक संस्करण से दूसरे संस्करण में ब्रेकिंग परिवर्तन सभी के लिए हानिकारक होगा।

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

इसके अलावा, https://github.com/moby/moby/issues/22054#issuecomment -425580301 में समाधान वास्तव में काम नहीं करता है। क्यों? मैं सीधे डॉकर नहीं चलाता, मैं डॉकर कंपोज़ के माध्यम से चलता हूं - वाईएएमएल पर आधारित; आईपी ​​​​पते गतिशील हैं (डॉकर द्वारा नियंत्रित) और अक्सर मैं एक ही डॉकर नेटवर्क के भीतर कई सेवाओं को तैनात करता हूं जिन्हें एक दूसरे के साथ बातचीत करने की आवश्यकता होती है। इस प्रकार -p उपयोग और पता बाध्यकारी उपयोग (पुनरावर्तन में विकल्प 1) दोनों ही गैर-समाधान हैं। DOCKER-USER वास्तव में कुछ भी हल नहीं करता है जैसा कि अन्य ने बताया है (रिकैप में विकल्प 2) और IP टेबल्स को पूरी तरह से अक्षम करना (रिकैप में विकल्प 3) भी कुछ भी मदद नहीं करता है b/c अब सब कुछ टूट गया है (IPs गतिशील हैं इसलिए समाधान को स्क्रिप्ट करना कठिन है; अंतर-कंटेनर नेटवर्किंग टूट गई है b/c डॉकर कंटेनरों के बीच स्थानांतरित करने के लिए IPTables पर निर्भर करता है; आदि)।

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

वैकल्पिक हल के रूप में, आप -m conntrack --ctorigdstport का उपयोग करके मूल गंतव्य पोर्ट तक पहुंच सकते हैं।

तो मेरे मामले में मेरे पास निम्न है:

-A DOCKER-USER -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Allow docker out
-A DOCKER-USER -s 172.17.0.0/16 -j ACCEPT
# Allow access to docker service mapped to host 8702 (the service is actually listening on port 8088 in the container)
-A DOCKER-USER -p tcp -m conntrack --ctorigdstport 8702 -j ACCEPT
# Prevent access to docker from outside
-A DOCKER-USER -j DROP

@सिस्टमपैराडॉक्स

सही iptables समाधान के लिए हुर्रे! मैं

मैंने --ctorigdstport बारे में कभी नहीं सुना था, लेकिन मुझे लगता है कि ऐसा इसलिए है क्योंकि मैंने हर संभव iptables एक्सटेंशन के बारे में नहीं पढ़ा है और कोशिश की है और आप इस संदर्भ में मेरे ज्ञान के लिए इसका उल्लेख करने वाले पहले व्यक्ति हैं।

मैंने परीक्षण किया और यह वास्तव में काम करता है:

$ docker run -d -p 7777:6379 --name data1 redis
$ docker run -d -p 8888:6379 --name data2 redis
$ sudo iptables -N DOCKER-USER-redis1
$ sudo iptables -A DOCKER-USER-redis1 -s 192.168.56.0/24 -p tcp -m tcp -j RETURN
$ sudo iptables -A DOCKER-USER-redis1 -j REJECT --reject-with icmp-port-unreachable
$ sudo iptables -N DOCKER-USER-redis2
$ sudo iptables -A DOCKER-USER-redis2 -s 10.0.24.0/24 -p tcp -m tcp -j RETURN
$ sudo iptables -A DOCKER-USER-redis2 -j REJECT --reject-with icmp-port-unreachable
$ sudo iptables -A DOCKER-USER -i eth0 -p tcp -m conntrack --ctorigdstport 7777 -j DOCKER-USER-redis1
$ sudo iptables -A DOCKER-USER -i eth0 -p tcp -m conntrack --ctorigdstport 8888 -j DOCKER-USER-redis2

मुझे लगता है कि इस तरह का एक उदाहरण दस्तावेज़ों में है क्योंकि इसमें शायद 99% उपयोगकर्ता क्या ढूंढ रहे हैं: -p का उपयोग करके बंदरगाहों को उजागर करने की क्षमता लेकिन फिर भी -s जैसे सामान्य फ़िल्टर का उपयोग करके उन पर यातायात को नियंत्रित करने में सक्षम हो

मैंने iptables के संबंध में डॉकर प्रलेखन को अद्यतन करने के लिए एक अनुरोध बनाया।

https://github.com/docker/docker.github.io/issues/8087

https://unrouted.io/2017/08/15/docker-firewall/ में सूचीबद्ध समाधान
कुछ ऐसा ही लगता है, एक अतिरिक्त iptables श्रृंखला बनाना जिसे FILTERS . कहा जाता है
जहां चेन इनपुट और DOCKER-USER कूदते हैं।

@SystemParadox @colinmollenhour --ctorigdstport परीक्षण के बाद मैं पुष्टि कर सकता हूं कि यह काम करता है, लेकिन एक छोटी सी चेतावनी के साथ।

मेरे मामले में, मेरे पास अपाचे पर पोर्ट 80 पर एक डॉकराइज्ड PHP एप्लिकेशन है। मेरे नियम केवल 1.2.3.4 की अनुमति इस प्रकार हैं:

-A DOCKER-USER -s 1.2.3.4/32 -i eth0 -p tcp -m conntrack --ctorigdstport 80 -j ACCEPT
-A DOCKER-USER -i eth0 -p tcp -m conntrack --ctorigdstport 80 -j DROP

तो मेरा छोड़ने का नियम आपके से थोड़ा अधिक विशिष्ट है, मेरे वेबसर्वर को मारने वाले केवल पैकेट छोड़ना - या तो मैंने सोचा। वास्तव में, यह मेरे वेबसर्वर को निर्देशित पैकेट के साथ- साथ तीसरे पक्ष के सर्वर पर PHP एप्लिकेशन द्वारा किए गए अनुरोधों से प्रतिक्रियाओं के साथ

यह इस तथ्य के कारण है कि --ctorigdstport फ़िल्टर किए जा रहे पैकेट पर गंतव्य पोर्ट से मेल नहीं खाता है, लेकिन उस पैकेट पर जिसने कनेक्शन शुरू किया है। इसलिए, डॉकर से अन्य सर्वरों पर जाने वाले अनुरोधों की प्रतिक्रियाओं में SPT=80 होगा और यह भी --ctorigdstport 80 से मेल खाएगा।

यदि कोई DROP नियमों में सख्त नियंत्रण रखना चाहता है, तो --ctdir भी जोड़ना होगा:

-A DOCKER-USER -i eth0 -p tcp -m conntrack --ctorigdstport 80 --ctdir ORIGINAL -j DROP

वास्तव में, कनेक्शन की अनुमति देने वाले सभी नियमों में --ctdir जोड़ा जाना चाहिए ताकि उनका अर्थ सटीक रूप से व्यक्त किया जा सके:

-A DOCKER-USER -s 1.2.3.4/32 -i eth0 -p tcp -m conntrack --ctorigdstport 80 --ctdir ORIGINAL -j ACCEPT

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

@SystemParadox हाँ, मुझे दस्तावेज़ों के माध्यम से खुद को सूचित करने का मौका नहीं मिला और प्रतिक्रिया के इंतजार में लटक रहे डॉकर के अनुरोधों से आश्चर्यचकित हो गया। :)

मैं --ctdir ORIGINAL आवश्यकता के कारणों के साथ मंडलियों में चक्कर लगाता रहता हूं। एक तरफ, @jest द्वारा स्पष्टीकरण सही समझ में आता है, और दूसरी तरफ मुझे आम तौर पर उत्तर पैकेट से निपटना नहीं पड़ता है, तो यह यहां अलग क्यों होना चाहिए?

मुझे लगता है कि अंतर यह है कि मेरे पास पहले नियम के रूप में -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT , इसलिए मेरे बाकी नियमों में कभी भी कोई उत्तर पैकेट नहीं दिखता है। इस मामले में, मुझे लगता है कि --ctdir ORIGINAL की सख्त आवश्यकता नहीं है, हालांकि इसे वैसे भी शामिल करना संभवतः सुरक्षित होगा।

@jest , क्या आप इससे सहमत होंगे? संभवतः आपके पास प्रारंभिक ESTABLISHED,RELATED -j ACCEPT नियम नहीं है, यही वजह है कि इससे आपके लिए फर्क पड़ता है?

@jest आपकी पोस्ट एक बड़ी मदद थी, धन्यवाद।

क्या आपका दृष्टिकोण केवल डॉकटर द्वारा प्रबंधित सामान के लिए या हर चीज के लिए आवश्यक है? उदाहरण के लिए, मेरे ssh पोर्ट (22) का डॉकटर से कोई लेना-देना नहीं है। क्या मुझे हमेशा की तरह -m tcp --dport 22 का उपयोग करने की आवश्यकता है, या क्या मुझे -m conntrack --ctorigdstport 22 --ctdir ORIGINAL उपयोग करना चाहिए?

मुझे लगता है कि आपके दृष्टिकोण की आवश्यकता केवल डॉकटर-प्रबंधित ट्रैफ़िक के लिए है, क्योंकि वे पैकेट फ़िल्टर तालिका में मेरे पास आने से पहले मैंगलिंग/नेटिंग से गुजरते हैं। लेकिन, मैं iptables के लिए नया हूं इसलिए मैं किसी ऐसे व्यक्ति से सुनिश्चित होना चाहता हूं जो मुझसे ज्यादा जानता हो!

@ lonix1 docker द्वारा DOCKER श्रृंखला में नियम

@SystemParadox कुछ समय हो गया है और मेरे पास जाँच करने के लिए उस सर्वर तक पहुँच नहीं है, लेकिन अगर मुझे सही से याद है, तो ESTABLISHED,RELATED नियम थे ( ufw-before-input श्रृंखला में UFW द्वारा प्रबंधित)। हालांकि, मेरे मामले में, वे पोर्ट 80 पर डॉकर से इंटरनेट होस्ट के लिए किए गए कनेक्शन के पहले पैकेट (एसवाईएन) से मेल नहीं खाएंगे। और DOCKER-USER में उपयुक्त नियम द्वारा छोड़ दिया जाएगा जब कोई --ctdir नहीं था

@ Ionix1 , होस्ट पर सेवाओं के लिए पैकेट केवल INPUT के माध्यम से जाते हैं, जबकि docker सेवाओं के लिए पैकेट केवल FORWARD और DOCKER-USER के माध्यम से जाते हैं।

उदाहरण के लिए, 10.0.0.1 का बाहरी आईपी और -p 4000:80 और -p 4001:80 दो कंटेनर दिए जाने पर, आपको निम्नलिखित गुणों वाले पैकेट दिखाई देंगे:

INPUT:
dst 10.0.0.1 dport 80 ctorigdst 10.0.0.1 ctorigdstport 80
FORWARD/DOCKER-USER:
dst 172.17.0.5 dport 80 ctorigdst 10.0.0.1 ctorigdstport 4000
dst 172.17.0.6 dport 80 ctorigdst 10.0.0.1 ctorigdstport 4001

तो आप INPUT नियमों के लिए सुरक्षित रूप से --dport 80 उपयोग कर सकते हैं, क्योंकि वे पूरी तरह से अलग श्रृंखलाओं में हैं। जैसा कि आप देख सकते हैं, --ctorigdstport 80 अभी भी मेल खाएगा, लेकिन जब तक आप किसी कारण से इनपुट को मैनेज नहीं कर रहे हैं, मैं शायद ऐसा नहीं करूंगा।

आप यह भी देख सकते हैं कि आप वास्तव में --dport 80 साथ --dst 172.17.0.5 का उपयोग किसी विशिष्ट डॉकटर कंटेनर के लिए पैकेट को फ़िल्टर करने के लिए कर सकते हैं, लेकिन वह IP अनुमानित नहीं है, यही कारण है कि हम --ctorigdstport का उपयोग कर रहे हैं

अंतत: आपको इस बात से अवगत होना चाहिए कि कोई भी नियम किस पैकेट से मेल खा सकता है, यह इस बात पर निर्भर करता है कि आप किस श्रृंखला में हैं, गंतव्य क्या है, और क्या कोई गड़बड़ी चल रही है।

@jest धन्यवाद, यह मेरी सोच की पुष्टि करता प्रतीत होता है।

इसलिए, मुझे UFW से iptables पर स्विच करने के लिए थोड़ी दिशा की आवश्यकता है ...
-क्या मैं सिर्फ "ufw अक्षम" के माध्यम से UFW को बंद कर दूं?
-क्या मैं अपनी खुद की .sh फाइल बना सकता हूं, या कोई मौजूदा फाइल है (मैं DigitalOcean पर उबंटू हूं)?
-मुझे बस डॉकर को "--iptables=false" बताने की जरूरत है? (यह डॉकर के लिए है?)
-DOCKER-USER पहले से ही Docker द्वारा निर्मित और जंजीर में है?

@fredjohnston आप UFW का उपयोग जारी रख सकते हैं। प्रोफ़ाइल /etc/ufw में संग्रहीत हैं। यहां मुद्दा यह है कि डॉकर b/c नहीं दिखाएगा /etc/ufw/applications.d में कोई ऐप प्रोफ़ाइल सूचीबद्ध नहीं है (किसी भी अन्य फ़ायरवॉल टूल और इसके कॉन्फ़िगरेशन के लिए समान)।

Docker में IPTables को डिसेबल करने का मतलब है कि Docker में आपके पास ज्यादा नेटवर्किंग नहीं होगी, बस IP एड्रेस और कंटेनर एक-दूसरे से बात नहीं कर पाएंगे। DOCKER_USER आपको कुछ नियंत्रण देने के लिए एक हैक है, लेकिन वास्तव में इस मुद्दे को हल नहीं करता है - जो वास्तव में डॉकर कंटेनरों को डिफ़ॉल्ट रूप से नेटवर्क पर सार्वजनिक नहीं करने के बारे में है, लेकिन कंटेनर के आईपी पते पर बंद कर दिया गया है।

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

चूंकि मैं यहां किसी भी तरह से हूं - मैं वास्तव में एक संबंधित मुद्दे में भाग रहा हूं जहां यह लिनक्स के अलावा अन्य प्लेटफॉर्म पर भी एक मुद्दा है। निम्न पर विचार करें:

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

अब मान लीजिए कि आप दोनों परियोजनाओं को स्थानीय रूप से चलाना चाहते हैं - उदाहरण के लिए एक साझा पुस्तकालय पर काम करने के लिए जो दोनों परियोजनाएं उपयोग करती हैं ताकि आप इसे आसानी से परीक्षण के लिए अपने कोड में खींच सकें।

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

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

एक उचित समाधान में यहाँ दो गुना है:

1. कंटेनर केवल उनके आईपी के लिए बाध्य होंगे और उनके एक्सपोज्ड पोर्ट उनके संबंधित डॉकर नेटवर्क के भीतर अकेले उनके आईपी के लिए बाध्य होंगे, न कि सिस्टम पर सभी आईपी ( 0.0.0.0 , :: ) से मेल खाते हैं।
2. डॉकर भी डिफ़ॉल्ट रूप से सिस्टम से डॉकर नेटवर्क के मार्ग को सार्वजनिक रूप से उजागर नहीं करेगा। डॉकर नेटवर्किंग का उपयोग वर्तमान में डिज़ाइन किए गए इंटर-नेटवर्क (डॉकर नेटवर्क से डॉकर नेटवर्क) कनेक्शन स्थापित करने के लिए किया जा सकता है, और फिर डिफ़ॉल्ट रूप से स्थानीय होस्ट कनेक्शन की भी अनुमति देता है।
3. उपयोगकर्ता तब बाहरी दुनिया में कंटेनर को बेनकाब करने के लिए उपयुक्त फ़ायरवॉल नियमों को जोड़ने के लिए हुक पर होंगे, जब और यदि वांछित हो - उदाहरण के लिए, पोर्ट फ़ॉरवर्डिंग पोर्ट 443 से उनकी पसंद के कंटेनर के पोर्ट 443 तक।

फिर, यह धीरे-धीरे किया जा सकता है:

• रिलीज़ 1: चरण 1 और 2 लागू करें; लेकिन चेतावनी के साथ गैर-लोकलहोस्ट रूटिंग भी (अस्थायी रूप से) जोड़ें। पोर्ट प्राप्त करने के लिए पहले आओ-पहले पाओ के वर्तमान व्यवहार को बनाए रखा जाता है; और इस व्यवहार के दूर जाने की चेतावनी जारी की जाती है।
• रिलीज़ 1+N: चेतावनी छोड़ें, और गैर-लोकलहोस्ट रूटिंग छोड़ें। उन उपयोगकर्ताओं के लिए चरण 3 की आवश्यकता है जो डॉकर को पोर्ट ऑफ सिस्टम को उजागर करना चाहते हैं और सुनिश्चित करें कि यह अच्छी तरह से प्रलेखित है।

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

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

यहाँ एक दस्तावेज़ अद्यतन अनुरोध है https://github.com/docker/docker.github.io/pull/8357 बोल्ट-ऑन iptables स्थिर कॉन्फ़िगरेशन बनाने के लिए लेकिन मुझे इसकी स्थिति के बारे में निश्चित नहीं है।

संपादित करें: मैंने देखा है कि आपने DOCKER-USER के अर्थ को गलत समझा है। इसका उपयोग "कंटेनर के आईपी पते पर बंद कंटेनर बनाने" के लिए नहीं किया जाता है, बल्कि iptables नियमों के साथ कंटेनर तक पहुंच को फ़िल्टर करने के लिए किया जाता है।

@ aki-k प्रति DOCKER_USER मुझे पता है कि DOCKER_USER कंटेनर को IP पते के विरुद्ध लॉक नहीं करता है और कभी दावा नहीं किया कि उसने ऐसा किया। DOCKER_USER बस सुरक्षा मुद्दे को उपयोगकर्ता को प्रबंधित करने के लिए बदल देता है - जिसका अर्थ है कि उपयोगकर्ता को यह जानना होगा कि उनके फ़ायरवॉल में हेरफेर कैसे किया जाए ताकि यह सुनिश्चित हो सके कि उनके पास वास्तव में एक सुरक्षित वातावरण है। इसे एक उपयोगकर्ता मुद्दा बनाना समान रूप से अस्वीकार्य है क्योंकि अधिकांश उपयोगकर्ता अपने फ़ायरवॉल को प्रबंधित करना नहीं जानते हैं - फ़ायरवॉल नियम कठिन हैं, और यहाँ तक कि हममें से जो फ़ायरवॉल नियम लिखने के बारे में अच्छी तरह से जानते हैं, वे अभी भी अक्सर चीजें गलत कर सकते हैं।

मेरा अनुरोध - और संपूर्ण बिंदु - इस मुद्दे में यह है कि डॉकर को डिफ़ॉल्ट रूप से सुरक्षित होने की आवश्यकता है और ऐसा करने के लिए उपयोगकर्ता के ज्ञान या स्पष्ट हस्तक्षेप के बिना बाहरी दुनिया में कंटेनरों को उजागर नहीं करना चाहिए। और मेरी पिछली टिप्पणी के अनुसार (https://github.com/moby/moby/issues/22054#issuecomment-552951146) ऐसा करने से कुछ अन्य तकनीकी लाभ भी होंगे।

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

इसके बारे में मुझे जो सबसे पहली समस्या रिपोर्ट मिली है, वह 18 मार्च, 2014 की है:

https://github.com/moby/moby/issues/4737

यह शायद एक डिज़ाइन निर्णय है जिसे वे बदलना नहीं चाहते हैं और DOCKER-USER iptables श्रृंखला के साथ ठीक करने का प्रयास करते हैं। आप केवल docker host (-p 127.0.0.1:port:port) पर पोर्ट प्रकाशित करने के लिए docker run के लिए -p विकल्प का उपयोग कर सकते हैं, लेकिन यह समस्या का समाधान भी नहीं कर रहा है।

के स्पष्ट होने दो, डोकर डिफ़ॉल्ट रूप से सुरक्षित है। आपको Docker को पोर्ट फ़ॉरवर्डिंग करने के लिए कहना होगा।

जहां तक ​​सेवाओं के लिए एक दूसरे के साथ संवाद करने की आवश्यकता है, आपको एक्सेस सीमित करने के लिए नेटवर्क ( docker network ) का उपयोग करना चाहिए, पोर्ट फ़ॉरवर्डिंग के लिए नहीं।

आइए स्पष्ट करें, डॉकर _Is_ डिफ़ॉल्ट रूप से सुरक्षित है। आपको Docker को पोर्ट फ़ॉरवर्डिंग करने के लिए कहना होगा।

कृपया अपनी स्थापित iptables सुरक्षा पर चल रहे डॉकटर के साथ एक तथ्यात्मक समस्या को खारिज न करें। मुझे यकीन है कि आपने इस पर चर्चा करने वाली अनगिनत मुद्दों की रिपोर्ट देखी होगी।

आइए स्पष्ट करें, डॉकर _Is_ डिफ़ॉल्ट रूप से सुरक्षित है। आपको Docker को पोर्ट फ़ॉरवर्डिंग करने के लिए कहना होगा।

जहां तक ​​सेवाओं के लिए एक दूसरे के साथ संवाद करने की आवश्यकता है, आपको एक्सेस सीमित करने के लिए नेटवर्क ( docker network ) का उपयोग करना चाहिए, पोर्ट फ़ॉरवर्डिंग के लिए नहीं।

आइए स्पष्ट करें - डॉकर तब तक सुरक्षित है जब तक आप इसे डॉकर नेटवर्क के बाहर एक्सेस नहीं करना चाहते। एक बार जब आप इसे स्थानीय होस्ट (127.0.0.1) से भी एक्सेस करना चाहते हैं तो डॉकर डिफ़ॉल्ट रूप से सुरक्षित नहीं है क्योंकि यह 0.0.0.0 के खिलाफ बांधता है और सिस्टम से कंटेनरों को उजागर करता है - उपयोगकर्ता अपने सिस्टम को सुरक्षित करने के लिए जो कुछ भी करता है, उसे बिना दिखाए iptables प्रत्यक्ष उपयोग के अलावा अन्य टूलींग में। DOCKER_USER कभी भी एक उचित समाधान नहीं होगा और न ही होगा क्योंकि इसके लिए उपयोगकर्ता को अंतर्निहित फ़ायरवॉल सिस्टम (लिनक्स पर iptables, मैक जो भी उपयोग करता है, और विंडोज़ पर विंडोज फ़ायरवॉल) के बारे में बहुत अधिक जानकारी की आवश्यकता होती है। इसे अभी भी डिफ़ॉल्ट रूप से सुरक्षित करने की आवश्यकता है। इसे करने का एक बहुत ही आसान तरीका है जैसा कि मैंने पहले https://github.com/moby/moby/issues/22054#issuecomment -552951146 में उल्लिखित किया है और इस पूरे मुद्दे पर कई बार कॉल किया है (हालांकि शायद उतना स्पष्ट रूप से नहीं टिप्पणी)।

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

आइए स्पष्ट करें, डॉकर _Is_ डिफ़ॉल्ट रूप से सुरक्षित है। आपको Docker को पोर्ट फ़ॉरवर्डिंग करने के लिए कहना होगा।
जहां तक ​​सेवाओं के लिए एक दूसरे के साथ संवाद करने की आवश्यकता है, आपको एक्सेस सीमित करने के लिए नेटवर्क ( docker network ) का उपयोग करना चाहिए, पोर्ट फ़ॉरवर्डिंग के लिए नहीं।

आइए स्पष्ट करें - डॉकर तब तक सुरक्षित है जब तक आप इसे डॉकर नेटवर्क के बाहर एक्सेस नहीं करना चाहते। एक बार जब आप इसे स्थानीय होस्ट (127.0.0.1) से भी एक्सेस करना चाहते हैं तो डॉकर डिफ़ॉल्ट रूप से _not_ सुरक्षित है क्योंकि यह 0.0.0.0 के खिलाफ बांधता है [...]

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

लेकिन इसके बजाय, डॉकर पैकेट पर एड्रेस को फिर से लिखने के लिए मैजिक डीएनएटी/मस्कवार्डिंग नियमों को फ़ायरवॉल में इंजेक्ट करता है, इसलिए बेतरतीब ढंग से किसी भी पूर्व-स्थापित नियम प्रणाली को तोड़ देता है।

मेरी राय में यहाँ अमूर्तता का गड़बड़ स्तर सबसे बड़ा बमर है और उपयोगकर्ता को भ्रमित करता है। मुझे नहीं पता कि डॉकर टीम द्वारा --publish मशीनरी को डिजाइन करते समय किन परिदृश्यों पर विचार किया गया था, जो हम यहां देखते हैं, मुझे कोई भी नहीं दिखता है जो निर्णय को सही ठहराता है (शायद प्रदर्शन कारणों के अलावा)।

आइए स्पष्ट करें, डॉकर डिफ़ॉल्ट रूप से सुरक्षित है। आपको Docker को पोर्ट फ़ॉरवर्डिंग करने के लिए कहना होगा।

... जो डॉकर की सबसे अधिक उपयोग की जाने वाली विशेषताओं में से एक है। प्रभावी ढंग से, तुम सिर्फ ने कहा कि डोकर के सबसे अधिक इस्तेमाल किया सुविधाओं में से एक के भीतर पहले से मौजूद फ़ायरवॉल नियमों का एक गैर-दस्तावेजी ओवरराइड default_ द्वारा डोकर _secure बनाता है।

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

आइए आज की स्थिति का आकलन करें:

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

मैंने कुछ लोगों को यह कहते हुए देखा है कि वे एक-दूसरे को सेवाएं देने के लिए -p का उपयोग कर रहे हैं, जिसकी आवश्यकता नहीं होनी चाहिए।
डिफ़ॉल्ट नेटवर्क पर आप सेवाओं को एक साथ जोड़ने के लिए --link का उपयोग कर सकते हैं, कंटेनर DNS पर उपलब्ध है।
गैर-डिफ़ॉल्ट नेटवर्क (उपयोगकर्ता परिभाषित नेटवर्क) पर, कंटेनर DNS द्वारा भी एक-दूसरे तक पहुंच सकते हैं, जिसमें --link माध्यम से उपनाम स्थापित करना, या यहां तक ​​कि एक निर्दिष्ट उपनाम वाले नेटवर्क तक भी शामिल है।

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

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

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

-p कुछ अन्य विकल्प हैं:

1. -p उपयोग न करें, सीधे कंटेनर आईपी से कनेक्ट करें। इसके लिए थोड़ा अतिरिक्त काम करने की आवश्यकता है क्योंकि आपको आईपी देखना है, लेकिन यह डेटा एपीआई से उपलब्ध है। आपको यह सुनिश्चित करने की भी आवश्यकता होगी कि फ़ायरवॉल पर आगे की नीति इसकी अनुमति देती है (यह मानते हुए कि आप किसी भिन्न होस्ट से कनेक्ट हो रहे हैं, वही होस्ट ठीक होना चाहिए)
2. उन सेवाओं के लिए macvlan या ipvlan नेटवर्किंग का उपयोग करें जिन्हें आप होस्ट के नेटवर्क (यानी प्रवेश) से एक्सेस करना चाहते हैं। ये नेटवर्किंग विकल्प कंटेनर को होस्ट के नेटवर्क इंटरफेस से सीधे एक आईपी देते हैं (आप चुनते हैं कि यह किस इंटरफेस से जुड़ा है)।
3. --net=host उपयोग करें, यह सेवा को होस्ट नेटवर्क नेमस्पेस पर चलाता है जिससे सेवा को नेटवर्क इंफ़्रा तक पहुंच प्रदान करता है जो होस्ट पर पहले से मौजूद है।

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

-p का उपयोग करके आप किस उपयोग के मामले को हल करने का प्रयास कर रहे हैं?
क्या आपके पास वास्तविक परिवर्तन के बारे में कुछ विचार हैं जो आप देखना चाहते हैं?

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

@ cpuguy83 यह सब ठीक है और बांका है, लेकिन इस अनुरोध में कुछ भी नहीं बदलता है।

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

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

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

इसके अलावा, लोग अधिकांश वातावरण का प्रबंधन करने के लिए डॉकर कंपोज़ का उपयोग करते हैं, और docker-compose.yml या Dockerfile माध्यम से निर्दिष्ट करते हैं कि एक पोर्ट को उजागर करने की आवश्यकता है ताकि वे इसे स्थानीय रूप से एक्सेस कर सकें। इसलिए use the -p पैरामीटर कहना गलत है क्योंकि वे कभी भी docker कमांड के साथ सीधे इस तरह से इंटरफेस नहीं करते हैं कि यह काम करेगा।

एक बंदरगाह को उजागर करने का मतलब यह नहीं है कि सुरक्षा को तोड़ा जाना चाहिए। मैंने रेखांकित किया है कि आप सुरक्षा को तोड़े बिना स्थानीय सिस्टम के लिए एक पोर्ट को कैसे उजागर कर सकते हैं (https://github.com/moby/moby/issues/22054#issuecomment-552951146) और यह बाहरी जोखिम के प्रबंधन को बंद कर देगा (बंद) सिस्टम) उपयोगकर्ता के हाथों में एक तरह से वे अपने मौजूदा टूलींग से आसानी से नियंत्रित कर सकते हैं।

समाधान:

• डॉकर नेटवर्क का प्रयोग करें
• अकेले डॉकर नेटवर्क और स्थानीय होस्ट पर बंदरगाहों का पर्दाफाश करें
• 0.0.0.0 पर पोर्ट को बाइंड करना बंद करें - या प्रभावी ढंग से ऐसा कर रहे हैं
• पोर्ट ऑफ सिस्टम (ufw, फ़ायरवॉल, आदि) को उजागर करने के लिए उपयोगकर्ताओं को अपने स्वयं के फ़ायरवॉल टूलिंग का उपयोग करने की आवश्यकता होती है।
• इसे आसान बनाने के लिए सामान्य फ़ायरवॉल के लिए एकीकरण प्रदान करें

दूसरे शब्दों में, 127.0.0.1:<port> माध्यम से डॉकटर कंटेनर में किसी सेवा तक पहुँचने के बजाय स्थानीय होस्ट से भी <docker container ip>:<service port> आवश्यकता होती है। यदि लोग सिस्टम से सेवा को उजागर करना चाहते हैं तो वे अपने टूलिंग (ufw, आदि) के माध्यम से किसी दिए गए पोर्ट से <docker container ip>:<service port> पोर्ट करने के लिए फ़ायरवॉल नियम जोड़ सकते हैं।

वैकल्पिक रूप से, उनके प्रॉक्सी डिज़ाइन के साथ कुबेरनेट्स दृष्टिकोण का पालन करें, जो कि https://github.com/moby/moby/issues/22054#issuecomment -554665865 में सुझाए गए @jest के रूप में प्रभावी ढंग से कर रहा है। फिर से, यह अभी भी केवल स्थानीय प्रणाली होने की आवश्यकता होगी जब तक कि उपयोगकर्ता उद्देश्यपूर्ण रूप से बाहरी नेटवर्क को उजागर न करे।

यहां सबसे बड़ा मुद्दा यह है कि डॉकर अपनी सेवाएं प्रदान करने के लिए फ़ायरवॉल की अखंडता से समझौता कर रहा है, ऐसा बिना उपयोगकर्ता को बताए, और उपयोगकर्ता के टूलिंग में एकीकृत किए बिना ताकि उपयोगकर्ता न तो इसके बारे में जान सके और न ही इसे नियंत्रित कर सके।

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

एक बुनियादी परीक्षण मामले के रूप में:

• एक डेबियन-आधारित सर्वर सेटअप करें (डेबियन, उबंटू)
• यूएफडब्ल्यू, ओपनएसएसएच सर्वर स्थापित करें
• ufw allow OpenSSH चलाएं
• ufw enable चलाएं

इस बिंदु पर आपके पास एक बहुत ही सुरक्षित सर्वर है; केवल यातायात की अनुमति है या तो (ए) आउटगोइंग ट्रैफिक से संबंधित है या (बी) एसएसएच सर्वर ट्रैफिक है।

अब, एक खुले बंदरगाह के साथ एक डॉकटर कंटेनर शुरू करें।

एक स्वीकार्य समाधान निम्नलिखित को पूरा करेगा:

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

firewalld साथ CentOS/Fedora/RHEL आधारित सिस्टम के लिए भी यही प्रयास करें।

@ cpuguy83 IMO लोग -p से एक आवेदन स्तर पर काम करने की अपेक्षा करते हैं। यही है, अगर मैं -p 80:80 , तो मैं व्यवहार की अपेक्षा करता हूं जैसे कि कंटेनर में पोर्ट 80 के लिए बाध्य एप्लिकेशन होस्ट पर चल रहा था।

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

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

फ़ायरवॉल मामलों में -p समस्याओं को कम करना: सामान्य दुनिया में उपयोगकर्ता अपेक्षा करता है कि 0.0.0.0:80 तक सीमित एप्लिकेशन बाहरी दुनिया को दिखाई दे। यदि उपयोगकर्ता पहुंच को सीमित करना चाहता है, तो उसे कई गाइडों में एक फ़ायरवॉल का उपयोग करने और INPUT श्रृंखला में एक नियम स्थापित करने का निर्देश दिया जाता है:

-P INPUT DROP
-A INPUT -s 1.2.3.4/32 -p tcp --dst-port 80 -j ACCEPT

या UFW जैसे टूल का उपयोग करें:

ufw enable
ufw allow http

लेकिन डॉकटर के साथ, उपयोगकर्ता को नीले रंग से ऐसे नियम बनाने में सक्षम होना चाहिए:

-A DOCKER-USER -s 1.2.3.4/32 -i eth0 -p tcp -m conntrack --ctorigdstport 80 --ctdir ORIGINAL -j ACCEPT
-A DOCKER-USER -i eth0 -p tcp -m conntrack --ctorigdstport 80 --ctdir ORIGINAL -j DROP

कृपया, मुझे एक औसत उपयोगकर्ता के लिए एक व्यापक मार्गदर्शिका दिखाएं कि डॉकर के साथ ऐसे सामान्य परिदृश्यों को कैसे हल किया जाए।

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

इन दिनों मैं अपने ज्ञान की कमी के कारण बंदरगाहों का पर्दाफाश नहीं करता, और इसके बजाय ट्रैफिक जैसी सेवाओं का उपयोग करता हूं। हो सकता है कि --expose भी सीएलआई दस्तावेज़ों में सामान्य उद्देश्य के रूप में प्रस्तावित नहीं किया जाना चाहिए, क्योंकि आईएमओ यह औसत उपयोगकर्ता के लिए कोई अच्छा काम नहीं करता है।

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

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

@dentonmwood यह बिल्कुल वैसा ही लगता है जैसा आपको करना चाहिए। जैसा कि मैंने ऊपर उल्लेख किया है, आप macvlan या ipvlan का उपयोग करके सेवा को चलाने के लिए भी सेटअप कर सकते हैं जो इसे सीधे आपके सामान्य नेटवर्क पर एक आईपी देगा।

@BenjamenMeyer @jest @jacoscaz

अतिरिक्त प्रतिक्रिया के लिए धन्यवाद।

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

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

मैंने सोचा था कि हम स्थानीय पहुंच के उपयोग के मामले के लिए एक स्थानीय प्रॉक्सी (ala kubectl proxy ) कर सकते हैं, हालांकि यह फिर से डेवलपर पर अधिक जानने और समझने की जिम्मेदारी डालता है, जिसकी उन्हें वास्तव में आवश्यकता होनी चाहिए। .

विचार?

मुझे लगता है कि प्रॉक्सी शुरू करना अच्छी दिशा में एक कदम है।

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

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

उदाहरण के लिए, इस समय iptables में /etc/docker/daemon.json जो यह निर्धारित करता है कि DOCKER हेरफेर करना है या नहीं। कॉन्फ़िगरेशन को किसी अन्य प्रविष्टि के साथ बढ़ाया जा सकता है, जैसे कि iptables==true && expose_with_network_proxy==true जैसे संयोजन प्रॉक्सी-जैसे व्यवहार पर स्विच हो जाएंगे।

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

हम मूल रूप से इस स्थिति में संगतता टूटने के डर के कारण हैं।

मैं वास्तव में इस तथ्य पर जोर देना चाहता हूं कि इस मुद्दे की गंभीरता, कम से कम मेरी नजर में, दस्तावेज़ीकरण की कमी के साथ -p के मौजूदा तकनीकी आधार के मुकाबले अधिक है। हां, मुझे विश्वास नहीं है कि वर्तमान तंत्र को _सुरक्षित_ कहा जा सकता है, लेकिन सुरक्षा खामियों को ठीक किया जा सकता है और मैं उन कारणों की आलोचना करने की स्थिति में नहीं हूं जिनके कारण वर्तमान परिदृश्य हुआ। अंत में हमेशा 20/20 होता है, और मैं पिछड़ी संगतता के प्रति प्रतिबद्धता और इस तरह की प्रतिबद्धता में आने वाली तकनीकी चुनौतियों का सामना करने की इच्छा की प्रशंसा करता हूं।

मुझे जो नहीं मिलता है वह यह है कि डॉकर के दस्तावेज़ों में अभी भी कोई उज्ज्वल, बड़ा, लाल बक्से नहीं हैं, जो स्पष्ट रूप से -p का उपयोग करने के दुष्प्रभावों के खिलाफ चेतावनी देते हैं। अगर मुझे ऐसी कोई चेतावनी मिली होती तो मुझे नहीं लगता कि मैं यहां पहले स्थान पर होता।

विचार?

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

@BenjamenMeyer @jest @jacoscaz

अतिरिक्त प्रतिक्रिया के लिए धन्यवाद।

अंत में इसे और करीब से देखने के लिए धन्यवाद।

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

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

विचार?

1. दस्तावेज़ीकरण को अद्यतन करने के साथ प्रारंभ करें ताकि उपयोगकर्ता सभी विधियों (-p, Dockerfile, docker-compose.yml) से EXPOSE के प्रभाव से अवगत हों। इतना जल्दी किया जा सकता है। यह इस मुद्दे पर कुछ ध्यान आकर्षित करने में भी मदद कर सकता है ताकि अधिक लोगों को एक अच्छा समाधान खोजने में सलाह/विशेषज्ञता की पेशकश की जा सके और अगर इस पर पिछड़ा संगतता की सामुदायिक इच्छा हो तो जवाब देने में मदद मिल सकती है।
2. डॉकर अब जहां है वहां से जाने के लिए एक विधि की योजना बनाएं जहां डॉकर को होना चाहिए। इसमें किसी बिंदु पर एक ब्रेकिंग परिवर्तन शामिल हो सकता है।

मुझे लगता है कि स्थिति की गंभीरता निश्चित रूप से इसे ठीक करने के लिए एक ब्रेकिंग बदलाव की अनुमति देती है; बस लोगों को बताए बिना ऐसा न करें। एक समयरेखा (6 महीने? 12 महीने?) निर्धारित करें जहां परिवर्तन पर भारी चर्चा हो, आदि और आप समुदाय को तैयार करते हैं; फिर "प्रमुख" संस्करण में परिवर्तन करें। आपके संस्करण स्कीमा के आधार पर ऐसा लगता है कि पहला सेट वर्ष (19) है; यह देखते हुए कि हम 2019 के अंत में हैं, समाधान निकालने और उसका विज्ञापन करने के लिए शेष 2019 और फिर 2020 का उपयोग करें; इसे 2020 में किसी समय वैकल्पिक सुविधा के रूप में पेश करें और फिर 2021 में इसे पहले स्थान/डिफ़ॉल्ट उपयोग के लिए प्रचारित करें।

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

हालाँकि इसे शुरू किया गया है, मुझे लगता है कि आप इस तरह के बदलाव के लिए समग्र समुदाय को बहुत अधिक सहायक पाएंगे यदि वे समझते हैं कि क्यों और क्या हो रहा है और ऐसा नहीं लगता कि वे इससे अंधे हैं।

मैंने सोचा था कि हम स्थानीय पहुंच के उपयोग के मामले के लिए एक स्थानीय प्रॉक्सी (ala kubectl proxy ) कर सकते हैं, हालांकि यह फिर से डेवलपर पर अधिक जानने और समझने की जिम्मेदारी डालता है, जिसकी उन्हें वास्तव में आवश्यकता होनी चाहिए। .

मुझे प्रॉक्सी विचार पसंद है, और @jest का सुझाव है कि इसे कैसे सक्षम किया जाए, यह भी माइग्रेशन करने का एक शानदार तरीका हो सकता है।

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

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

मुझे प्रॉक्सी विचार पसंद है, और @jest का सुझाव है कि इसे कैसे सक्षम किया जाए, यह भी माइग्रेशन करने का एक शानदार तरीका हो सकता है।

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

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

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

डॉकर मैकओएस फ़ायरवॉल को उसी तरह बायपास करता है जैसे वह लिनक्स पर करता है।

मेरी विकास मशीन (मैक के लिए डॉकर डेस्कटॉप) पर मैंने डॉकर डेमॉन कॉन्फ़िगरेशन में "ip": "127.0.0.1" जोड़ा। इस तरह कोई भी विकास डेटाबेस आदि डिफ़ॉल्ट रूप से केवल स्थानीयहोस्ट से ही पहुंच योग्य होगा। उन दुर्लभ मामलों के लिए जिन्हें मुझे ऐप को दूसरों के लिए दृश्यमान बनाने की आवश्यकता है, मैं इसे -p 0.0.0.0:8080:8080 साथ स्पष्ट रूप से प्रकाशित कर सकता हूं।

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

@luontola क्या एक सुंदर समाधान है।

संपादित करें: जो मैं भी सोच रहा था वह शायद पतों की अनुमति/ब्लॉक सूची रखने का एक तरीका था जिसे परिभाषित किया जा सकता था उदाहरण के लिए डॉकर कंपोज़ जो तब स्वचालित रूप से DOCKER-USER iptables श्रृंखला में जोड़ा जाएगा।

एक छोटा ऊप्सी डेज़ी जो इस मुद्दे के महत्व पर प्रकाश डालता है: https://github.com/docker/for-linux/issues/810 (सारांश: DOCKER-USER को हटा दिया गया था, भले ही आपने dockers बाहरी एक्सेस को ब्लॉक करने के लिए iptables को कॉन्फ़िगर किया हो, यह उस अतिरिक्त कॉन्फ़िगरेशन को अनदेखा करेगा और सभी कंटेनरों को उजागर करेगा)

@danhallin आपकी जैसी टिप्पणियाँ वास्तव में कुछ स्थितियों में दिन बचा सकती हैं। साझा करने के लिए धन्यवाद।

हम्म दिलचस्प पढ़ना!

मैं मैक ओएस एक्स पर चल रहा हूं और लिटिलस्निच नामक एक स्थानीय फ़ायरवॉल भी है। यह सिर्फ एक संवाद को पॉप अप करके पूछता है कि क्या यह 185.156.177.252 के लिए com.docker.backend प्रक्रिया से कनेक्ट करने के लिए ठीक था। मैंने इनकार पर क्लिक किया।

मैं सोच रहा था कि यह मेरे राउटर में एक पोर्ट को आगे कैसे खोल सकता है, लेकिन मुझे अभी एहसास हुआ है कि यह निश्चित रूप से UPnP के माध्यम से किया जाता है! सभी राउटर इसका समर्थन करते हैं।

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

@ cpuguy83 यह सब ठीक है और बांका है, लेकिन इस अनुरोध में कुछ भी नहीं बदलता है।

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

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

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

इसके अलावा, लोग अधिकांश वातावरण का प्रबंधन करने के लिए डॉकर कंपोज़ का उपयोग करते हैं, और docker-compose.yml या Dockerfile माध्यम से निर्दिष्ट करते हैं कि एक पोर्ट को उजागर करने की आवश्यकता है ताकि वे इसे स्थानीय रूप से एक्सेस कर सकें। इसलिए use the -p पैरामीटर कहना गलत है क्योंकि वे कभी भी docker कमांड के साथ सीधे इस तरह से इंटरफेस नहीं करते हैं कि यह काम करेगा।

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

समाधान:

* Use Docker Network

* Expose the Ports on the Docker Network alone and local host

* Stop binding the port on 0.0.0.0 - or effectively doing so

* Require users to use their own firewall tooling to expose the port off system (ufw, firewalld, etc)

* Provide integrations for common firewalls to make this easy

दूसरे शब्दों में, 127.0.0.1:<port> माध्यम से डॉकटर कंटेनर में किसी सेवा तक पहुँचने के बजाय स्थानीय होस्ट से भी <docker container ip>:<service port> आवश्यकता होती है। यदि लोग सिस्टम से सेवा को उजागर करना चाहते हैं तो वे अपने टूलिंग (ufw, आदि) के माध्यम से किसी दिए गए पोर्ट से <docker container ip>:<service port> पोर्ट करने के लिए फ़ायरवॉल नियम जोड़ सकते हैं।

वैकल्पिक रूप से, अपने प्रॉक्सी डिज़ाइन के साथ कुबेरनेट्स दृष्टिकोण का पालन करें, प्रभावी ढंग से @jest के रूप में #22054 (टिप्पणी) में सुझाव दिया गया है। फिर से, यह अभी भी केवल स्थानीय प्रणाली होने की आवश्यकता होगी जब तक कि उपयोगकर्ता उद्देश्यपूर्ण रूप से बाहरी नेटवर्क को उजागर न करे।

यहां सबसे बड़ा मुद्दा यह है कि डॉकर अपनी सेवाएं प्रदान करने के लिए फ़ायरवॉल की अखंडता से समझौता कर रहा है, ऐसा बिना उपयोगकर्ता को बताए, और उपयोगकर्ता के टूलिंग में एकीकृत किए बिना ताकि उपयोगकर्ता न तो इसके बारे में जान सके और न ही इसे नियंत्रित कर सके।

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

एक बुनियादी परीक्षण मामले के रूप में:

* Setup a Debian-based server (Debian, Ubuntu)

* Install ufw, OpenSSH Server

* run `ufw allow OpenSSH`

* run `ufw enable`

इस बिंदु पर आपके पास एक बहुत ही सुरक्षित सर्वर है; केवल यातायात की अनुमति है या तो (ए) आउटगोइंग ट्रैफिक से संबंधित है या (बी) एसएसएच सर्वर ट्रैफिक है।

अब, एक खुले बंदरगाह के साथ एक डॉकटर कंटेनर शुरू करें।

एक स्वीकार्य समाधान निम्नलिखित को पूरा करेगा:

* The port should not be accessible from another computer; the firewall should continue to block it from outside systems.

* The port should be accessible from the local computer (localhost).

* Multiple docker containers should be able to expose the same port and have everything work; all containers with an exposed port should be accessible from the local system only.

* The user should not have to know about their firewall configuration details to make this happen.

firewalld साथ CentOS/Fedora/RHEL आधारित सिस्टम के लिए भी यही प्रयास करें।

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

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

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

मेरा पहला आश्चर्य यह था कि मेरा कंटेनरीकृत Nginx प्रॉक्सी पूरे इंटरनेट के लिए सुलभ था। मेरे पास अपने फ़ायरवॉल नियमों में एक विकल्प है कि मैं दुनिया से आने वाले वेब ट्रैफ़िक को अनुमति दूं। लेकिन मैंने अभी तक उस सुविधा को चालू नहीं किया था। मेरे iptables में कहीं भी यह स्पष्ट नहीं है कि HTTP 80/443 की अनुमति है।

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

Nginx पर मेरे आश्चर्य के बाद, मैंने बुद्धिमानी से दोबारा जांच करने का फैसला किया कि MySQL भी उजागर नहीं हुआ था। मैंने अपने दूरस्थ VPS पर MySQL डेटाबेस से (अपने लैपटॉप से) कनेक्ट करने का प्रयास किया। और फिर से चौंक गया जब मैं तुरंत सफलतापूर्वक जुड़ा।

मैं जो कुछ भी नहीं कह रहा हूं उस पर पिछली पोस्टों में विस्तार से चर्चा नहीं की गई है। उनकी मददगार जांच और सुझावों के लिए @BenjamenMeyer @jest @jacoscaz को बहुत-बहुत धन्यवाद। लेकिन उन लोगों के लिए जो आधुनिक उपयोग-मामलों और अनुभवों की मांग कर रहे हैं? यहां आप इसे रखते हैं। इस धागे के शुरू होने के 4 साल बाद, मेरे जैसे लोग अभी भी इस व्यवहार का सामना कर रहे हैं। और अभी भी दूर आकर स्तब्ध महसूस कर रहा हूँ।

हां, बहुत सारे उपाय हैं। मैं तुरंत कुछ का पीछा करूंगा। लेकिन उन्हें लागू करने के लिए, आपको वास्तव में यह जानना होगा

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

यदि अन्य इसे उपयोगी पाते हैं तो इस मुद्दे के लिए अपना समाधान साझा करना चाहते हैं। iptables और ipset का उपयोग करना। Ubuntu, CentOS 7 और RHEL 7 पर परीक्षण किया गया। ipset का उपयोग किया जाता है क्योंकि "विश्वसनीय" IP हमेशा एक ही IP श्रेणी में नहीं होते हैं (iptables की सीमा तय करें)।
यह सामान्य डॉकर, और डॉकर झुंड (उर्फ स्वार्मकिट) के साथ काम करता है।
यह सुनिश्चित करता है कि आप डिफ़ॉल्ट रूप से सुरक्षित हैं, केवल आपके द्वारा निर्दिष्ट IP को OS पोर्ट और डॉकर पोर्ट (iptables और ipset का उपयोग करके) से कनेक्ट करने में सक्षम होने की अनुमति देता है जो आपके द्वारा निर्दिष्ट किया जाना चाहिए। ओएस पोर्ट या डॉकर पोर्ट को "सार्वजनिक" बनाने का विकल्प भी है (सभी आईपी के लिए खुला)

Ansible की आवश्यकता नहीं है, लेकिन यह आसान बनाता है .. उत्तरदायी भूमिका: https://github.com/ryandaniels/ansible-role-iptables-docker
CentOS/RHEL के लिए मैन्युअल चरण:
https://github.com/ryandaniels/ansible-role-iptables-docker#manual -commands-centosrhel
और उबंटू 18.04/20.04:
https://github.com/ryandaniels/ansible-role-iptables-docker#manual -commands-ubuntu-2004

आपको iptables के अलावा ipset को स्थापित/कॉन्फ़िगर करने की आवश्यकता होगी (समस्या होने पर उपरोक्त लिंक देखें)।
उदाहरण iptables config (ssh पोर्ट 22 के साथ सभी के लिए खुला):

*filter
:DOCKER-USER - [0:0]
:FILTERS - [0:0]
#Can't flush INPUT. wipes out docker swarm encrypted overlay rules
#-F INPUT
#Use ansible or run manually once instead to add -I INPUT -j FILTERS
#-I INPUT -j FILTERS
-A DOCKER-USER -m state --state RELATED,ESTABLISHED -j RETURN
-A DOCKER-USER -i docker_gwbridge -j RETURN
-A DOCKER-USER -s 172.18.0.0/16 -j RETURN
-A DOCKER-USER -i docker0 -j RETURN
-A DOCKER-USER -s 172.17.0.0/16 -j RETURN
#Below Docker ports open to everyone if uncommented
#-A DOCKER-USER -p tcp -m tcp -m multiport --dports 8000,8001 -j RETURN
#-A DOCKER-USER -p udp -m udp -m multiport --dports 9000,9001 -j RETURN
-A DOCKER-USER -m set ! --match-set ip_allow src -j DROP
-A DOCKER-USER -j RETURN
-F FILTERS
#Because Docker Swarm encrypted overlay network just appends rules to INPUT
-A FILTERS -p udp -m policy --dir in --pol ipsec -m udp --dport 4789 -m set --match-set ip_allow src -j RETURN
-A FILTERS -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FILTERS -p icmp -j ACCEPT
-A FILTERS -i lo -j ACCEPT
#Below OS ports open to everyone if uncommented
-A FILTERS -p tcp -m state --state NEW -m tcp -m multiport --dports 22 -j ACCEPT
#-A FILTERS -p udp -m udp -m multiport --dports 53,123 -j ACCEPT
-A FILTERS -m set ! --match-set ip_allow src -j DROP
-A FILTERS -j RETURN
COMMIT