Безопасный просмотр файлов Docker-образа

Изображение обложки: иконка контейнера и лупа

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

Создание контейнера без его запуска
Экспорт файловой системы контейнера
Использование “docker image save”
Просмотр слоёв через “docker image history”
Сторонние инструменты
Альтернативы и когда методы не работают
Пошаговый план и чек-листы
Заключение

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

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

быстро оценить пригодность образа для продакшена;
найти подозрительные entrypoint/CMD или скачивание данных в RUN-инструкциях;
обнаружить секреты, как ключи и токены, оставленные в слоях;
понять, какие пакеты и зависимости добавлены.

Стандартный путь — запустить контейнер и войти в него. Это просто, но опасно: запуск неизвестного образа может исполнить вредоносный код при старте.

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

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

Пример:

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

Этот контейнер можно запустить позднее командой docker start, если решите, что он безопасен. Создание контейнера само по себе безопасно: оно лишь регистрирует конфигурацию и слои, не выполняя ENTRYPOINT или CMD.

Важно: создание контейнера не извещает образ о запуске и не даёт исполняться скриптам образа. Тем не менее, следите за тем, чтобы локальное окружение (демон Docker) было обновлён и защищён.

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

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

docker export suspect-container > suspect-container.tar

Результат — tar‑архив в рабочем каталоге с полным содержимым образа. Откройте или распакуйте архив любым инструментом, чтобы просмотреть директории и файлы.

Если нужно получить список файлов прямо в терминале, используйте tar t:

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

tar t выдаст список файлов и папок; это удобно для быстрого поиска по имени и последующего целевого изучения.

Совет по безопасности: работайте с архивом в изолированной среде, например на хосте без доверительных данных. Архив может содержать секреты или скрипты — не выполняйте их.

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

Команда docker image save сохраняет сам образ в tar‑архив. В отличие от docker export, она фокусируется на объекте образа и сохраняет структуру слоёв и метаданные.

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

Внутри архива вы найдёте manifest.json, директории слоёв и tar‑файлы с содержимым каждого слоя. Это полезно для:

анализа, какие Dockerfile‑инструкции добавили файлы;
сравнения содержимого отдельных слоёв;
анализа истории сборки без создания контейнера.

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

Просмотр слоёв с помощью docker image history

Команда docker image history выводит список слоёв образа и команду, которая их создала.

docker image history suspect-image:latest

Вывод содержит колонку “CREATED BY” с инструкциями Dockerfile (RUN, COPY, ADD и т.д.). Она не показывает содержимое файловой системы, но помогает выявить подозрительные операции: скачивание бинарников, изменение переменных окружения, неожиданные ENTRYPOINT/CMD.

Скриншот вывода

Сканирование списка слоёв позволяет быстро найти очевидные проблемные места. Особое внимание уделяйте последним слоям: они чаще всего содержат финальную конфигурацию запуска (CMD/ENTRYPOINT) и последние изменения файлов.

Сторонние инструменты

Существуют open‑source и коммерческие инструменты для детального анализа образов. Они дают фильтры, визуализацию слоёв и списки установленных пакетов.

Anchore: команда anchore-cli image content my-image:latest выдаёт полный список файлов и метаданных после установки Anchore.
Dive: интерактивный инструмент для визуализации слоёв. Он показывает, какие файлы были добавлены или изменены в каждом слое.

Скриншот использования Dive для просмотра файловой системы Docker-образа

Другие инструменты могут индексировать пакеты (apt, rpm), зависимости языка (pip, npm, gem) и искать потенциальные секреты.

Сравнение подходов (краткая матрица)

docker create + docker export — безопасно, простая конечная файловая система, легко просматривать.
docker image save — сохраняет слои и метаданные, полезно для слоёвой диагностики.
docker image history — быстрая проверка действий сборки, не показывает файлы.
Anchor/Dive и другие — автоматизация, визуализация, фильтры; требуют установки.

Когда эти методы не работают или ограничены

Если образ зашифрован или использует нестандартные драйверы хранения, save/export могут давать неполные данные.
Сниффинг содержимого не обнаружит таймеры и действия, которые выполняются только во время рантайма (например, загрузка данных по сети в ENTRYPOINT). Для таких случаев нужен изолированный запуск в песочнице.
Автоматические сканеры часто пропускают новые, неизвестные вредоносные файлы. Ручной осмотр обязателен.

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

Песочница: запуск контейнера в полностью изолированной среде с отключённым сетевым доступом (network disabled) и ограничениями на ресурсы. Это уменьшит риск, но всё равно исполнит код.
Имейдж‑сканеры: Clair, Trivy, Anchore — ищут известные уязвимости и пакеты.
Статический анализ Dockerfile: если у вас есть Dockerfile, проверьте его вручную и выполните линтеры для Dockerfile.

