container အတွင်း ကုမ္ပဏီ CA ထည့်ခြင်းသည် လုပ်ဖော်ကိုင်ဖက်၏ မအောင်မြင်သော image pull ကို ပြုပြင်၍ မရပါ။ အောင်မြင်သော pull သည်လည်း image အတွင်းရှိ application က စစ်ဆေးထားသော HTTPS ဝန်ဆောင်မှုကို ယုံကြည်ကြောင်း သက်သေမပြပါ။

လုပ်ငန်းစစ်ဆေးရမည့် ယုံကြည်မှု
အဖွဲ့အစည်း၏ စစ်ဆေးရေး proxy မှတဆင့် image ဆွဲခြင်းဆွဲခြင်းကို လုပ်ဆောင်သော host သို့မဟုတ် Docker ပတ်ဝန်းကျင်
image build စဉ် ဒေါင်းလုဒ်လုပ်ခြင်းbuild ပတ်ဝန်းကျင်နှင့် ၎င်း၏ downloader
လည်ပတ်နေသော application မှ HTTPS ဝန်ဆောင်မှုကို ခေါ်ခြင်းimage ၏ OS store သို့မဟုတ် application ၏ ကိုယ်ပိုင်ယုံကြည်မှု ဖွဲ့စည်းမှု

အမှားကို တစ်ဖက်လူကို စစ်ဆေးသော လုပ်ငန်းစဉ်အထိ ခြေရာခံပြီး ထုတ်ပေးသူ၊ host အမည်နှင့် handshake အဆင့်ကို အတည်ပြုပါ။ တရားဝင် စစ်ဆေးရေးဝန်ဆောင်မှုသည် အဖွဲ့အစည်း၏ CA ဖြင့် ဦးတည်ရာ လက်မှတ်ကို လက်မှတ်ထိုးနိုင်သည်။ HTTPS proxy listener ရှိ TLS ကျရှုံးမှုသည် ၎င်းမှတဆင့် ရောက်ရှိသော ဦးတည်ရာ လက်မှတ်၏ ကျရှုံးမှု အလိုအလျောက် မဟုတ်ပါ။ proxy ၏ IP ထည့်ခြင်းသည် ယုံကြည်မှု ပစ္စည်း မပေးပါ။

အတည်ပြုထားသော အများပြည်သူ ထုတ်ပေးသူ လက်မှတ်ကို သက်ဆိုင်ရာ host၊ image ဖြန့်ဖြူးမှု သို့မဟုတ် application ၏ ပံ့ပိုးသော နည်းလမ်းဖြင့် ထည့်သွင်းပါ။ Docker ၏ CA လမ်းညွှန်ချက်သည် host နှင့် container store များကို ဖုံးလွှမ်းသော်လည်း CentOS လမ်းကြောင်းသည် Debian သို့မဟုတ် Windows အတွက် သယ်ဆောင်နိုင်သော ညွှန်ကြားချက် မဟုတ်ပါ။ ထုတ်လုပ်ထားသော bundle တွင် ထည့်ခြင်းကို update က ပယ်ဖျက်နိုင်သည်။ Java application သို့မဟုတ် ကိုယ်ပိုင် CA ဖွဲ့စည်းမှုရှိသော အခြား client သည် OS bundle ကို လုံးဝ လျစ်လျူရှုနိုင်သည်။

application ယုံကြည်မှု တည်တံ့ရန် ပြောင်းလဲမှုကို အတည်ပြုထားသော image သို့မဟုတ် application ဖွဲ့စည်းမှု လုပ်ငန်းစဉ်တွင် ထည့်ပါ။ လည်ပတ်နေသော container တစ်ခုတွင် အပြန်အလှန် တည်းဖြတ်ခြင်းသည် image မှ ဖန်တီးသော နောက် container တွင် ရှိမည် မဟုတ်ပါ။

လိုအပ်သော အများပြည်သူ ယုံကြည်မှု လက်မှတ်ကိုသာ တရားဝင် လမ်းကြောင်းဖြင့် ဖြန့်ဖြူးပါ။ CA ကိုယ်ပိုင်သော့ကို image တွင် ဘယ်တော့မှ မထည့်ပါနှင့်၊ မသိသော အများပြည်သူ proxy ၏ root တပ်ဆင်ရေး တောင်းဆိုမှုကို သာမန် ပြင်ဆင်မှုအဖြစ် မသဘောထားပါနှင့်။ ရည်ရွယ်ထားသော store ကို ဖွဲ့စည်းပြီးနောက် host အမည်နှင့် ကွင်းဆက် စစ်ဆေးမှုကို ဖွင့်ထားပါ။

ဆက်စပ်ဆောင်းပါးများ