[Эта статья была написана Эриком .]
В прошлом году было много дискуссий о безопасности контейнеров Docker, но большинство из них, похоже, были сосредоточены только на одном аспекте контейнеров: изоляции. Пространства имен ядра (изоляция процессов), контрольные группы (изоляция ресурсов) и традиционные сравнения виртуализаций (изоляция гипервизора) были горячими темами в прошлом году, и все они обсуждают различные аспекты одной и той же базовой концепции изоляции. Складывать все яйца в одну корзину никогда не было хорошей идеей, и специалисты по безопасности не должны позволять чрезмерному сосредоточению внимания на изоляции создавать отвлечение от основ безопасности.
Давайте отойдем от этого обсуждения и вместо этого рассмотрим краеугольный камень компьютерной безопасности, управления уязвимостями и почему имеет смысл применять его для безопасности контейнеров.
Несмотря на то, что контейнеры представлены как « просто приложение и его зависимости » , в контейнере происходит гораздо больше, чем в одном приложении. Это « и это зависимости », что интересно. Все контейнеры наследуют родительский образ, как правило, базовую ОС, и вместе с этим возникает множество зависимостей, таких как:
- оболочка
- пользователи по умолчанию
- библиотеки и зависимые пакеты
Безопасность на уровне контейнера просто стала интересной.
Давайте попробуем запустить контейнер на базе CentOS 5.11 из официального хранилища Docker . Это полностью поддерживаемый базовый образ, хотя и на основе установочного носителя, что означает, что он не обновляется с помощью обновлений безопасности. Этот факт выделен IN CAPS и предлагает вам обновить его, если вы собираетесь использовать это изображение. Здесь я хотел бы подчеркнуть одно отличие: безопасность самого Docker полностью отделена от внутренней безопасности общедоступных изображений. Ответственность за управление безопасностью на уровне контейнера лежит на конечных пользователях, и это главная причина, по которой я считаю важным переориентировать обсуждение безопасности на основы.
Итак, давайте начнем и используем мощь и легкость Docker! Команды, которые мы будем использовать:
docker pull centos:5.11 docker run -it --name “centos-5.11” centos:5.11 /bin/bash
После запуска контейнера давайте установим агент Halo с помощью простого сценария оболочки.
#!/bin/sh # add the CloudPassage repository echo -e '[cloudpassage]\nname=CloudPassage\nbaseurl=http://packages.cloudpassage.com/redhat/$basearch\ngpgcheck=1' | tee /etc/yum.repos.d/cloudpassage.repo > /dev/null # import CloudPassage public key rpm --import http://packages.cloudpassage.com/cloudpassage.packages.key # update yum repositories yum check-update > /dev/null # install the agent yum -y install cphalo # run cphalo /opt/cloudpassage/bin/cphalo --daemon-key=abc123abc123abc123abc123abc123ab
Вау, это было довольно быстро и просто. Все преимущества использования контейнера материализовались на ваших глазах! После установки агента Halo давайте рассмотрим эти зависимые пакеты с точки зрения управления уязвимостями.
Хм … и Шеллшок, и Пудель присутствуют. Помните, что я сказал, что ответственность за безопасность контейнеров лежит на конечном пользователе?
Если контейнеры на основе приложений не перестраиваются из обновленного образа на регулярной основе, уязвимости будут возникать в их зависимостях. Если ваши контейнеры имеют общие тома или связаны с другими контейнерами (как, несомненно, будет происходить в большинстве развертываний на основе контейнеров), то фокус безопасности на изоляции кажется слишком узким для темы.
Похоже, что изоляция создает точку принятия решения «все или ничего» о том, являются ли контейнеры жизнеспособным вариантом виртуализации, когда следует применять гораздо более широкий подход к обсуждению рисков и мер по их снижению. Вместо этого диалог должен быть более широким с самого начала и охватывать основы, такие как управление уязвимостями и все остальное, что SDSec привносит в диалог.