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

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

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

Мысли по нескольким параметрам:

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

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

100 голосов | спросил Mark Lindroos 9 J000000Wednesday14 2014, 01:54:39

4 ответа


42

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

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

ответил Johannes 'fish' Ziemke 12 PM00000030000001231 2014, 15:41:12
5

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

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

ответил Paul R 3 +04002014-10-03T23:44:28+04:00312014bEurope/MoscowFri, 03 Oct 2014 23:44:28 +0400 2014, 23:44:28
1

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

SUSE /zypper-docker

Быстрый старт Docker

ответил pwl 8 Maypm16 2016, 20:05:40
0

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

ответил Ben Grissinger 9 J000000Wednesday14 2014, 03:23:04

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

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132