Модель мышления при аудите образа (heuristic)

Посмотрите историю слоёв: ищите неожиданные RUN/COPY/ADD.
Сохраните образ или экспортируйте контейнер, чтобы получить файловую систему.
Просмотрите список файлов на предмет исполняемых файлов и скриптов в /usr/bin, /usr/local/bin, /etc/init.d.
Проверьте наличие секретов (ключи, certs, token) и конфигурационных файлов с паролями.
Используйте автоматические сканеры для ускорения анализа.
При сомнениях — запустите в песочнице с мониторингом сети.

Пошаговый SOP для быстрой проверки образа

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

docker create --name audit-ctn suspect-image:latest

Экспортируйте файловую систему:

docker export audit-ctn > audit-ctn.tar

Просмотрите содержимое архива (список файлов):

dar export audit-ctn | tar t | less

Поиск потенциальных секретов (пример с grep):

tar xf audit-ctn.tar -O | strings | egrep -i "password|secret|token|api_key" | head

Анализ слоёв (опционально):

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

Распакуйте и изучите manifest.json и слои.

Прокрутите docker image history для быстрого осмотра действий сборки:

docker image history suspect-image:latest

Запустите автоматический сканер (Trivy/Anchore/Clair):

trivy image suspect-image:latest

Если необходимо — запустите контейнер в песочнице с отключённым сетью и профилированием:

docker run --rm --network none --cpus 0.5 --memory 512m suspect-image:latest

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

Образ не содержит известных секретов в открытом виде.
ENTRYPOINT/CMD проверены и понятны.
Нет скачиваний исполняемых файлов в RUN, которые не проходят проверку целостности.
Все пакеты имеют допустимый уровень доверия или план обновления.

Ролевые чек-листы

DevOps:

Автоматизировать docker image save и сканирование в CI.
Хранить сигнатуры и версии образов.

Security Engineer:

Проверить слои с docker image history.
Запустить Trivy/Anchore и вручную проинспектировать подозрительные файлы.

QA / Developer:

Проверить, что необходимые зависимости объявлены явно в Dockerfile.
Убедиться, что разработчики не хранят секреты в образах.

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

Риск: Вредоносный ENTRYPOINT — Смягчение: Не запускать; экспорт и ручной осмотр.
Риск: Секреты в слоях — Смягчение: удаление секретов, перевыпуск секретов, запреты в CI.
Риск: Неизвестные бинарные файлы — Смягчение: блокировка запуска без анализа в песочнице.

Практические советы по усилению безопасности образов

Минимизируйте слои и используйте официальные базовые образы.
Не храните секреты в образах; используйте менеджеры секретов во время запуска.
Подписывайте образы (Docker Content Trust) и проверяйте подписи перед использованием.
Ограничьте привилегии контейнеров (не запускать с –privileged).

Пример диаграммы принятия решения (Mermaid)

flowchart TD
  A[Есть сомнения относительно образа?] -->|Да| B{Можно ли экспортировать?}
  B -->|Да| C[Создать контейнер и экспортировать tar]
  B -->|Нет| D[Запустить в песочнице с мониторингом]
  C --> E[Ручной и автоматический анализ]
  D --> E
  E --> F{Найдены подозрительные файлы?}
  F -->|Да| G[Отклонить/заменить образ]
  F -->|Нет| H[Допустить к тестированию]

Кейс: когда ручной экспорт спасает ситуацию (обобщённый пример)

Предположим, у вас есть образ из внешнего реестра. docker image history показывает RUN с командой, скачивающей бинарник с непроверенного URL. Вместо запуска вы создаёте контейнер и экспортируете tar. Внутри архива вы находите исполняемый файл в /usr/local/bin и скрипт, который при запуске поднимает обратную консоль. Это позволяет принять решение отклонить образ и сообщить разработчику.

Маленькая глоссарная подсказка (1‑строчная)

image — пакет файлов и метаданных, из которого создаются контейнеры.
container — запущенный (или созданный) экземпляр образа.
layer — отдельный слой файловой системы образа, созданный инструкцией Dockerfile.

Приёмочные тесты и контроль качества

Тест: при экспорте архива в нём присутствует /etc/passwd и другие базовые директории — проверка целостности.
Тест: поиск ключевых слов (password, secret) возвращает ожидаемую нулевую результативность для принятых образов.

Заключение

Docker‑образы по умолчанию непрозрачны. Реестры и Docker CLI не показывают список файлов напрямую. Экспорт образа в tar или сохранение образа позволяет изучать содержимое без запуска контейнера и риска исполнения вредоносного кода. Комбинируйте ручной осмотр, историю слоёв и автоматические сканеры. При сомнениях выполняйте анализ в изолированной песочнице и применяйте политики подписи и проверки образов.

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

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

Краткое резюме и рекомендации в одном месте: