კომპანიის CA-ის კონტეინერში დამატება ვერ გამოასწორებს კოლეგის წარუმატებელ image-ის ჩამოტანას. წარმატებული ჩამოტანა ასევე არ ამტკიცებს, რომ image-ის შიგნით არსებული აპლიკაცია ენდობა ინსპექტირებულ HTTPS სერვისს.

ოპერაციაშესამოწმებელი ნდობა
image-ის ჩამოტანა ორგანიზაციის ინსპექციის პროქსის მეშვეობითჰოსტი ან Docker გარემო, რომელიც ასრულებს ჩამოტანას
ჩამოტვირთვა image-ის build-ის დროსbuild-ის გარემო და მისი ჩამომტვირთავი
HTTPS სერვისის გამოძახება გაშვებული აპლიკაციიდანimage-ის OS საცავი ან აპლიკაციის საკუთარი ნდობის კონფიგურაცია

მიადევნეთ შეცდომას კვალს მოპირდაპირე მხარის შემოწმების პროცესამდე, შემდეგ დაადასტურეთ გამომცემი, ჰოსტის სახელი და handshake-ის ეტაპი. ავტორიზებულ ინსპექციის სერვისს შეუძლია დანიშნულების სერტიფიკატი ორგანიზაციის CA-ით მოაწეროს ხელი. TLS-ის ხარვეზი HTTPS პროქსის მსმენელზე ავტომატურად არ ნიშნავს მის მეშვეობით მიღწეული დანიშნულების სერტიფიკატის ხარვეზს. პროქსის IP-ის შეყვანა ნდობის მასალას არ იძლევა.

დააყენეთ დამტკიცებული საჯარო გამომცემის სერტიფიკატი შესაბამისი ჰოსტის, image-ის გავრცელების ან აპლიკაციის მხარდაჭერილი მექანიზმით. Docker-ის CA სახელმძღვანელო მოიცავს ჰოსტისა და კონტეინერის საცავებს, მაგრამ CentOS-ის გზა არ არის გადასატანი ინსტრუქცია Debian-ისთვის ან Windows-ისთვის. გენერირებულ პაკეტზე დამატება შეიძლება გაუქმდეს განახლებით; Java აპლიკაციამ ან საკუთარი CA კონფიგურაციის მქონე სხვა კლიენტმა შეიძლება საერთოდ უგულებელყოს OS-ის პაკეტი.

აპლიკაციის მუდმივი ნდობისთვის ცვლილება შეიტანეთ დამტკიცებულ image-ის ან აპლიკაციის კონფიგურაციის პროცესში. ერთი გაშვებული კონტეინერის ინტერაქტიული რედაქტირება არ იქნება image-იდან შექმნილ შემდეგ კონტეინერში.

გაავრცელეთ მხოლოდ საჭირო საჯარო ნდობის სერტიფიკატი ავტორიზებული არხით. არასოდეს ჩადოთ CA-ის კერძო გასაღები image-ში და უცნობი საჯარო პროქსის root-ის დაყენების მოთხოვნა ჩვეულებრივ კონფიგურაციად არ მიიღოთ. სასურველი საცავის კონფიგურაციის შემდეგ ჩართული დატოვეთ ჰოსტის სახელისა და ჯაჭვის შემოწმება.

დაკავშირებული სტატიები