ପ୍ରକ୍ସି ବିଫଳତା କେଉଁ Docker CA ଷ୍ଟୋରକୁ ସୂଚାଉଛି?
ଅଧିକୃତ ନିରୀକ୍ଷଣ CA ଉପରେ ବିଶ୍ୱାସ କରିବା ସମୟରେ image pull, build download ଏବଂ container application ଅନୁରୋଧକୁ ଅଲଗା କରନ୍ତୁ।
କଣ୍ଟେନର ଭିତରେ କମ୍ପାନୀ CA ଯୋଡ଼ିବା ଦ୍ୱାରା ସହକର୍ମୀଙ୍କ ବିଫଳ image pull ଠିକ୍ ହେବ ନାହିଁ। ସଫଳ pull ମଧ୍ୟ ପ୍ରମାଣ କରେ ନାହିଁ ଯେ image ଭିତରର application ନିରୀକ୍ଷିତ HTTPS ସେବାକୁ ବିଶ୍ୱାସ କରେ।
| କାର୍ଯ୍ୟ | ଅନୁସନ୍ଧାନ କରିବାକୁ ଥିବା ବିଶ୍ୱାସ |
|---|---|
| ସଂସ୍ଥାର ନିରୀକ୍ଷଣ ପ୍ରକ୍ସି ମାଧ୍ୟମରେ image ଟାଣିବା | ଟାଣିବା କରୁଥିବା 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 ଏବଂ ଶୃଙ୍ଖଳା ଯାଞ୍ଚ ସକ୍ରିୟ ରଖନ୍ତୁ।