प्रोक्सी विफलताले कुन Docker CA स्टोरतर्फ संकेत गर्छ?
अधिकृत निरीक्षण CA मा भरोसा गर्दा image pull, build download र 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 का लागि सार्न मिल्ने निर्देशन होइन। बनाइएको बन्डलमा थपिएको कुरा अपडेटले रद्द गर्न सक्छ; Java application वा आफ्नै CA कन्फिगरेसन भएको अर्को client ले OS बन्डललाई पूर्ण रूपमा बेवास्ता गर्न सक्छ।
स्थायी application भरोसाका लागि परिवर्तन स्वीकृत image वा application कन्फिगरेसन प्रक्रियामा राख्नुहोस्। चलिरहेको एउटा container मा गरिएको अन्तरक्रियात्मक सम्पादन image बाट बन्ने अर्को container मा हुनेछैन।
आवश्यक सार्वजनिक भरोसा प्रमाणपत्र मात्र अधिकृत माध्यमबाट वितरण गर्नुहोस्। कहिल्यै image मा CA निजी कुञ्जी नराख्नुहोस् र अपरिचित सार्वजनिक प्रोक्सीको root-install अनुरोधलाई सामान्य सेटअप नमान्नुहोस्। इच्छित स्टोर कन्फिगर भएपछि hostname र चेन प्रमाणीकरण खुला राख्नुहोस्।