Додавання корпоративного CA всередині контейнера не виправить невдале завантаження образу в колеги. Успішне завантаження також не доводить, що застосунок усередині образу довіряє перевіреній службі HTTPS.

ОпераціяДовіра, яку треба дослідити
Завантаження образу через інспекційний проксі організаціїХост або середовище Docker, яке виконує завантаження
Завантаження під час збірки образуСередовище збірки та його завантажувач
Виклик служби HTTPS із запущеного застосункуСховище ОС образу або власна конфігурація довіри застосунку

Простежте помилку до процесу, що перевіряє іншу сторону, потім підтвердьте видавця, ім'я хоста та етап рукостискання. Авторизована інспекційна служба може підписати сертифікат призначення CA організації. Збій TLS на слухачі проксі HTTPS не є автоматично збоєм сертифіката призначення, досягнутого через нього. Введення IP-адреси проксі не дає жодного матеріалу довіри.

Встановіть затверджений публічний сертифікат видавця через підтримуваний механізм відповідного хоста, розповсюдження образу або застосунку. Настанова Docker щодо CA охоплює сховища хоста й контейнера, але шлях для CentOS не є переносною інструкцією для Debian або Windows. Додавання до згенерованого пакета може бути скасоване оновленням; застосунок Java або інший клієнт із власною конфігурацією CA може повністю ігнорувати пакет ОС.

Для тривалої довіри застосунку внесіть зміну до затвердженого процесу конфігурації образу або застосунку. Інтерактивне редагування одного запущеного контейнера не буде присутнє в наступному контейнері, створеному з образу.

Поширюйте лише потрібний публічний сертифікат довіри авторизованим каналом. Ніколи не поміщайте закритий ключ CA в образ і не сприймайте запит на встановлення кореневого сертифіката від незнайомого публічного проксі як звичайне налаштування. Залишайте ввімкненою перевірку імені хоста й ланцюжка після налаштування потрібного сховища.

Схожі статті