Добавление корпоративного CA внутри контейнера не исправит неудачную загрузку образа у коллеги. Успешная загрузка тоже не доказывает, что приложение внутри образа доверяет проверяемой службе HTTPS.

ОперацияДоверие, которое нужно проверить
Загрузка образа через инспекционный прокси организацииХост или среда Docker, выполняющая загрузку
Скачивание во время сборки образаСреда сборки и её загрузчик
Вызов службы HTTPS из работающего приложенияХранилище ОС образа или собственная конфигурация доверия приложения

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

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

Для устойчивого доверия приложения внесите изменение в утверждённый процесс конфигурации образа или приложения. Интерактивное изменение одного работающего контейнера не будет присутствовать в следующем контейнере, созданном из образа.

Распространяйте только необходимый публичный сертификат доверия по авторизованному каналу. Никогда не помещайте закрытый ключ CA в образ и не воспринимайте запрос на установку корневого сертификата от незнакомого публичного прокси как обычную настройку. Оставляйте включённой проверку имени хоста и цепочки после настройки нужного хранилища.

Похожие статьи