Есть ли способ объединить образы Docker в 1 контейнер?

У меня сейчас есть несколько файлов Docker.

Один предназначен для Cassandra 3.5, и это FROM cassandra: 3.5

У меня также есть Dockerfile для Kafka, но он немного сложнее. Это ОТ java: openjdk-8-fre , и он запускает длинную команду для установки Kafka и Zookeeper.

Наконец, у меня есть приложение, написанное на Scala, которое использует SBT.

Для этого Dockerfile это FROM broadinstitute/scala-baseimage , который дает мне Java 8, Scala 2.11.7 и STB 0.13.9, которые являются что мне нужно.

Возможно, я не понимаю, как работает Docker, но моя программа Scala имеет Cassandra и Kafka в качестве зависимостей, и для целей разработки я хочу, чтобы другие могли просто клонировать мое репо с помощью Dockerfile , а затем иметь возможность построить его с помощью Cassandra, Kafka, Scala, Java и SBT, так что они могут просто скомпилировать исходный код. Хотя у меня с этим много проблем.

Как мне объединить эти файлы Docker? Как мне просто создать среду с запеченными в ней вещами?


Вы можете сделать это с помощью функции многоступенчатой ​​сборки , представленной в Docker 1.17

Взгляните на это:

  ОТ golang: 1.7.3WORKDIR/go/src/github.com/alexellis/href-counter/ RUN go get -d -v golang.org/x/net/html COPY app.go .RUN CGO_ENABLED = 0 GOOS = linux go build -a -installsuffix cgo -o app .FROM alpine: последняя версия RUN apk --no-cache  добавить CA-сертификатыWORKDIR/root/COPY --from = 0/go/src/github.com/alexellis/href-counter/app .CMD ["./app"]  

Затем создайте образ как обычно:

  docker build -t alexellis2/href-counter: latest  

From: https://docs.docker.com/develop/develop-images/multistage-build/

Конечным результатом является тот же крошечный рабочий образ, что и раньше, со значительным уменьшением сложности. Вам не нужно создавать какие-либо промежуточные изображения, и вам вообще не нужно извлекать какие-либо артефакты в локальную систему.

Как это работает? Вторая инструкция FROM запускает новый этап сборки с образом alpine: latest в качестве основы. Строка COPY —from = 0 копирует только построенный артефакт из предыдущего этапа в этот новый этап. Go SDK и любые промежуточные артефакты остаются позади и не сохраняются в конечном изображении.


Вы не можете комбинировать файлы докеров, так как могут возникнуть конфликты. Что вы хотите сделать, так это создать новый файл докеров или создать собственный образ.

TL; DR; Если ваш текущий контейнер разработки содержит все необходимые инструменты и работает, то сохраните его как образ а затем в репо и создать файл докеров для извлечения из этого образа из этого репо.

Подробности: создание собственного образа намного проще, чем создание файла докеров с использованием общедоступного образа, поскольку вы можете хранить любые хаки и моды в образ. Для этого запустите пустой контейнер с базовым образом Linux (или broadinstitute/scala-baseimage), установите все необходимые инструменты и настройте их, пока все не будет работать правильно, а затем сохраните его (контейнер) как образ. Создайте новый контейнер из этого образа и проверьте, можете ли вы построить свой код поверх него с помощью docker-compose (или как вы хотите это сделать/построить). Если это работает, значит у вас есть рабочий базовый образ, который вы можете загрузить в репо, чтобы другие могли его вытащить.

Чтобы создать файл докеров с общедоступным образом, вам нужно будет разместить все хаки, моды и настройки в самом dockerfile. То есть вам нужно будет поместить каждую используемую вами командную строку в текстовый файл и сократить количество хаков, модов и настроек до командных строк. В конце ваш файл dockerfile создаст образ автоматически, и вам не нужно хранить этот образ в репо, и все, что вам нужно сделать, это предоставить другим dockerfile, и они могут развернуть образ в своем собственном докере.

Обратите внимание, что если у вас есть рабочий файл докеров, вы можете легко настроить его, поскольку он будет создавать новый образ каждый раз, когда вы используете файл докеров. С настраиваемым образом вы можете столкнуться с проблемами, когда вам потребуется перестроить образ из-за конфликтов. Например, все ваши инструменты работают с openjdk, пока вы не установите тот, который не работает. Исправление может включать удаление openjdk и использование oracle one, но вся конфигурация, которую вы сделали для всех установленных вами инструментов, сломалась.

1


Следующий ответ относится к docker 1.7 и выше:

Я бы предпочел использовать - from = NAME и from image as NAME Почему? Вы можете использовать - from = 0 и выше, но это может стать немного сложно, когда у вас много этапы docker в dockerfile.

пример примера:

  FROM golang: 1.7.3 как backendWORKDIR/backendRUN go get -d -v golang.org /x/net/html COPY app.go .RUN # установить кое-что, скомпилировать ресурсы .... FROM golang: 1.7.3 as assetsWORKDIR/assetsRUN ./getassets.shFROM nodejs: latest as frontend RUN npm installWORKDIR/assetsCOPY -  from = assets/asets .CMD ["./app"] FROM alpine: последний как объединенные активыWORKDIR/root/COPY --from = merge ./COPY --from = backend  ./backend .CMD ["./app"]  

