При развертывании приложений на серверы обычно существует разделение между тем, что комплекты приложений с собой и что оно ожидает от платформы (операционная система и установленные пакеты) обеспечивать. Одна точка этого - то, что платформа может быть обновлена независимо от приложения. Это полезно, например, когда обновления системы защиты должны быть применены срочно к пакетам, обеспеченным платформой, не восстанавливая целое приложение.
Традиционно обновления системы защиты были применены просто путем выполнения команды диспетчера пакетов для установки обновленных версий пакетов в операционной системе (например, "вкусное обновление" на RHEL). Но с появлением контейнерной технологии, такой как Докер, где контейнерные изображения по существу связывают и приложение и платформу, каков канонический способ сохранить систему с контейнерами актуальной? И хост и контейнеры имеют их собственное, независимое, наборы пакетов, для которых нужно обновление, и обновление на хосте не обновит пакетов в контейнерах. С выпуском RHEL 7, где контейнеры Докера особенно показаны, было бы интересно услышать, какой рекомендуемый способ Redhat обработать обновления системы защиты контейнеров.
Мысли о нескольких опций:
Таким образом, ни один из этих подходов не кажется удовлетворительным.
Приложение Docker image bundles application and "platform", that's correct. Но обычно образ состоит из базового образа и реального приложения.
Таким образом, канонический способ обработки обновлений безопасности заключается в обновлении базового образа, а затем пересобранном образе приложения.
.Прежде всего, многие из ваших обновлений, которые вы традиционно запускали в прошлом, просто не будут находиться внутри самого контейнера. Контейнер должен быть достаточно лёгким и небольшим подмножеством полной файловой системы, которую вы привыкли видеть в прошлом. Пакеты, которые вам нужно обновить, должны быть частью вашего DockerFile, а поскольку у вас есть DockerFile, вы должны иметь возможность отслеживать те пакеты и идентификаторы контейнеров, которые нуждаются в обновлениях. Интерфейс Cloudstein, который скоро будет выпущен, отслеживает эти ингредиенты DockerFile для вас, чтобы вы могли построить схему обновления, которая лучше всего подходит для их контейнеров. Надеюсь, это поможет
Контейнеры должны быть легкими и взаимозаменяемыми. Если у вашего контейнера проблемы с безопасностью, вы перестраиваете версию контейнера, которая была исправлена, и устанавливаете новый контейнер. (многие контейнеры используют стандартный базовый образ, который использует стандартные инструменты управления пакетами, такие как apt-get для установки своих зависимостей, при пересборке обновления будут извлекаться из репозиториев)
Хотя вы можете исправлять внутри контейнеров, это не будет хорошо масштабироваться.
это, как правило, даже хуже, чем три варианта, которые вы предоставили. Большинство образов докеров не создаются с помощью диспетчеров пакетов, поэтому вы не можете просто использовать оболочку образа докера и выпустить обновление. Вам нужно будет либо перестроить, либо заново получить образ докера.
Тот факт, что вам нужно перестроить или вы ждете от других, чтобы восстановить исправления безопасности, в большинстве случаев кажется неразумным.
Я рассматривал возможность развертывания сонара и радара в докере контейнеры, но знание того, что они не собираются получать регулярные обновления безопасности, которые получает мой контейнер, является нарушением сделки. Управление обновлениями безопасности для моего контейнера - это достаточно хлопот, и вам не придется как-то вручную применять обновления безопасности к каждому образу докера по отдельности.