प्रॉक्सी विफलता किस Docker CA स्टोर की ओर इशारा करती है?
स्वीकृत निरीक्षण CA पर भरोसा करते समय image pulls, build downloads और container application अनुरोधों को अलग करें।
कंटेनर के अंदर कंपनी का CA जोड़ना किसी सहकर्मी के विफल image pull को ठीक नहीं कर सकता। सफल pull यह भी सिद्ध नहीं करता कि image के अंदर का application निरीक्षित HTTPS सेवा पर भरोसा करता है।
| संचालन | जाँचने योग्य भरोसा |
|---|---|
| संगठन के निरीक्षण प्रॉक्सी के माध्यम से image खींचना | pull करने वाला host या Docker वातावरण |
| image build के दौरान डाउनलोड करना | build वातावरण और उसका downloader |
| चल रहे application से HTTPS सेवा कॉल करना | image का OS स्टोर या application का अपना भरोसा कॉन्फ़िगरेशन |
त्रुटि का पता उस प्रक्रिया तक लगाएँ जो सामने वाले पक्ष को सत्यापित करती है, फिर issuer, hostname और handshake चरण की पुष्टि करें। स्वीकृत निरीक्षण सेवा गंतव्य प्रमाणपत्र पर संगठन के CA से हस्ताक्षर कर सकती है। HTTPS प्रॉक्सी listener पर TLS विफलता अपने आप उसके माध्यम से पहुँचे गंतव्य प्रमाणपत्र की विफलता नहीं है। प्रॉक्सी का IP दर्ज करने से कोई भरोसा सामग्री नहीं मिलती।
स्वीकृत सार्वजनिक issuer प्रमाणपत्र संबंधित host, image वितरण या application के समर्थित तंत्र से स्थापित करें। Docker का CA मार्गदर्शन host और container स्टोर को कवर करता है, लेकिन CentOS पथ Debian या Windows के लिए सुवाह्य निर्देश नहीं है। बनाए गए बंडल में जोड़ा गया हिस्सा update से रद्द हो सकता है; Java application या अपना CA कॉन्फ़िगरेशन रखने वाला अन्य client OS बंडल को पूरी तरह नज़रअंदाज़ कर सकता है।
स्थायी application भरोसे के लिए परिवर्तन को स्वीकृत image या application कॉन्फ़िगरेशन प्रक्रिया में रखें। किसी एक चल रहे container में किया गया इंटरैक्टिव संपादन image से बनने वाले अगले container में नहीं होगा।
केवल आवश्यक सार्वजनिक भरोसा प्रमाणपत्र अधिकृत चैनल से वितरित करें। कभी भी image में CA निजी कुंजी न रखें और किसी अपरिचित सार्वजनिक प्रॉक्सी के root-install अनुरोध को सामान्य सेटअप न मानें। इच्छित स्टोर कॉन्फ़िगर होने के बाद hostname और chain सत्यापन चालू रखें।