Docker — прекрасная вещь, которая может экономить массу сил и времени. В этой статье мы поговорим о том, как использовать Docker максимально безопасно и отлавливать потенциальные угрозы заранее. Также ты найдешь здесь готовые рекомендации, команды и инструменты, которые легко использовать в своем проекте.

Контейнерная виртуализация на базе Docker крайне популярна среди DevOps-админов. Она позволяет быстро раскатать инструменты разработки и тестирования ПО или целые проекты из многих компонентов. И все бы хорошо, если бы не целый класс специфических угроз безопасности. Это и возможность побега из контейнера в хостовую систему, и шатдаун инстанса в результате «отказа в обслуживании», и кейсы с эксплуатацией уязвимостей ядра ОС, и подкидывание заранее скомпрометированных эталонных образов в репозиторий, и тому подобные атаки.

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

 

Глазами безопасника

Мы уже не раз рассказывали о самой системе контейнеризации, публиковали большой FAQ по ней, раскрывали малоизвестные трюки и фишки и на пальцах объясняли, как сделать свою песочницу. Однако вопрос настройки опций безопасности для контейнеров все это время оставался в стороне. Сейчас мы посмотрим на Docker глазами спеца по безопасности (или хакера, если уж мы всерьез подняли эту тему).

 

Что такое Docker и как он работает

Docker — это ПО для автоматизации развертывания приложений и управления ими в средах с поддержкой контейнеризации. Софтина позволяет упаковывать любое приложение со всем его окружением и зависимостями в специальный контейнер, который можно запустить в любом современном Linux.

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

Docker имеет многие фишки, которые есть у систем традиционной виртуализации. К примеру:

  • независимость — контейнер можно переместить на любую ОС с предварительно поднятой службой Docker и запустить одной командой;
  • самодостаточность — контейнер будет выполнять все заданные ему функции в любом месте, где бы его ни запустили, без дополнительной настройки и обслуживания.

Однако в отличие от традиционной виртуализации, где образ мы, как правило, формируем сами, Docker работает с образами, взятыми из репозиториев. Существуют публичные и приватные хранилища официальных и неофициальных образов. В документации они называются docker registry. А самый популярный на сегодня и часто используемый репозиторий — это Docker Hub.

Сравнение Docker и VM
Сравнение Docker и VM

Docker image — это последовательный набор программных слоев. Каждый слой — результат работы команды в конфигурационном файле Dockerfile. То есть образ — это шаблон, на основе которого мы запускаем контейнер. А вот все, что запускается на основе этого образа, и есть сам контейнер (инстанс). В итоге у Docker появляется очень полезная фича, которая позволяет из одного подготовленного образа запускать несколько одинаковых копий этого образа, то есть контейнеров.

INFO

Docker, как и любое другое ПО, к сожалению, имеет свои уязвимости и недостатки безопасности, которые может проэксплуатировать хакер. Мы ранее уже писали про неверно настроенные root-аккаунты, подвергающие контейнеры компрометации, легальные образы с запиленными бэкдорами, рабочими PoC-эксплоитами и совсем свежий критический баг, для которого еще нет патча.

 

Типовые проблемы безопасности, связанные с Docker

Давай пройдемся по типовым кейсам, связанным с безопасностью инфраструктуры Docker.

Безопасность хостовой системы

Один из самых простых и в то же время ключевых вопросов защиты Docker — это безопасность хостовой машины, в частности ядра ОС. Ведь в уже скомпрометированной системе изоляция и прочие механизмы безопасности контейнеров, которые мы могли бы использовать, нам вряд ли помогут. А все потому, что Docker спроектирован таким образом, что все запущенные контейнеры используют ядро хоста. Поэтому в качестве хоста должен быть пропатченный, обновленный дистрибутив Linux без известных уязвимостей и признаков инфицирования малварью.

Классический пример такого кейса — это побег из контейнера Docker. В официальной документации этот баг называется «выходом за пределы контейнера» (container breakout) и описывает ситуацию, при которой программе, запущенной внутри контейнера, удается преодолеть механизмы изоляции и получить рутовые привилегии или доступ к важной информации, хранящейся на хосте. Типичный пример этого бага — DirtyCow (CVE-2016-5195), мы о нем уже рассказывали.

Для реализации защиты от подобных ситуаций используется правило уменьшения количества привилегий для контейнера, выдаваемых ему по умолчанию. Так, если демон Docker выполняется под рутом, то мы создаем для него пользовательское пространство имен (user-level namespace) с минимальными привилегиями.

Исчерпание ресурсов, или DDoS на контейнер

Если сравнивать контейнеры с виртуальными машинами, то первые более легковесны. Даже на старом и слабом железе можно запустить много контейнеров. Однако ошибки в конфигурации демонов, сетевого стека, недостатки проектирования архитектуры и атаки хакеров могут приводить к состояниям типа «отказ в обслуживании» (Denial of Service).

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

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.


Check Also

Блиц-интервью: Алексей Лукацкий о построении защиты, «Гидре» и формуле взлома

Алексей Лукацкий — именитый эксперт в области ИБ, а также владелец самой узнаваемой шляпы …

4 комментария

  1. Аватар

    mitrofanzzz

    11.07.2019 at 12:59

    Статья не только познавательна с точки зрения ИБ, она еще и сам докер представляет в выгодном свете. Спасибо, было интересно.

  2. Аватар

    soko1

    18.07.2019 at 14:01

    Вопрос имею про docker-bench-secutity. Можно ли его пускать в продакшене? Не перезапускает ли он уже запущенные контейнеры и не проивзодит ли с ними какие манипуляции, которые могут повлиять на работу? Пока доки не читал, но в закладки добавил, обязательно прогоню везде.

    Полезная статья, спасибо автору 🙂

    • Иван Пискунов

      Иван Пискунов

      19.07.2019 at 20:35

      Docker bench secutity это обычный скрипт на языке командной оболочки с подвязанной базой эталонных значений тех опций безопасности, которые должны быть форсированы в системе. Никаких других манипуляций кроме как «сбора данных и аудита» тулза не проводит, так, что теоретически на PROD запускать ее можно))) но все лучше таки сначала прогнать ее на тестовой среде)

Оставить мнение