Примечание. Правильное управление файлом докера поможет создать образ докера быстрее. Внутренний докер использует кеширование уровня докера, чтобы помочь в этом процессе, на случай, если изображение придется перестраивать.


Да, вы может свернуть большое количество программного обеспечения в один образ Docker (GitLab делает это с одним образом, который включает Postgres и все остальное), но в целом Генри прав — это не типичный способ использования Docker.

Как вы говорите, Cassandra и Kafka являются зависимостями для вашего приложения Scala, они не являются частью приложения, поэтому не все они входят в тот же образ.

Необходимость координировать множество контейнеров с помощью Docker Compose добавляет дополнительный уровень администрирования, но дает гораздо большую гибкость:

  • ваши контейнеры могут иметь разные продолжительность жизни, поэтому, когда у вас есть новая версия вашего приложения для развертывания, вам нужно только запустить новый контейнер приложения, вы можете оставить все зависимости запущенными;
  • вы можете использовать тот же образ приложения в любом среды, используя разные конфигурации для ваших зависимостей — например, в dev вы можете запустить базовый контейнер Kafka, а в prod он будет кластеризован на многих узлах, ваш контейнер приложения такой же;
  • ваши зависимости могут использоваться и другими приложениями, поэтому несколько потребителей могут запускать в разных контейнерах, и все они работают с одними и теми же контейнерами Kafka и Cassandra;
  • плюс уже упомянутая масштабируемость, ведение журнала и т. д.

Вы не можете объединить образы докеров в 1 контейнер. См. Подробное обсуждение проблемы Moby, Как объединить несколько образов в один с помощью Dockerfile.

В вашем случае лучше не включать все образы Cassandra и Kafka. Приложению потребуются только драйвер Cassandra Scala и драйвер Kafka Scala. Контейнер должен включать только драйверы.


Docker не работает объединяет образы, но ничто не мешает вам объединить файлы докеров, если они есть, и превратить их в толстый образ, который вам нужно будет создать. Однако есть моменты, когда это имеет смысл, поскольку для запуска нескольких процессов в контейнере большинство догм Docker будет указывать на это как на менее желательное, особенно с микросервисной архитектурой (однако правила должны быть нарушены, верно?)


Мне нужны образы docker: latest и python: latest для Gitlab CI. Вот что я придумал:

  ОТ ubuntu: latestRUN apt updateRUN apt install -y sudoRUN sudo apt install -y docker. ioRUN sudo apt install -y python3-pipRUN sudo apt install -y python3RUN docker --versionRUN pip3 --versionRUN python3 --version  

После того, как я собрал и отправил его на свой Репозиторий Docker Hub:

  docker build -t docker-hub-repo/image-name: latest path/to/Dockerfiledocker push docker-hub-repo/image-name: latest   

Не забудьте войти в докер перед нажатием

Надеюсь, это поможет

0



Terrier: инструмент с открытым исходным кодом для идентификации и анализа компонентов контейнера и изображения

Слушайте эту статью

В рамках нашего выступления в Blackhat Europe «Обратный инжиниринг и использование сборок в облаке» мы публично выпустили новый инструмент под названием Terrier.

В этом сообщении блога я покажу вам, как Terrier может помочь вам идентифицировать и проверять контейнер. и компоненты изображений для самых разных сценариев использования, будь то с точки зрения цепочки поставок или криминалистической экспертизы. Terrier можно найти на Github https://github.com/heroku/terrier.

Контейнеры и изображения

В этом сообщении в блоге я не собираюсь идти слишком много деталей о контейнерах и изображениях (вы можете узнать больше здесь), однако важно выделить несколько характеристик контейнеров и изображений, которые делают их интересными с точки зрения терьера. Контейнеры запускаются из изображений, и в настоящее время Open Containers Initiative (OCI) является самым популярным форматом для изображений. В оставшейся части этого сообщения в блоге изображения OCI называются изображениями.

По сути, изображения представляют собой tar-архивы, содержащие несколько tar-архивов и метаинформацию, представляющую «слои» изображения. Формат изображений OCI упрощает работу с изображениями, что делает анализ относительно простым. Если бы у вас был доступ только к терминалу и команде tar, вы могли бы в значительной степени получить то, что вам нужно, из tar-архива изображения.

Когда изображения используются во время выполнения для контейнера, их содержимое становится содержимое запущенного контейнера и слои по существу извлекаются в место на хосте среды выполнения контейнера. Хост среды выполнения контейнера — это хост, на котором работают и обслуживаются контейнеры. Обычно это расположение /var/lib/docker/overlay2//. Это место содержит несколько интересных папок, в частности «объединенную» папку. «Объединенная» папка содержит содержимое изображения и все изменения, которые произошли в контейнере с момента его создания. Например, если изображение содержит такое местоположение, как /usr/chris/stuff , и после создания контейнера из этого изображения я создал файл с именем helloworld.txt в расположении /usr/chris/stuff . Это приведет к следующему допустимому пути на хосте среды выполнения контейнера /var/lib/docker/overlay2//merged/usr/chris/stuff/helloworld.txt .

Что делает терьер?

Теперь, когда у нас есть краткое представление об изображениях и контейнерах, мы можем посмотреть, что делает терьер. Часто бывает так, что вам нужно определить, содержит ли изображение или контейнер определенный файл. Это требование может быть связано с необходимостью проведения судебно-медицинской экспертизы или для выявления и предотвращения определенного вектора атаки в цепочке поставок. Независимо от требований, полезно иметь возможность определять наличие определенного файла в изображении или контейнере.

