Этап 9 - Docker Security
Docker security начинается с реалистичного предположения: containers изолированы, но это не магические sandboxes. Они используют общий host kernel, поэтому снижение privileges важно.
Security model
Запуск от root внутри container распространен, но рискован. Если application скомпрометирована, attacker получает больше возможностей внутри container. Dockerfile должен создавать или использовать non-root user после установки packages и подготовки files.
trusted base image
minimal packages
non-root user
scan image
inject secrets at runtime
Users, scanners и secrets
Image scanning проверяет известные vulnerabilities в OS packages и libraries. Это не доказательство безопасности. Это early warning system, которая ловит известные CVE до deployment.
Secrets должны приходить в runtime, а не во время image build. Если Dockerfile копирует .env или private key, удаление позже не обязательно убирает его из image history. Environment variables удобны, но очень sensitive values требуют controlled secret mechanism в целевой platform.
Least privilege на практике
Least privilege означает, что process получает только те permissions, которые ему нужны. В Docker это начинается с отказа от запуска application от root без явной причины. Также сюда входят ограничение Linux capabilities, отказ от unnecessary mounts и запрет на Docker socket в обычных application containers.
Docker socket особенно опасен. Container с доступом к нему часто может управлять Docker на host. Для новичка правило простое: не монтируйте Docker socket, если глубоко не понимаете последствия и container не предназначен для управления Docker.
File ownership должен соответствовать runtime user. Переключение на non-root user без подготовки permissions может сломать startup приложения. Security и operability нужно проектировать вместе.
Scanning — не вся история
Vulnerability scanning находит известные проблемы в packages и libraries. Он не знает, открывает ли application admin endpoint, пишет ли tokens в logs или неправильно использует secrets.
Воспринимайте scan results как один input. Исправляйте critical и high issues, понимайте, находится ли vulnerable package в runtime path, и регулярно пересобирайте images из обновленных base images.
Security также зависит от process: кто может push images, кто approving base image updates и где хранятся secrets. Docker дает tools, но workflow решает, используются ли они хорошо.
Где применяются security controls
Docker security controls применяются на том Docker host, который запускает container. Non-root user, read-only filesystem, limited capabilities и mounted secrets влияют на container process на этом host. Они не защищают автоматически каждую другую машину, где лежит тот же source code.
Image scanning может выполняться локально, в CI или в registry. Самый сильный workflow сканирует images до deployment. Scanning только на ноутбуке разработчика полезен для обучения, но CI или registry scanning делает проверку частью team process.
Secrets также зависят от environment. Local development может использовать .env file с fake values. Production должен использовать platform secret mechanism, потому что real secrets не должны жить в image layers, Git history или случайных local files.
Команды: запустить и проверить
Выполняйте эти commands в terminal той машины, где установлен Docker. Для локального обучения это terminal на вашем ноутбуке. Для VPS сначала подключитесь к server по SSH, затем запускайте commands там. Не вставляйте commands вслепую: запустите одну command, посмотрите, что изменилось, затем переходите к следующей.
docker run --user 10001:10001 app:prod
docker history app:prod
docker scout cves app:prod
docker inspect app:prod
Таблица для ориентира
| Тема | Что означает | Практический вывод |
|---|---|---|
| Non-root user | Lower runtime privileges | Снижает ущерб после compromise |
| Scanner | Known vulnerability check | Находит CVE, не design flaws |
| Secret injection | Values supplied at runtime | Убирает secrets из image layers |
Правило снижения риска
Не спрашивайте, «безопасен» ли container вообще. Спросите, что он сможет сделать при compromise. Может ли он писать важные files? Работает ли от root? Содержит ли secrets? Есть ли в нем unnecessary tools?
Security улучшается, когда каждый ответ становится меньше: меньше packages, меньше privileges, меньше secrets в image и меньше exposed capabilities.
Контрольная точка
Продолжайте, когда можете объяснить, почему non-root users, vulnerability scanning и runtime secret injection решают разные части security problem.
Практика: security inspection
Проверьте image перед тем, как ему доверять. Посмотрите, от какого user работает process, содержит ли history подозрительные copied files и не слишком ли большой base image. Затем запустите vulnerability scan. Scan полезен, но это только один сигнал; он не скажет, хорошо ли спроектированы secrets handling или runtime privileges.
Короткий вывод
Главный ориентир security: уменьшайте поверхность атаки до запуска container. Меньше packages, меньше privileges, меньше secrets в image history и меньше открытых возможностей дают более понятную и управляемую runtime-среду.