Просмотр содержимого Docker-образа без запуска

Иллюстрация: проверка содержимого Docker-образа

Быстрые ссылки

Creating a Container Without Starting It
Exporting the Container’s Filesystem
Using “docker image save”
Listing Layers With “docker image history”
Third-Party Tools
Conclusion

Почему важно просматривать образ до запуска

Docker-образы упаковывают исполняемые файлы, библиотеки и конфигурации. На первый взгляд образ может выглядеть безобидно, но внутри могут находиться нежелательные или вредоносные файлы, бэкдоры, секреты или конфигурации, нарушающие политики безопасности. Запуск контейнера из неподтверждённого образа может привести к выполнению неизвестного ENTRYPOINT/CMD, скачиванию данных из интернета или изменению хоста при неправильных правах.

Ключевая идея: получить максимально точную картину файловой системы образа, не исполняя его. Ниже перечислены методы, эвристики и практические чеклисты для этого.

Important: создание контейнера командой docker create не запускает его и не выполняет ENTRYPOINT/CMD. Экспорт и анализ файловой системы безопаснее запуска контейнера, но всегда соблюдайте аккуратность при извлечении бинарников и скриптов — не запускайте их вне контролируемой среды.

Создание контейнера без запуска

Команда docker create создаёт контейнер сверху указанного образа, но не запускает его. Это полезно, когда нужно получить ссылку на контейнер и затем экспортировать его файловую систему или пробросить тома для анализа.

Пример:

docker create --name suspect-container suspect-image:latest

Этот контейнер останется остановленным. Вы можете создавать множество таких контейнеров для последовательного анализа разных образов.

Краткие замечания:

docker create не выполняет ENTRYPOINT/CMD и не запускает процессы внутри контейнера.
Контейнер хранит метаданные (настройки, переменные окружения, монтирования), которые можно увидеть через docker inspect.
Если цель — только получить итоговую файловую систему, docker create + docker export даёт именно её.

Экспорт файловой системы контейнера

После создания остановленного контейнера используйте docker export, чтобы получить «плоский» tar с итоговой файловой системой контейнера.

docker export suspect-container > suspect-container.tar

Этот tar содержит конечный набор файлов и директорий, которые будут присутствовать в работающем контейнере. Файлы можно просмотреть локально, распаковать или анализировать в командной строке.

Примеры полезных команд для анализа без распаковки в рабочую директорию:

docker export suspect-container | tar t > suspect-container-files.txt

docker export suspect-container | tar tvf - | less

Полезно обратить внимание на:

Наличие бинарников в /usr/bin, /usr/local/bin, /sbin
Сценарии в /entrypoint.sh или любых файлов вида *.sh
Наличие ключей/конфиденциальных файлов в /root или /home
Скрипты автозапуска, cron и systemd unit-файлы (если они присутствуют)

Использование docker image save

Команда docker image save сохраняет сам образ в tar-архив, включая метаданные слоёв и manifest.json.

docker image save suspect-image:latest > suspect-image.tar

Чем отличается docker save от docker export:

docker save сохраняет слои, manifest и config; полезно для анализа истории сборки и для передачи образа в офлайн-репозиторий.
docker export извлекает итоговую файловую систему контейнера в «плоском» виде, без слоёв и метаданных, что удобно для обзора конечного содержимого.

Если вам важно выяснить, какие изменения были внесены на каждом слое (например, какие пакеты установлены на конкретном шаге), используйте docker save + распаковку директорий со слоями и анализ manifest.json.

Просмотр истории слоёв через docker image history

docker image history suspect-image:latest

Эта команда показывает список слоёв и Dockerfile-инструкции, которые их создали (колонка CREATED BY). Она не даёт прямого списка файлов, но позволяет быстро обнаружить подозрительные шаги:

Скачивание исполняемых файлов через curl/wget
Запуск инсталляторов, скриптов или сборщиков с непроверенных источников
Добавление неявных переменных окружения
Неожиданный ENTRYPOINT или CMD

Вывод команды docker image history, показывающий слои образа

Важно: docker image history отражает метаданные сборки, но может быть неполной при использовании squash или когда образ строился без сохранения промежуточных слоёв.

Дополнительные команды Docker для контекста

Просмотр метаданных образа:

docker image inspect suspect-image:latest

inspect выводит JSON с конфигурацией образа: Entrypoint, Cmd, Env, Labels, User и т. п. Это первое место, куда стоит заглянуть.

Просмотр контейнера перед экспортом:

docker inspect suspect-container

Это раскрывает, какие настройки контейнера будут применены при запуске.

Сторонние инструменты для детального анализа

Есть несколько полезных открытых инструментов:

Anchore: имеет подсистему для перечисления содержимого образа. Пример команды (после установки Anchore):

anchore-cli image content my-image:latest

Dive: интерактивный инструмент для визуализации слоёв и изменений в файловой системе. Очень полезен для поиска избыточных файлов и понимания, где добавлен тот или иной файл.

Просмотр файловой системы Docker-образа в Dive, интерфейс визуального анализа слоев

Skopeo и umoci: инструменты для копирования и распаковки OCI/Docker образов без необходимости Docker Daemon. Полезны в изолированных средах.
Trivy, Clair и другие сканеры уязвимостей: анализируют пакеты и уязвимости, но не всегда обнаруживают кастомные бэкдоры или секреты, спрятанные в нестандартных местах.

Когда эти методы могут не сработать