Идентификация файлов в изображениях OCI

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

  1. Образ OCI, то есть архив TAR
  2. Хэш SHA256 определенного файла/файлов

Первого пункта можно легко достичь с помощью Docker, используя следующую команду:

  $ docker save imageid -o myImage.tar   

В приведенной выше команде используется идентификатор образа Docker, который можно получить с помощью следующей команды:

  $ docker images  

После того, как ваше изображение экспортировано как tar-архив, вам нужно будет установить хэш SHA256 для конкретного файла, который вы хотите идентифицировать в образе. Есть несколько способов добиться этого, но в этом примере мы собираемся использовать хэш двоичного кода Golang go1.13.4 linux/amd64 , что можно сделать с помощью следующей команды на хосте Linux:

  $ cat/usr/local/go/bin/go |  sha256sum  

Приведенная выше команда должна привести к следующему хешу SHA256: 82bce4b98d7aaeb4f841a36f7141d540bb049f89219f9e377245a91dd3ff92dd

Теперь у нас есть , мы можем использовать этот хэш, чтобы определить, находится ли двоичный файл Golang в изображении myImage.tar . Для этого нам нужно заполнить файл конфигурации для Terrier. Terrier использует файлы конфигурации YAML, а ниже находится наш файл конфигурации, который мы сохраняем как cfg.yml :

  mode: imageimage: myImage.  tarhashes: - hash: '82bce4b98d7aaeb4f841a36f7141d540bb049f89219f9e377245a91dd3ff92dd'  

В конфигурационном файле выше есть несколько записей, которые позволяют нам указать режим , в котором будет работать терьер. в этом случае мы работаем с файлом изображения (tar-архивом), поэтому используется режим image . Файл изображения, с которым мы работаем, — это myImage.tar , а хэш, который мы хотим идентифицировать, находится в списке hashes .

Теперь мы готовы запустить Terrier, и это можно сделать с помощью следующей команды:

  $ ./terrier  

Результат выполнения приведенной выше команды должен быть примерно таким:

  $ ./terrier [+] Загрузка конфигурации: cfg.yml [+] Анализ изображения [+] Источник изображения Docker  : myImage. деготь [*] Проверка уровня: 34a9e0f17132202a82565578a3c2dae1486bb198cde76928c8c2c5c461e11ccf [*] Проверка уровня: 6539a80dd09da08132a525494ff97e92f4148d413e7c48b3583883fda8a40560 [*] Проверка уровня: 6d2d61c78a65b6e6c82b751a38727da355d59194167b28b3f8def198cd116759 Найдено файл '6d2d61c78a65b6e6c82b751a38727da355d59194167b28b3f8def198cd116759/USR/местные/Go/bin/идти' с хэш [!]: 82bce4b98d7aaeb4f841a36f7141d540bb049f89219f9e377245a91dd3ff92dd [*] Проверка уровня:  a6e646c34d2d2c2f4ab7db95e4c9f128721f63c905f107887839d3256f1288e1 [*] Проверка уровня: aefc8f0c87a14230e30e510915cbbe13ebcabd611e68db02b050b6ceccf9c545 [*] Проверка уровня: d4468fff8d0f28d87d48f51fc0a6afd4b38946bbbe91480919ebfdd55e43ce8c [*] Проверка уровня: dbf9da5e4e5e1ecf9c71452f6b67b2b0225cec310a20891cc5dedbfd4ead667c код> 

Мы определили файл /USR/местные/ go/bin/go , расположенный на уровне 6d2d61c78a65b6e6c82b751a38727da355d59194167b28b3f8def198cd116759 , который имеет тот же хэш SHA256, что и мы предоставили. Теперь у нас есть подтверждение того, что изображение «myImage.tar» содержит файл с предоставленным нами хешем SHA256.

Этот пример можно расширить, и вы можете указать Terrier на поиск нескольких хешей. В этом случае мы будем искать вредоносный файл. Недавно была обнаружена вредоносная библиотека Python, получившая название «Jeilyfish». Terrier можно использовать для проверки наличия этого вредоносного пакета в вашем Docker-образе. Для этого мы можем определить SHA256 одного из вредоносных файлов Python, содержащих бэкдор:

  $ cat jeIlyfish-0.7.1/jeIlyfish/_jellyfish.py |  sha256sumcf734865dd344cd9b0b349cdcecd83f79a751150b5fd4926f976adddb93d902c  

