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

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

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

Мысли о нескольких опций:

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

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

117
задан 6 December 2016 в 15:29
5 ответов

Приложение Docker image bundles application and "platform", that's correct. Но обычно образ состоит из базового образа и реального приложения.

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

.
47
ответ дан 28 November 2019 в 19:19

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

0
ответ дан 28 November 2019 в 19:19

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

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

7
ответ дан 28 November 2019 в 19:19

Это выполняется автоматически в SUSE Enterprise Linux с помощью zypper-docker (1)

SUSE / zypper-docker

Docker Quick Start

2
ответ дан 28 November 2019 в 19:19

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

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

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

-1
ответ дан 28 November 2019 в 19:19

Теги

Похожие вопросы