ការបរាជ័យរបស់ proxy ចង្អុលទៅកាន់ Docker CA store មួយណា?

បំបែកការទាញ image, ការទាញយកពេល build និងសំណើកម្មវិធី container នៅពេលទុកចិត្ត CA ត្រួតពិនិត្យដែលបានអនុញ្ញាត។

ការបន្ថែម CA របស់ក្រុមហ៊ុននៅក្នុង container មិនអាចជួសជុលការទាញ image បរាជ័យរបស់សហការីបានទេ។ ការទាញជោគជ័យក៏មិនបញ្ជាក់ថាកម្មវិធីនៅក្នុង image ទុកចិត្តសេវា HTTPS ដែលបានត្រួតពិនិត្យនោះទេ។

ប្រតិបត្តិការការទុកចិត្តត្រូវស៊ើបអង្កេត
ទាញ image តាម proxy ត្រួតពិនិត្យរបស់ស្ថាប័នHost ឬបរិស្ថាន Docker ដែលធ្វើការទាញ
ទាញយកពេល build imageបរិស្ថាន build និងកម្មវិធីទាញយករបស់វា
ហៅសេវា HTTPS ពីកម្មវិធីកំពុងដំណើរការStore OS របស់ image ឬការកំណត់ទុកចិត្តផ្ទាល់របស់កម្មវិធី

តាមដានកំហុសទៅដល់ដំណើរការដែលផ្ទៀងផ្ទាត់ភាគីម្ខាង បន្ទាប់មកបញ្ជាក់អ្នកចេញ ឈ្មោះ host និងដំណាក់កាល handshake។ សេវាត្រួតពិនិត្យដែលបានអនុញ្ញាតអាចចុះហត្ថលេខាលើវិញ្ញាបនបត្រគោលដៅដោយ CA របស់ស្ថាប័ន។ ការបរាជ័យ TLS នៅអ្នកស្តាប់ proxy HTTPS មិនមែនជាការបរាជ័យនៃវិញ្ញាបនបត្រគោលដៅដែលឈានដល់តាមរយៈវាដោយស្វ័យប្រវត្តិទេ។ ការបញ្ចូល IP របស់ proxy មិនផ្តល់សម្ភារៈទុកចិត្តទេ។

ដំឡើងវិញ្ញាបនបត្រអ្នកចេញសាធារណៈដែលបានអនុម័តតាមយន្តការដែលគាំទ្រដោយ host ការចែកចាយ image ឬកម្មវិធីពាក់ព័ន្ធ។ ការណែនាំ CA របស់ Docker គ្របដណ្តប់ store របស់ host និង container ប៉ុន្តែផ្លូវ CentOS មិនមែនជាការណែនាំដែលអាចផ្ទេរទៅ Debian ឬ Windows បានទេ។ ការបន្ថែមទៅកញ្ចប់ដែលបានបង្កើតអាចត្រូវបានលុបដោយការធ្វើបច្ចុប្បន្នភាព។ កម្មវិធី Java ឬ client ផ្សេងទៀតដែលមានការកំណត់ CA ផ្ទាល់ខ្លួនអាចមិនអើពើនឹងកញ្ចប់ OS ទាំងស្រុង។

សម្រាប់ការទុកចិត្តកម្មវិធីជាប់លាប់ ដាក់ការផ្លាស់ប្តូរនៅក្នុងដំណើរការកំណត់ image ឬកម្មវិធីដែលបានអនុម័ត។ ការកែសម្រួលអន្តរកម្មលើ container មួយដែលកំពុងដំណើរការ នឹងមិនមាននៅក្នុង container បន្ទាប់ដែលបង្កើតពី image នោះទេ។

ចែកចាយតែវិញ្ញាបនបត្រទុកចិត្តសាធារណៈដែលចាំបាច់តាមឆានែលដែលបានអនុញ្ញាត។ កុំដាក់កូនសោឯកជន CA ក្នុង image ហើយកុំចាត់ទុកសំណើដំឡើង root ពី proxy សាធារណៈដែលមិនស្គាល់ជាការដំឡើងធម្មតា។ រក្សាការផ្ទៀងផ្ទាត់ឈ្មោះ host និងខ្សែសង្វាក់ឱ្យដំណើរការ បន្ទាប់ពីកំណត់ store ដែលបានបម្រុងទុក។

អត្ថបទពាក់ព័ន្ធ