Затем мы обновляем конфигурацию нашего терьера, добавляя хеш-код, вычисленный выше.

  - image.image.  hash: '82bce4b98d7aaeb4f841a36f7141d540bb049f89219f9e377245a91dd3ff92dd' - hash: 'cf734865dd344cd9b0b349cdcecd83f79a751150b5fdc49b976>  p> /terrier [+] Конфигурация загрузки: cfg.yml [+] Анализ изображения [+] Источник изображения Docker: myImage. деготь [*] Проверка уровня: 34a9e0f17132202a82565578a3c2dae1486bb198cde76928c8c2c5c461e11ccf [*] Проверка уровня: 6539a80dd09da08132a525494ff97e92f4148d413e7c48b3583883fda8a40560 [*] Проверка уровня: 6d2d61c78a65b6e6c82b751a38727da355d59194167b28b3f8def198cd116759 Найдено файл '6d2d61c78a65b6e6c82b751a38727da355d59194167b28b3f8def198cd116759/USR/местные/Go/bin/идти' с хэш [!]: 82bce4b98d7aaeb4f841a36f7141d540bb049f89219f9e377245a91dd3ff92dd [*] Проверка уровня:  a6e646c34d2d2c2f4ab7db95e4c9f128721f63c905f107887839d3256f1288e1 [*] Проверка уровня: aefc8f0c87a14230e30e510915cbbe13ebcabd611e68db02b050b6ceccf9c545 [*] Проверка уровня: d4468fff8d0f28d87d48f51fc0a6afd4b38946bbbe91480919ebfdd55e43ce8c [*] Проверка уровня: dbf9da5e4e5e1ecf9c71452f6b67b2b0225cec310a20891cc5dedbfd4ead667c код> 

Приведенные выше результаты показывают, что наше изображение не содержит вредоносный пакет Python.

Нет ограничений на количество хэшей, которые вы можете искать, однако следует отметить, что Terrier perfo rms все свои действия в памяти по соображениям производительности, поэтому вы можете достичь определенных ограничений, если у вас недостаточно доступной памяти.

Идентификация и проверка определенных файлов в изображениях OCI

Terrier также можно использовать, чтобы определить, содержит ли конкретное изображение определенный файл в определенном месте . Это может быть полезно, чтобы убедиться, что изображение использует определенный компонент, то есть двоичный, общий объект или зависимость. Это также можно рассматривать как «закрепление» компонентов, если вы убедитесь, что изображения используют определенные компоненты, то есть определенную версию cURL.

Для этого вам потребуется следующее:

  1. Образ OCI, т.е. архив TAR
  2. Хэш SHA256 определенного файла/файлов
  3. Путь и имя конкретный файл/ы

Первой точки можно легко достичь с помощью Docker, используя следующую команду:

  $ docker save imageid  -o myImage.tar  

В приведенной выше команде используется идентификатор образа Docker, который можно получить с помощью следующей команды:

  $  docker images  

После того, как вы экспортировали образ как tar-архив, вам нужно будет определить путь к файлу, который вы хотите идентифицировать и проверить в образе. Например, если мы хотим убедиться, что в наших изображениях используется определенная версия cURL, мы можем запустить следующие команды в контейнере или в другой среде, которая напоминает изображение.

  $ which curl/usr/bin/curl  

Теперь у нас есть путь к cURL и теперь мы можем сгенерировать SHA256 этого экземпляра cURL, потому что в этом случае мы доверяйте этому экземпляру cURL. Мы могли бы определить хэш другими способами, например, многие двоичные файлы выпускаются с соответствующим хешем от разработчика, который можно получить на веб-сайте разработчика..

  $ cat/usr/bin/curl |  sha256sum 9a43cb726fef31f272333b236ff1fde4beab363af54d0bc99c304450065d9c96  

Теперь мы можем заполнить наш файл конфигурации для Terrier:

  modeImage.tarfiles: my  : - name: '/usr/bin/curl' хеши: - hash: '9a43cb726fef31f272333b236ff1fde4beab363af54d0bc99c304450065d9c96'  

Мы сохранили вышеуказанную конфигурацию как

/code> и когда мы запустим Terrier с этой конфигурацией, мы получим следующий результат:

  $ ./terrier[+] Загрузка конфигурации: cfg.yml [+] Анализ изображения  [+] Докер изображение Источник: myImage.tar [*] Проверка уровня: 34a9e0f17132202a82565578a3c2dae1486bb198cde76928c8c2c5c461e11ccf [*] Проверка уровня: 34a9e0f17132202a82565578a3c2dae1486bb198cde76928c8c2c5c461e11ccf [*] Проверка уровня: 6539a80dd09da08132a525494ff97e92f4148d413e7c48b3583883fda8a40560 [*] Проверка уровня: 6539a80dd09da08132a525494ff97e92f4148d413e7c48b3583883fda8a40560 [*] Проверка уровня: 6d2d61c78a65b6e6c82b751a38727da355d59194167b28b3f8def19  8cd116759 [*] Проверка слой: 6d2d61c78a65b6e6c82b751a38727da355d59194167b28b3f8def198cd116759 [*] Проверка слой: a6e646c34d2d2c2f4ab7db95e4c9f128721f63c905f107887839d3256f1288e1 [*] Проверка слой: a6e646c34d2d2c2f4ab7db95e4c9f128721f63c905f107887839d3256f1288e1 [*] Проверка слой: aefc8f0c87a14230e30e510915cbbe13ebcabd611e68db02b050b6ceccf9c545 [*] Проверка слой: aefc8f0c87a14230e30e510915cbbe13ebcabd611e68db02b050b6ceccf9c545 [*] Проверка слой: d4468fff8d0f28d87d48f51fc0a6afd4b38946bbbe91480919ebfdd55e43ce8c [*] Проверка слой: d4468fff8d0f28d87d48f51fc0a6afd4b38946bbbe91480919ebfdd55e43ce8c  [*] Проверка уровня: dbf9da5e4e5e1ecf9c71452f6b67b2b0225cec310a20891cc5dedbfd4ead667c [*] Проверка уровня: dbf9da5e4e5e1ecf9c71452f6b67b2b0225cec310a20891cc5dedbfd4ead667c были идентифицированы все компоненты [!]: (1/1) Все компоненты были идентифицированы и проверены [!]: (1/1) $ эхо $ 0 код  > 

