Секреты в ARG и ENV

Секреты нельзя хранить в ARG и ENV, потому что они попадают в слои образа, историю сборки, манифесты и логи, и их легко прочитать через docker history, docker inspect или инструменты оркестраторов.

Такие значения размножаются по кэшу и артефактам CI/CD, их практически невозможно полностью удалить и безопасно отозвать.

Для секретов используют Docker/Kubernetes Secrets, внешние секрет-менеджеры и build-time secrets, которые не вшиваются в финальный образ.

Конструкции ARG и ENV удобны для конфигурации, но не предназначены для хранения чувствительных данных. Их ключевая проблема в том, что значения становятся частью образа, истории сборки и окружения контейнера, а эти артефакты широко распространяются, кэшируются и доступны множеству людей и систем.

• Попадание в слои образа и метаданные. Значения ARG и ENV сохраняются в слоях и метаданных образа. Их можно увидеть командами docker history, docker inspect или через UI реестра образов, то есть любой с доступом к реестру может прочитать секрет.
• Размножение по кэшу и артефактам CI/CD. Пайплайны сборки, кэш Docker, артефакты CI, экспортированные образы, бэкапы реестров и логов могут содержать эти значения. Полностью вычистить все копии почти нереально, поэтому такой секрет фактически считается навсегда скомпрометированным.
• Простой доступ на ноде или в кластере. В рантайме переменные окружения легко читать: через docker inspect, kubectl describe pod, дампы процессов и отладчики. Это нарушает принцип наименьших привилегий: любой с техдоступом к ноде может увидеть секрет.
• Сложность ротации и отзыва. Как только значение попало в образ и разошлось по реестрам и окружениям, его нельзя считать контролируемым. Смена переменной окружения в одном месте не гарантирует, что старый секрет не остался в кэше, старых образах или логах.
• Риск утечки в логи и метрики. Скрипты и приложения нередко логируют окружение при старте или диагностике. Если секреты лежат в ENV, они легко оказываются в логах, к которым часто есть более широкий доступ, чем к самим контейнерам.

Рекомендованный подход — хранить секреты в специализированных механизмах: Docker/Kubernetes Secrets, HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager и т.п. При сборке использовать build-time secrets (например, docker buildx build --secret ...), которые доступны только во время нужного шага и не попадают в финальный образ. В рантайме секреты монтируются как файлы/volume или подтягиваются по API, а не зашиваются в образ через ARG и ENV.

Пример, как делать не нужно: пароль базы передаётся через ARG/ENV и навсегда остаётся в истории образа и в переменных окружения контейнера.

Пример более безопасного подхода: тот же пароль передаётся как build-time secret, используется только на шаге сборки и не попадает в финальный образ и его историю.