Не храните прокси-учётные данные сборки в образах Docker
Используйте предопределённые прокси-входы Docker для сборки и не превращайте временные секреты прокси в постоянные переменные среды образа.
Для загрузки пакетов во время сборки используйте предопределённые прокси-входы Docker, а не сохраняйте временный маршрут в ENV Dockerfile. POSIX-вызов может передать:
HTTP_PROXY=http://203.0.113.10:8080 \
HTTPS_PROXY=http://203.0.113.10:8080 \
docker build --build-arg HTTP_PROXY --build-arg HTTPS_PROXY .Замените конечную точку из документации. Если после имён --build-arg значения не указаны, они берутся из окружения этого вызова. Для этих предопределённых входов объявления ARG не требуются.
Docker по умолчанию исключает эти аргументы прокси из обработки кэша сборки и из docker history. Явная ссылка на них в Dockerfile меняет это поведение, поэтому не добавляйте объявления только потому, что так сделано в другом примере.
Процесс всё равно получает значения. Аутентифицированный URL может утечь через выведенное окружение, журналы, скопированную конфигурацию или последующие операции с образом, даже если один вид истории его скрывает. ENV в Dockerfile делает маршрут частью конечного окружения образа и может превратить прокси только для сборки в зависимость каждого контейнера.
Если команде нужны секретные данные, secret mount BuildKit предоставляет интерфейс секрета на время сборки. Ограничьте учётные данные этой операцией; не выводите mount и не копируйте его содержимое в слой образа.
Эти входы сборки не настраивают ни предыдущую загрузку реестра, выполненную daemon, ни маршрут хоста недоступного удалённого builder. Затем проверьте конечный образ и конфигурацию приложения на постоянные значения прокси, не предполагая, что временная обработка удалила все копии.