Прокси-ийн алдаа аль Docker CA сан руу зааж байна вэ?
Эрх бүхий шалгалтын CA-д итгэх үед image татах, build үеийн татан авалт, контейнер аппликейшны хүсэлтүүдийг ялгаарай.
Контейнер дотор компанийн CA нэмэх нь ажилтны амжилтгүй image таталтыг засахгүй. Амжилттай таталт нь image доторх аппликейшн шалгасан HTTPS үйлчилгээг итгэдэг гэдгийг ч батлахгүй.
| Үйлдэл | Шалгах итгэл |
|---|---|
| Байгууллагын шалгалтын проксигоор image татах | Таталтыг гүйцэтгэж буй хост эсвэл Docker орчин |
| Image build үед татах | Build орчин ба түүний татагч |
| Ажиллаж буй аппликейшнаас HTTPS үйлчилгээ дуудах | Image-ийн OS сан эсвэл аппликейшны өөрийн итгэлийн тохиргоо |
Алдааг эсрэг талыг шалгаж буй процесс хүртэл мөрдөж, дараа нь гаргагч, хостын нэр, handshake-ийн үе шатыг баталгаажуулна. Эрх бүхий шалгалтын үйлчилгээ очих сертификатыг байгууллагын CA-аар гарын үсэг зурж болно. HTTPS прокси сонсогч дээрх TLS алдаа нь түүгээр дамжин хүрэх очих сертификатын алдаа автоматаар биш. Проксигийн IP оруулах нь итгэлийн материал өгөхгүй.
Зөвшөөрөгдсөн нийтийн гаргагчийн сертификатыг холбогдох хост, image түгээлт эсвэл аппликейшны дэмждэг механизмаар суулгана. Docker-ийн CA заавар нь хост болон контейнерын санг хамардаг боловч CentOS зам нь Debian эсвэл Windows-д шилжүүлэх боломжтой заавар биш. Үүсгэсэн багцанд нэмэлт оруулсан зүйлийг шинэчлэлт цуцалж болно; Java аппликейшн эсвэл өөрийн CA тохиргоотой бусад клиент OS-ийн багцыг бүрмөсөн үл тоомсорлож болно.
Аппликейшны тогтвортой итгэлийн хувьд өөрчлөлтийг зөвшөөрөгдсөн image эсвэл аппликейшны тохиргооны процесст оруулна. Ажиллаж буй нэг контейнерт интерактив засвар хийсэн нь image-ээс үүсэх дараагийн контейнерт байхгүй.
Зөвхөн шаардлагатай нийтийн итгэлийн сертификатыг эрх бүхий сувгаар түгээнэ. Хэзээ ч image-д CA-ийн хувийн түлхүүр хийхгүй, танихгүй нийтийн проксигийн root суулгах хүсэлтийг ердийн тохиргоо гэж бүү үз. Зорьсон санг тохируулсны дараа хостын нэр болон гинжин хэлхээний шалгалтыг идэвхтэй үлдээнэ.