Приведенные выше выходные данные показывают, что файл /usr/bin/curl был успешно идентифицирован Это означает, что изображение содержит файл в расположении /usr/bin/curl и что SHA256 этого файла соответствует хешу, который мы предоставили в конфигурации. Terrier также использует коды возврата, и если мы проанализируем код возврата из выходных данных выше, мы увидим, что значение равно 0 , что указывает на успех. Если Terrier не может идентифицировать или проверить все предоставленные файлы, возвращается код возврата 1 , который указывает на сбой. Настройка кодов возврата особенно полезна в средах тестирования или средах CI/CD.

Мы также можем запустить Terrier с включенным подробным режимом, чтобы получить дополнительную информацию:

  $ ./terrier [+] Загрузка конфигурации: cfg.yml [+] Анализ изображения [+] Источник изображения Docker: myImage. деготь [*] Проверка уровня: 34a9e0f17132202a82565578a3c2dae1486bb198cde76928c8c2c5c461e11ccf [*] Проверка уровня: 6539a80dd09da08132a525494ff97e92f4148d413e7c48b3583883fda8a40560 Выявленные экземпляр '/USR/BIN/локон' в [!] [!] 6539a80dd09da08132a525494ff97e92f4148d413e7c48b3583883fda8a40560/USR/BIN/завитка Проверенный соответствия экземпляра «/USR/бен /завиток»по адресу: 6539a80dd09da08132a525494ff97e92f4148d413e7c48b3583883fda8a40560/USR/бен/завитка с хэш: 9a43cb726fef31f272333b236ff1fde4beab363af54d0bc99c304450065d9c96 [*] Проверка слоя: 6d2d61c78a65b6e6c82b751a38727da355d59194167b28b3f8def198cd116759 [*] Проверка слоя: a6e646c34d2d2c2f4ab7db95e4c9f128721f63c905f107887839d3256f1288e1 [*] Проверка слоя: aefc8f0c87a14230e30e510915cbbe13ebcabd611e68db02b050b6ceccf9c545 [*] Проверка слоя: d4468fff8d0f28d87d48f51fc0a6afd4b38946bbbe91480919ebfdd55e43ce8c [*] Проверка слоя:  dbf9da5e4e5e1ecf9c71452f6b67b2b0225cec310a20891cc5dedbfd4ead667c [!] Все компоненты были идентифицированы: (1/1) [!] Все компоненты мы  повторно идентифицированы и проверены: (1/1)  

Приведенные выше выходные данные предоставляют некоторую более подробную информацию, например, на каком слое были расположены файлы cURL. Если вам нужна дополнительная информация, вы можете включить опцию veryveryverbose в файле конфигурации, но будьте осторожны, это много вывода, и grep будет вашим другом.

Нет ограничений на количество хэшей, которые вы можете указать для файла. Это может быть полезно, когда вы хотите разрешить более одной версии определенного файла, то есть несколько версий cURL. Пример конфигурации нескольких хешей для файла может выглядеть так:

  mode: imageimage: myImage.tarfiles: - name: '/usr/bin/curl' hashes: - hash  : '9a43cb726fef31f272333b236ff1fde4beab363af54d0bc99c304450065d9c96' - хэш: 'aefc8f0c87a14230e30e510915cbbe13ebcabd611e68db02b050b6ceccf9c545' - хэш: '6d2d61c78a65b6e6c82b751a38727da355d59194167b28b3f8def198cd116759' - хэш: 'd4468fff8d0f28d87d48f51fc0a6afd4b38946bbbe91480919ebfdd55e43ce8c' код> 

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

Репозиторий Terrier на Github также содержит полезный скрипт под названием convertSHA.sh , который может использоваться для преобразования списка хэшей SHA256 и имен файлов в файл конфигурации Terrier. Это полезно при преобразовании вывода других инструментов в формат, удобный для терьеров. Например, мы могли бы иметь следующее содержимое файла:

