Продолжаем рубрику, в которой разбираем реальные инженерные ситуации и ищем причины проблем, которые не всегда очевидны на первый взгляд.
Сегодня под микроскопом — секреты в Docker
Представим, что разработчику нужно передать API-ключ приложению:
FROM python:3.12ENV API_KEY="super-secret-key"COPY . .CMD ["python", "app.py"]
приложение получает ключ; контейнер запускается; секрет не нужно хранить отдельно от проекта.
Но в таком подходе есть серьёзная проблема.Секрет оказывается внутри Docker-образа.
А образ — это не просто один файл с приложением. Docker хранит историю его слоёв, и информация, которая попала в один из них, может остаться доступной даже после того, как строку удалили из Dockerfile.
То есть разработчик может сделать:
ENV API_KEY="super-secret-key"а потом заменить это на:
ENV API_KEY=""и пересобрать образ.
Но это ещё не означает, что старый ключ исчез из истории.
Как сделать безопаснее Секреты лучше передавать во время запуска контейнера или использовать специальные механизмы управления секретами.
Например:
docker run \ -e API_KEY="$API_KEY" \ my-appТеперь ключ не нужно записывать непосредственно в Dockerfile.
А в более крупных системах для хранения секретов используют специальные инструменты: secret management в Kubernetes, Docker Secrets, Vault и облачные менеджеры секретов.
Docker-образ может попасть:
• в container registry;
• на CI/CD-сервер;
• на сервер разработчика;
• к другому члену команды.
Если внутри образа оказался настоящий API-ключ, пароль или токен, это уже не просто технический долг. Это потенциальный инцидент безопасности.
И даже если секрет быстро удалить из текущей версии кода, он может продолжать существовать в старых слоях, образах или истории сборок.
А доводилось находить API-ключи или пароли прямо в Docker-образах, Git-репозиториях или CI/CD?
#Y_LAB_University #Y_LAB_Actual
