Пароль для скачивания приватного артефакта нужен во время сборки, но не должен становиться частью готового образа. Для Docker BuildKit предусмотрены secret mounts. На Mentoring.digital разберём передачу временного файла в одну инструкцию сборки и ограничения этого механизма.
Почему ARG и ENV не подходят
Документация Docker прямо не рекомендует передавать секреты через build arguments и переменные окружения образа. Для таких данных есть специальный канал. Не пытайтесь исправить передачу настоящего ключа простым переименованием переменной или удалением файла позднее в Dockerfile.
Сначала определите, зачем сборке доступ: приватный пакет, API или Git-репозиторий. От этого зависит подходящий механизм. Secret mount передаёт общее чувствительное содержимое, а SSH mount решает отдельный сценарий доступа через SSH. Их нельзя считать взаимозаменяемыми без оценки используемого инструмента.
Минимальный пример без настоящего ключа
# syntax=docker/dockerfile:1
FROM alpine:3.22
RUN --mount=type=secret,id=demo_token,required=true \
test -s /run/secrets/demo_tokendocker build --secret id=demo_token,src=./demo-token.txt -t secret-demo .В demo-token.txt для учебного запуска поместите только подставное значение. Пример проверяет наличие непустого файла и намеренно не печатает его содержимое. Для реального инструмента потребуется собственная команда потребления секрета и проверка её поведения.
Передача состоит из двух частей: клиент сборки отправляет значение под идентификатором, инструкция Dockerfile получает соответствующее монтирование. Несовпадение идентификаторов нельзя исправить только существованием файла на вашей машине. Параметр required помогает явно обнаружить отсутствие ожидаемого секрета.
Временный доступ не запрещает копирование
Файл доступен на время соответствующей инструкции. Но команда внутри неё всё ещё может скопировать содержимое в другой файл, включить его в артефакт или вывести в журнал. Поэтому secret mount не является автоматическим доказательством чистоты всех результатов сборки.
Посмотрите, какие команды выполняются и куда они записывают данные. Особое внимание уделите диагностическому выводу, временным конфигурациям менеджера пакетов и генерируемым файлам. Не включайте подробный режим с настоящим ключом только ради удобного журнала. Для проверки поведения используйте подставные данные.
Контекст сборки проверяется отдельно
Файл, случайно попавший в контекст и затем скопированный общей инструкцией COPY, является другой дорогой утечки. Не храните настоящий секрет рядом с исходниками без понятных правил исключения и доступа. Механизм secret mount не отменяет проверку содержимого контекста и репозитория.
Опишите два потока отдельно: что отправляется как обычный файл проекта и что передаётся специальным параметром сборки. Если эти пути смешаны, визуальное отсутствие ключа в Dockerfile не подтверждает безопасную передачу. Простой учебный пример полезен именно тем, что позволяет увидеть границу каждого механизма.
Как проверить результат честно
Проверьте успешный запуск с подставным файлом и ожидаемый отказ без обязательного секрета. Затем изучите журналы и файлы результата на наличие учебного значения. Такой тест подтверждает выбранный пример, а не все возможные команды будущей сборки. Для каждого инструмента потребления нужны свои условия проверки.
В этой статье Dockerfile и параметры разобраны по официальной документации; запуск сборки здесь не заявляется. Не переносите команды в рабочую инфраструктуру без согласованной среды и проверки версии инструментария. Для разбора цепочки сборки можно выбрать наставника по Backend с соответствующим опытом. Если настоящий ключ уже раскрыт, удаление строки не отменяет факт раскрытия: дальнейшие действия определяются правилами владельца ключа.
