Как обрабатывать обновления безопасности в контейнерах Docker?

117

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

Традиционно обновления безопасности применялись просто путем выполнения команды менеджера пакетов для установки обновленных версий пакетов в операционной системе (например, «yum update» в RHEL). Но с появлением контейнерной технологии, такой как Docker, в которой образы контейнеров по существу объединяют и приложение, и платформу, каков канонический способ поддержания системы с контейнерами в актуальном состоянии? И хост, и контейнеры имеют свои собственные, независимые наборы пакетов, которые требуют обновления и обновления на хосте, не будет обновлять какие-либо пакеты внутри контейнеров. С выпуском RHEL 7, в котором контейнеры Docker особенно представлены, было бы интересно услышать, как Redhat рекомендует способ обработки обновлений безопасности контейнеров.

Мысли о нескольких вариантах:

  • Разрешение менеджеру пакетов обновлять пакеты на хосте не будет обновлять пакеты внутри контейнеров.
  • Необходимость регенерации всех образов контейнеров для применения обновлений, по-видимому, нарушает разделение между приложением и платформой (обновление платформы требует доступа к процессу сборки приложения, который генерирует образы Docker).
  • Выполнение ручных команд внутри каждого из запущенных контейнеров кажется громоздким, и изменения могут быть перезаписаны при следующем обновлении контейнеров из артефактов выпуска приложения.

Так что ни один из этих подходов не кажется удовлетворительным.

Маркус Халлманн
источник
1
Лучшая идея для этого я видел до сих пор - Project Atomic . Я не думаю, что он вполне готов к прайм-тайм.
Майкл Хэмптон
1
Валько, какой рабочий процесс у тебя получился? Я бегу долгосрочных контейнеров (хостинг PHP-CGI, например) , и то , что я нашел до сих пор: docker pull debian/jessieобновить изображение, а затем восстановить свой существующий образ (ы), а затем остановить контейнеры и запустить их снова ( с новым изображением). Изображения, которые я создаю, имеют то же имя, что и предыдущие, поэтому запуск выполняется через скрипт. Затем я удаляю «безымянные» изображения. Я, безусловно, был бы признателен за лучший рабочий процесс.
миха
1
Миха: Это звучит похоже на то, что я закончил делать. В основном, постоянно обновляются и перестраиваются все изображения, как часть новых выпусков. И перезапуск контейнеров с использованием новых изображений.
Маркус Халлманн
1
Лучший ответ здесь очень помогает, потому что есть сценарий, который содержит основные командные строки, чтобы сделать именно то, что сказал Йоханнес Зимке:
Гудзон Сантос
Интересный вопрос. Интересно об этом сам. Если на одном док-хосте запущено 20 приложений, вам необходимо обновить базовые образы, перестроить и перезапустить! 20 приложений, и вы даже не знаете, коснулось ли обновление безопасности их всех или только одного из них. Вы должны перестроить образ, скажем, для Apache, когда обновление безопасности коснулось, например, только libpng. Таким образом, вы получите ненужные перестройки и перезапуски ...
Далибор Филус

Ответы:

47

Образ Docker связывает приложение и «платформу», это правильно. Но обычно изображение состоит из базового изображения и фактического приложения.

Таким образом, канонический способ обработки обновлений безопасности - обновить базовый образ, а затем перестроить образ приложения.

Йоханнес Фиш Зимке
источник
3
Спасибо, это звучит разумно. Просто хотелось бы, чтобы обновление платформы, так сказать, не вызывало бы переупаковку всего приложения (рассмотрим, например, необходимость перестраивать 100 различных образов приложения из-за обновления одного базового образа). Но, возможно, это неизбежно при философии Docker, объединяющей все вместе в одном изображении.
Маркус Халлманн
3
@ValkoSipuli Вы всегда можете написать скрипт для автоматизации процесса.
dsljanus
Почему бы не добавить apt-get upgrade, dnf upgrade, pacman -syu и т. Д. Внутри контейнера? Вы можете даже создать сценарий оболочки, который сделает это, а затем запустит приложение, а затем использовать его в качестве точки входа контейнера, чтобы при запуске / перезапуске контейнера он обновлял все свои пакеты.
Артур Кей,
8
@ArthurKay Две причины: 1) Вы увеличиваете размер контейнера, поскольку все обновляемые пакеты будут добавлены в слой контейнера, сохраняя устаревший пакет в изображении. 2) Он побеждает самое большое преимущество (контейнерных) изображений: образ, который вы запускаете, не тот, который вы создаете / тестируете, потому что вы меняете пакеты во время выполнения.
Йоханнес 'рыба' Ziemke
7
Одна вещь, которую я не понимаю: если вы компания, покупающая часть программного обеспечения, которая поставляется в виде док-контейнера, нужно ли ждать, пока производитель программного обеспечения перестроит пакет приложения каждый раз, когда возникает проблема безопасности ? Какая компания таким образом откажется от контроля над своими открытыми уязвимостями?
Sentenza
7

Контейнеры должны быть легкими и взаимозаменяемыми. Если у вашего контейнера есть проблемы с безопасностью, вы перестраиваете исправленную версию контейнера и развертываете новый контейнер. (многие контейнеры используют стандартный базовый образ, который использует стандартные инструменты управления пакетами, такие как apt-get, для установки своих зависимостей, перестройка будет получать обновления из репозиториев)

Хотя вы можете вносить исправления в контейнеры, это не будет хорошо масштабироваться.

Пол Р
источник
0

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

Бен Гриссингер
источник
-1

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

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

Я думал о развертывании sonarr и radarr в док-контейнерах, но зная, что они не будут получать регулярные обновления безопасности, которые получает мой контейнер, это нарушит условия сделки. Управление обновлениями безопасности для моего контейнера - это достаточно хлопотно, не имея необходимости каким-либо образом вручную устанавливать обновления безопасности для каждого образа докера отдельно.

Ли Берч
источник
1
Ваш пост не будет считаться ответом, так как вы не дадите ответ на вопрос. Пожалуйста, добавьте его в качестве комментария к вопросу и удалите свой «ответ». StackExchange не является форумом, но его следует рассматривать как вопрос и ответ, где эксперты отвечают на вопросы, с которыми они могут помочь.
Филипп-Зьян К Ли-Стокманн