8946690bfe12308e253054ea658b1552c02b67445763439d1165c512c4bc240d ./bin/uname6de8254cfd49543097ae946c303602ffd5899b2c88ec27cfcd86d786f95a1e92 ./bin/gzexe74ff9700d623415bc866c013a1d8e898c2096ec4750adcb7cd0c853b4ce11c04 ./bin/wdctl61c779de6f1b9220cdedd7dfee1fa4fb44a4777fff7bd48d12c21efb87009877 ./bin/dmesg7bdde142dc5cb004ab82f55adba0c56fc78430a6f6b23afd33be491d4c7c238b./Бен/which3ed46bd8b4d137cad2830974a78df8d6b1d28de491d7a23d305ad58742a07120 ./bin/mknode8ca998df296413624b2bcf92a31ee3b9852f7590f759cc4a8814d3e9046f1eb ./bin/mva91d40b349e2bccd3c5fe79664e70649ef0354b9f8bd4658f8c164f194b53d0f ./bin/chown091abe52520c96a75cf7d4ff38796fc878cd62c3a75a3fd8161aa3df1e26bebd ./bin/uncompressc5ebd611260a9057144fd1d7de48dbefc14e16240895cb896034ae05a94b5750 ./bin/echod4ba9ffb5f396a2584fec1ca878930b677196be21aee16ee6093eb9f0a93bf8f ./bin/df5fb515ff832650b2a25aeb9c21f881ca2fa486900e736dfa727a5442a6de83e5 ./bin/tar6936c9aa8e17781410f286bb1cbc35b5548ea4e7604c1379dc8e159d91a0193d ./bin/zforce8d641329ea7f93b1caf031b70e2a0a3288c49a55c18d8ba86cc534eaa166ec2e ./bin/gzip0c1a1f53763ab668fb085327cdd298b4a0c1bf2f0b51b912aa7bc15392cd09e7. /бен/su20c358f7ee877a3fd2138ecce98fada08354810b3e9a0e849631851f92d09cc4 ./bin/bzexe01764d96697b060b2a449769073b7cf2df61b5cb604937e39dd7a47017e92ee0 ./bin/znew0d1a106dc28c3c41b181d3ba2fc52086ede4e706153e22879e60e7663d2f6aad ./bin/loginfb130bda68 f6a56e2c2edc3f7d5b805fd9dcfbcc26fb123a693b516a83cfb141 ./bin/dir0e7ca63849eebc9ea476ea1fefab05e60b0ac8066f73c7d58e8ff607c941f212 ./bin/bzmore14dc8106ec64c9e2a7c9430e1d0bef170aaad0f5f7f683c1c1810b466cdf5079 ./bin/zless9cf4cda0f73875032436f7d5c457271f235e59c968c1c101d19fc7bf137e6e37 ./bin/chmodc5f12f157b605b1141e6f97796732247a26150a0a019328d69095e9760b42e38 ./bin/sleepb9711301d3ab42575597d8a1c015f49fddba9a7ea9934e11d38b9ff5248503a8 ./bin/zfgrep0b2840eaf05bb6802400cc5fa793e8c7e58d6198334171c694a67417c687ffc7 ./bin/sttyd9393d0eca1de788628ad0961b74ec7a648709b24423371b208ae525f60bbdad ./bin/bunzip2d2a56d64199e674454d2132679c0883779d43568cd4c04c14d0ea0e1307334cf ./bin/mkdir1c48ade64b96409e6773d2c5c771f3b3c5acec65a15980d8dca6b1efd3f95969 ./bin/ cat09198e56abd1037352418279eb51898ab71cc733642b50bcf69d8a723602841e ./bin/true97f3993ead63a1ce0f6a48cda92d6655ffe210242fe057b8803506b57c99b7bc ./bin/zdiff0d06f9724af41b13cdacea133530b9129a48450230feef9632d53d5bbb837c8c ./bin/lsda2da96324108bbe297a75e8ebf cb2400959bffcdaa4c88b797c4d0ce0c94c50 ./bin/zegrep

Приведенное выше содержимое файла является надежным хэшем SHA256 для определенных файлов. Если мы хотим использовать этот список для обеспечения того, чтобы конкретное изображение использовало перечисленные выше файлы, мы можем сделать следующее:

  $ ./convertSHA.sh доверенные хэши  .txt terrier.yml  

Приведенный выше скрипт принимает входной файл trusthashes.txt , который содержит наши доверенные хэши, перечисленные выше, и преобразует их в терьера. удобный файл конфигурации с именем terrier.yml , который выглядит следующим образом:

  mode: imageimage: myImage. tarfiles: - имя: '/bin/uname' хэши: - хэш: '8946690bfe12308e253054ea658b1552c02b67445763439d1165c512c4bc240d' - имя: '/bin/gzexe' хэшей: - хэш: '6de8254cfd49543097ae946c303602ffd5899b2c88ec27cfcd86d786f95a1e92' - имя: '/bin/wdctl' хэшей: - хэш:  '74ff9700d623415bc866c013a1d8e898c2096ec4750adcb7cd0c853b4ce11c04' - имя: '/bin/dmesg' хэшей: - хэш: '61c779de6f1b9220cdedd7dfee1fa4fb44a4777fff7bd48d12c21efb87009877' - имя: '/bin/, который' хэшей: - хэш: '7bdde142dc5cb004ab82f55adba0c56fc78430a6f6b23afd33be491d4c7c238b' - имя: '/bin/MKNOD код>  

Конфигурационный файл terrier.yml готов к использованию:

  $ ./terrier -cfg  = terrier.yml [+] Загрузка конфигурации: terrier.yml [+] Анализ изображения [+] Докер Image Source: myImage.tar [*] Проверка уровня: 34a9e0f17132202a82565578a3c2dae1486bb198cde76928c8c2c5c461e11ccf [*] Проверка уровня: 6539a80dd09da08132a525494ff97e92f4148d413e7c48b3583883fda8a40560 [*] Проверка уровня: 6d2d61c78a65b6e6c82b751a38727da355d5919416  7b28b3f8def198cd116759 [*] Проверка уровня: a6e646c34d2d2c2f4ab7db95e4c9f128721f63c905f107887839d3256f1288e1 [*] Проверка уровня: aefc8f0c87a14230e30e510915cbbe13ebcabd611e68db02b050b6ceccf9c545 [*] Проверка уровня: d4468fff8d0f28d87d48f51fc0a6afd4b38946bbbe91480919ebfdd55e43ce8c [*] Проверка уровня: dbf9da5e4e5e1ecf9c71452f6b67b2b0225cec310a20891cc5dedbfd4ead667c Не все компоненты были identifed [!]: [!] (4/31) Компонент не определены: /bin/uncompress [!] Компонент не идентифицирован:/bin/bzexe [!] Компонент не идентифицирован:/bin/bzmore [!] Компонент не идентифицирован:/bin/bunzip2 $ echo $? 1  