Образ использует зашифрованные или сжатые данные, расшифровка которых требует секретов, известных только в runtime.
В образе есть стеганографически спрятанные данные или зашифрованные исполняемые файлы, которые сложно обнаружить автоматическими средствами.
Авторы образа намеренно пытаются запутать историю слоёв (например, объединяют команды и используют многоступенчатую сборку), чтобы скрыть промежуточные шаги.

В таких случаях необходимо более глубокое поведенческое тестирование в изолированной среде (sandbox/VM) и ручной аудит бинарников.

Эвристики и модель мышления при анализе образа

Модель «слой как дифф»: думайте о каждом слое как о патче к файловой системе. Итоговая FS — это наложение патчей.
Правила риска:
- Внимание к RUN с curl/wget|sh или загрузке бинарей из внешних источников.
- Проверяйте ENTRYPOINT/CMD на вызов удалённых скриптов.
- Ищите неожиданно большие слои — они часто содержат деб-пакеты, зависимости или скомпилированные бинарники.
Проверяйте пользовательские права: образы, работающие от root, более рискованы по умолчанию.

Мини-методология для ручного аудита образа

Клонируйте образ локально: docker pull
Посмотрите метаданные: docker image inspect
Просмотрите историю слоёв: docker image history
Создайте контейнер без запуска: docker create
Экспортируйте файловую систему: docker export | tar t
Просмотрите файлы и скрипты, ищите подозрительные бинарники и ключи
Используйте Dive/Anchore/Trivy для автоматизированного анализа
Задокументируйте находки и примите решение: разрешить, запретить, потребовать ремедиации

Роль‑ориентированные чеклисты

Developer:

Проверить Dockerfile и слои на ненужные зависимости
Минимизировать размер образа
Запускать контейнер локально в sandbox для функционального теста

Security Engineer:

Проверить ENTRYPOINT/CMD и переменные окружения
Просканировать образ на уязвимости
Обратить внимание на добавленные ключи и креды

Operations:

Убедиться, что образ подписан/прошёл CI-пайплайн
Проверить совместимость версий утилит/библиотек
План отката при проблемах

Критерии приёмки

Нет неизвестных внешних загрузок в Dockerfile-инструкциях
Нету открытых секретов в /root, /etc или переменных окружения
Образ запускается от непривилегированного пользователя либо докуменирован риск
Уязвимости закрыты или задокументированы и приняты

Матрица рисков и смягчения

Высокий риск: образ содержит незнакомые исполняемые файлы или инструкции загрузки из непроверенных URL. Смягчение: отказ от образа, аудит автором, запуск в полностью изолированной VM.
Средний риск: образ содержит большие наборы библиотек и пакетов. Смягчение: пересобрать образ с минимальными зависимостями.
Низкий риск: образ прост, все команды понятны, использует проверенные базовые образы.

Плейбук для безопасного аудита образа

Pull образ и продублировать его под контролируемым тегом.
docker image inspect для базовой информации.
docker image history для поиска подозрительных шагов.
docker create и docker export в tar для анализа файлов.
Пробежаться по списку файлов, искать ключи и бинарники.
Прогнать образ через Trivy/Anchore/Dive.
Собрать отчёт и принять решение.

Безопасное усиление при запуске образа в продакшн

Запуск в least-privilege режиме: user != root
Ограничение привилегий контейнера: –cap-drop all с выборочным добавлением нужных CAPs
Ограничение доступа к хосту: отсутствие монтирования /, /etc, /var/run/docker.sock при возможности
Использование seccomp, AppArmor/SELinux и cgroup‑лимитов
Подпись образов и проверка подписи перед деплоем

Приватность и соответствие требованиям

При анализе образа обратите внимание, не включены ли в него персональные данные или конфиденциальная информация (логины, API-ключи, сертификаты). Если такие данные найдены, необходимо:

Сообщить владельцу образа и инициировать инцидентный процесс
Оценить, была ли информация опубликована в реестрe
При необходимости уведомить заинтересованные стороны и принять меры удаления

Альтернативные подходы

Анализ в офлайн-лаборатории: распаковать образ в изолированном VM и провести динамический анализ
Использование подхода multi-stage build для уменьшения финального образа и исключения лишних инструментов
Политика доверенных базовых образов и автоматическая проверка в CI

Тестовые случаи и критерии приёмки для автоматизации

Пайплайн должен блокировать образ, если найдены секреты в файловой системе.
Пайплайн должен уведомлять при обнаружении скачивания бинарей из внешних URL.
Пайплайн должен подтверждать, что ENTRYPOINT/CMD соответствует ожидаемому поведению.

Заключение

Docker-образы по умолчанию не показывают своё содержимое при загрузке из реестра. Комбинация docker create + docker export и docker image save позволяет изучить конечную файловую систему и метаданные, не запуская образ. Для всестороннего анализа используйте и метаданные (docker inspect, history), и статический просмотр содержимого слоёв, и сторонние инструменты для автоматической проверки. В высокорисковых средах комбинируйте ручную проверку с автоматическими сканерами и применяйте жёсткие правила запуска контейнеров.

Краткий план действий:

Посмотреть метаданные: docker image inspect
Просмотреть историю: docker image history
Создать контейнер: docker create
Экспортировать FS: docker export
Просмотреть и отфильтровать файлы
Прогнать автоматические сканеры и принять решение

Внимание: автоматические сканеры ускоряют обнаружение известных проблем, но не заменяют ручной аудит при подозрениях на целенаправленную вредоносную активность.