В первой части статьи, опубликованной в предыдущем номере журнала, речь шла о том, как появился Docker и какое влияние на него оказали различные подходы к группированию процессов и организации их работы таким образом, чтобы они не выходили из-под контроля. Во второй части мы рассмотрим проблемы безопасности контейнера Docker, которые усиливались по мере роста популярности платформы.nnШирокое применение модели программирования с непрерывной интеграцией (CI) удачно сочетается с Docker, и его популярность взмыла вверх. На сегодня в собственных «официальных» репозиториях (https://docs.docker.com/docker-hub/repos/) хранятся сотни тысяч готовых образов Docker. И в этом кроется самая большая проблема безопасности контейнера Docker: целостность образа и настроек.nnКогда речь идет о безопасности контейнера Docker, для моделей оркестровки предпочтительны интегрированные роли, проверки сети и узкие направления атаки с защитой узлаnnЦелостность напрямую зависит от происхождения и гарантий, что образы исправлены или обновлены. Мониторинг поведения среды выполнения важен (и для его осуществления предусмотрены как специальные методы, так и ориентированные на контейнерные платформы продукты, но не будем забывать что в том и состоит гибкость образов Docker? что они либо работают, либо умирают. В худшем случае репозиторий может быть заражен — преднамеренно или нет.nnНедавно было обнаружено 17 различных образов Docker, содержащих обратные оболочки (reverse shell), программы захвата ключа безопасности или программу криптомайнинга Monero. Эти образы были удалены из репозиториев. В каждом случае были найдены способы обеспечить безопасность Docker и управляемых контейнеров, но для этого требуется дополнительная обработка.nnПредполагается, что Docker обнаруживает проблемы с образами, выполняя их анализ, но это происходит только на корпоративном уровне. То же делают многие сторонние программы безопасности контейнеров, и другие репозитории и реестры могут анализировать образы в поисках вредоносных программ или неверных настроек.nnКакие здесь возникают препятствия? Один вариант — присутствие вредоносной программы, но возможны и ошибки в настройках образов или внесение несанкционированных изменений в рабочей среде. В частности, встречаются неправильно составленные файлы настроек. Примером может служить разрешение входа root по SSH с известным набором предварительно подготовленных ключей.nnЭто проблема файла настроек, однако некоторые разработчики используют данный прием в своих предварительных образах. Случайные репозитории образов следует считать вовсе смертельно опасными, но даже «официальные» репозитории не проверяются достаточно надежно. Мы рассмотрим «модели с нулевым доверием» (https://www.gartner.com/smarter withgartner/gartner-top-10-security-projects-for-2018/).nnСуществуют еще проблемы с исправлениями, а также необходимыми обновлениями исходных файлов образа и узла, на котором размещен Docker. Запросы и обновления часто обрабатываются с помощью инструментов, уже используемых разработчиками, в том числе средствами управления Kubernetes или Mesos. Puppet, Chef и даже Jenkins могут быть настроены для управления и анализа парка контейнеров, даже в производственной среде и после этапа разработки. Направить в Docker запрос относительно компонентов и статуса образа — хорошо известная процедура.n
Предпочтение моделей с наименьшим и нулевым доверием
Как отмечалось в первой части статьи, Docker выполняется как корневой процесс, чтобы до минимума понизить уровень привилегий пользователя и доступность хранилищ данных. Как объекты низкого ранга, контейнеры уязвимы из-за множества соединенных с ними других объектов, в основном через сеть, но также через хранилище данных.nnВ связи с этим имеется два вектора привилегий: один в административной плоскости, где контейнеры развертываются в рабочие единицы, и другой в плоскости, где подключенные контейнеры должны обмениваться друг с другом данными, чтобы функционировать как единица рабочей нагрузки.nnДоверие передается по цепочке организаций и известных состояний, и каждая организация, которая выполняет развертывание измененных конструкций Docker, должна иметь возможность самостоятельно проверить состояния. Без такого рода ограничений возникают нарушения, подрывается соответствие требованиям нормативных актов и рушится инфраструктура.nnНеобходимо строго контролировать административное доверие, чтобы предотвратить изменения образов известными или неизвестными лицами. Иногда изменения вносятся, чтобы исправить ошибки, а иногда в образы вводится код для майнинга Monero.nnМодели с нулевым доверием как минимум располагают безопасным или шифрованным каналом между производственными элементами, что также подразумевает наличие ключей шифрования, средств управления ключами и ссылок на упомянутую выше административную плоскость. Некоторые организации также используют элементы политики, касающиеся уровней или степеней прав изменение параметров сетей, хранилищ, базовых компонентов или контейнеров в соответствии с нуждами рабочих нагрузок.nnПредполагается, что Docker обнаруживает проблемы с образами, выполняя их анализ, но это происходит только на корпоративном уровне. То же делают многие сторонние программы безопасности контейнеров, и другие репозитории и реестры могут анализировать образы в поисках вредоносных программ или неверных настроек.n
Внедрить использование контейнеров Docker для безопасного тестирования приложений поможет DevOps инженер с опытом проведения подобных мероприятий.