Как видно из выходных данных выше, Terrier не смог идентифицировать 4/31 компонентов, представленных в конфигурации. Код возврата также равен 1, что указывает на сбой. Если бы мы удалили компоненты, которых нет в предоставленном изображении, результат предыдущей команды выглядел бы следующим образом:

  $ ./terrier -cfg = terrier.  yml [+] Загрузка конфигурации: terrier.yml [+] Анализ изображения [+] Источник изображения Docker: myImage. смолы [*] Проверка слой: 34a9e0f17132202a82565578a3c2dae1486bb198cde76928c8c2c5c461e11ccf [*] Проверка слой: 6539a80dd09da08132a525494ff97e92f4148d413e7c48b3583883fda8a40560 [*] Проверка слой: 6d2d61c78a65b6e6c82b751a38727da355d59194167b28b3f8def198cd116759 [*] Проверка слой: a6e646c34d2d2c2f4ab7db95e4c9f128721f63c905f107887839d3256f1288e1 [*] Проверка слой: aefc8f0c87a14230e30e510915cbbe13ebcabd611e68db02b050b6ceccf9c545 [*] Проверка слой: d4468fff8d0f28d87d48f51fc0a6afd4b38946bbbe91480919ebfdd55e43ce8c [*] Проверка слой: dbf9da5e4e5e1ecf9c71452f6b67b2b0225cec310a20891cc5dedbfd4ead667c  [!] Все компоненты были идентифицированы: (27/27) [!] Не все компоненты были проверены: (26/27) [!] Компонент не проверен:/bin/cat [!] Компонент не проверен:/bin/chmod [  !] Компонент не проверен:/bin/chown [!] Компонент не проверен:/bin/df [!] Компонент не проверен:/bin/dir [!] Компонент не проверен:/bin/dmesg [!] Компонент не проверен: /bin/echo [!] Компонент не проверен:/bin/gzexe [!] Компонент  nt не проверен:/bin/gzip [!] Компонент не проверен:/bin/login [!] Компонент не проверен:/bin/ls [!] Компонент не проверен:/bin/mkdir [!] Компонент не проверен:/bin /mknod [!] Компонент не проверен:/bin/mv [!] Компонент не проверен:/bin/sleep [!] Компонент не проверен:/bin/stty [!] Компонент не проверен:/bin/su [!] Компонент  не проверено:/bin/tar [!] Компонент не проверен:/bin/true [!] Компонент не проверен:/bin/uname [!] Компонент не проверен:/bin/wdctl [!] Компонент не проверен:/bin/ zdiff [!] Компонент не проверен:/bin/zfgrep [!] Компонент не проверен:/bin/zforce [!] Компонент не проверен:/bin/zless [!] Компонент не проверен:/bin/znew $ echo $? 1   

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

Идентификация файлов в контейнерах

Предыдущие разделы были посвящены идентификации Сохранение файлов в изображениях, что можно назвать формой «статического анализа», однако этот анализ также можно выполнять для запущенных контейнеров. Для этого вам потребуется следующее:

  1. Местоположение объединенной папки контейнера
  2. A SHA256-хэш определенного файла/ов

Папка merged специфична для Docker, в данном случае мы используем ее, потому что именно здесь содержимое контейнера Docker находится в другом месте, если бы это был LXC.

Местоположение объединенной папки контейнера можно определить, выполнив следующие команды. Сначала получите идентификатор контейнера:

  $ docker psCONTAINER ID IMAGE КОМАНДА СОЗДАНО ПОРТЫ СОСТОЯНИЯ ИМЕНИb9e676fd7b09 golang "bash" 20 часов назад Время работы 20 часов cocky_robinson  

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

  $ docker exec b9e676fd7b09 mount |  grep diffoverlay on/type overlay (rw, relatime, lowerdir =/var/lib/docker/overlay2/l/7ZDEFE6PX4C3I3LGIGGI5MWQD4:/var/lib/docker/overlay2/l/EZNIFFIXOVO2GIT5PTBI754HC/lib/docker/docker/docker/docker:  UWKXP76FVZULHGRKZMVYJHY5IK:/Var/Библиотека/докер/overlay2/л/DTQQUTRXU4ZLLQTMACWMJYNRTH:/Var/Библиотека/докер/overlay2/л/R6DE2RY63EJABTON6HVSFRFICC:/Var/Библиотека/докер/overlay2/л/U4JNTFLQEKMFHVEQJ5BQDLL7NO:/Var/Библиотека/докер/overlay2/ л/FEBURQY25XGHJNPSFY5EEPCFKA:/Var/Библиотека/докер/overlay2/л/ICNMAZ44JY5WZQTFMYY4VV6OOZ, upperdir =/вар/Библиотека/докер/overlay2/04f84ddd30a7df7cd3f8b1edeb4fb89d476ed84cf3f76d367e4ebf22cd1978a4/Diff, WorkDir =/вар/Библиотека/докер/overlay2/04f84ddd30a7df7cd3f8b1edeb4fb89d476ed84cf3f76d367e4ebf22cd1978a4/работа) код  > 

