پروکسی کی ناکامی کس 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 کے لیے قابلِ نقل ہدایت نہیں ہے۔ بنائے گئے bundle میں اضافہ update سے منسوخ ہو سکتا ہے؛ Java application یا اپنی CA ترتیب رکھنے والا دوسرا client OS bundle کو مکمل نظرانداز کر سکتا ہے۔
application کے مستقل بھروسے کے لیے تبدیلی کو منظور شدہ image یا application ترتیب کے عمل میں رکھیں۔ چل رہے ایک container میں انٹرایکٹو ترمیم image سے بننے والے اگلے container میں نہیں ہوگی۔
صرف ضروری عوامی بھروسہ سرٹیفکیٹ مجاز چینل سے تقسیم کریں۔ کبھی image میں CA نجی کلید نہ رکھیں اور کسی نامعلوم عوامی پروکسی کی root-install درخواست کو عام سیٹ اپ نہ سمجھیں۔ مطلوبہ اسٹور ترتیب دینے کے بعد hostname اور زنجیر کی تصدیق فعال رکھیں۔