Из результатов выше нас интересуют две записи, upperdir и workdir , потому что эти две записи предоставят нам на путь к объединенной папке контейнера. Из приведенных выше результатов мы можем определить, что каталог merged контейнера расположен в /var/lib/docker/overlay2/04f84ddd30a7df7cd3f8b1edeb4fb89d476ed84cf3f76d367e4ebf22cd1978a4/, лежащем в основе хоста.

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

  mode: containerpath: merged # image: myImage.tarhashes: - hash: '82bce4b98d7aaeb4f841a36f7141d540bb049f89219f9e377245ad91dd3ff -  cf734865dd344cd9b0b349cdcecd83f79a751150b5fd4926f976adddb93d902c ' 

Приведенная выше конфигурация показывает, что мы изменили режим с image на контейнер , и мы добавили путь в нашу объединенную папку. Мы сохранили два хэша из предыдущего раздела.

Если мы запустим Terrier с этой конфигурацией из местоположения /var/lib/docker/overlay2/04f84ddd30a7df7cd3f8b1edeb4fb89d476ed84cf3f76d367e4ebf22cd1978a4/, мы получим следующий результат:

  $ ./terrier[+] Загрузка конфигурации: cfg. yml [+] Анализ контейнера [!] Обнаружен соответствующий экземпляр '82bce4b98d7aaeb4f841a36f7141d540bb049f89219f9e377245a91dd3ff92dd' по адресу: merged/usr/local/go/bin/go с хешем: 82bce4b9814d7d7daaeb4f>  , мы знаем, что контейнер ( b9e676fd7b09 ) не содержит вредоносного пакета Python, но он содержит экземпляр двоичного файла Golang, который находится в  merged/usr/local/ go/bin/go .  

Идентификация и проверка определенных файлов в контейнерах

И, как вы уже догадались, Terrier также можно использовать для проверки и идентифицировать файлы по определенным путям в контейнерах. Для этого нам понадобится следующее:

  1. Местоположение объединенной папки контейнера.
  2. Хэш SHA256 определенного файла/файлов
  3. Путь и имя конкретного файла/файлов

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

  mode: containerpath: mergedverbose: truefiles: - name: '/usr/ bin/curl 'хеши: - hash:' 9a43cb726fef31f272333b236ff1fde4beab363af54d0bc99c304450065d9c96 '- name:'/usr/local/go/bin/go 'хеши: - hash:' 82bce4b98d7aaaeb1908>    запустите Terrier с указанной выше конфигурацией, мы получим следующий результат:  
  $ ./terrier[+] Загрузка конфигурации: cfg.yml [+] Анализ контейнера [!] Найдено соответствие  экземпляр '/usr/bin/curl' в: объединенном/usr/bin/curl с хешем: 9a43cb726fef31f272333b236ff1fde4beab363af54d0bc99c304450065d9c96 [!] Найден соответствующий экземпляр '/usr/local/go/bin/usr' в:/local/merged  go/bin/go с хешем: 82bce4b98d7aaeb4f841a36f7141d540bb049f89219f9e377245a91dd3ff92dd [!] Все компоненты были идентифицированы: (2/2) [!] Все компоненты были идентифицированы и проверены: (2/2) $ echo $? 0  

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

Использование Terrier с CI/CD

В дополнение к Terrier используется как автономный инструмент командной строки, Terrier также может быть легко интегрирован с существующими технологиями CI/CD, такими как GitHub Actions и CircleCI. Ниже приведены два примера конфигураций, которые показывают, как Terrier можно использовать для идентификации и проверки определенных компонентов файлов Docker в конвейере и предотвращения продолжения конвейера, если все проверки не пройдут. Это можно рассматривать как дополнительное смягчение атак на цепочку поставок.

Ниже приведен пример конфигурации CircleCI с использованием Terrier для проверки содержимого изображения..

  версия: 2jobs: build: machine: true шаги: - checkout - run: name: команда сборки образа Docker: |  docker build -t builditall.  - запустить: name: Команда Сохранить образ Docker локально: |  docker save builditall -o builditall.tar - run: name: Проверить бинарные файлы образа Docker, команда: |  ./terrier

Ниже приведен пример конфигурации Github Actions с использованием Terrier для проверки содержимого изображения.

  name: Goon  : [push] jobs: build: name: Build running-on: ubuntu-latest steps: - name: Получить код использует: actions/checkout @ master - name: Выполнить сборку образа Docker run: |  docker build -t builditall.  - name: Сохранить образ Docker Локально запустить: |  docker save builditall -o builditall.tar - name: Проверить запуск двоичных файлов образа Docker: |  ./terrier  

Заключение

В этом сообщении блога мы рассмотрели, как выполнять несколько действий с контейнерами и изображениями Docker (и OCI) через Терьер. Выполненные действия позволили нам идентифицировать конкретные файлы по их хешам в образах и контейнерах. Выполненные действия также позволили нам идентифицировать и проверять несколько компонентов в образах и контейнерах. Эти действия, выполняемые Terrier, полезны при попытке предотвратить определенные атаки на цепочку поставок.

Мы также видели, как Terrier можно использовать в конвейере DevOps с помощью GitHub Actions и CircleCI.

Узнайте больше о Terrier на GitHub по адресу https://github.com/heroku/terrier.

Оцените статью
clickpad.ru
Добавить комментарий