Docker — прекрасная вещь, которая может экономить массу сил и времени. В этой статье мы поговорим о том, как использовать Docker максимально безопасно и отлавливать потенциальные угрозы заранее. Также ты найдешь здесь готовые рекомендации, команды и инструменты, которые легко использовать в своем проекте.
Контейнерная виртуализация на базе Docker крайне популярна среди DevOps-админов. Она позволяет быстро раскатать инструменты разработки и тестирования ПО или целые проекты из многих компонентов. И все бы хорошо, если бы не целый класс специфических угроз безопасности. Это и возможность побега из контейнера в хостовую систему, и шатдаун инстанса в результате «отказа в обслуживании», и кейсы с эксплуатацией уязвимостей ядра ОС, и подкидывание заранее скомпрометированных эталонных образов в репозиторий, и тому подобные атаки.
В этом материале мы с помощью админской смекалки, прямых рук и всех доступных штатных средств Linux научимся настраивать максимально безопасное и контролируемое DevOps-окружение на основе контейнеризации Docker.
Мы уже не раз рассказывали о самой системе контейнеризации, публиковали большой FAQ по ней, раскрывали малоизвестные трюки и фишки и на пальцах объясняли, как сделать свою песочницу. Однако вопрос настройки опций безопасности для контейнеров все это время оставался в стороне. Сейчас мы посмотрим на Docker глазами спеца по безопасности (или хакера, если уж мы всерьез подняли эту тему).
Docker — это ПО для автоматизации развертывания приложений и управления ими в средах с поддержкой контейнеризации. Софтина позволяет упаковывать любое приложение со всем его окружением и зависимостями в специальный контейнер, который можно запустить в любом современном Linux.
Таким образом, каждый созданный нами контейнер уже включает в себя все необходимое для работы приложения — библиотеки, системные инструменты, код и среду исполнения. Благодаря Docker DevOps-администраторы и разработчики могут быстро развертывать, масштабировать и запускать свои приложения в любой среде и быть при этом уверенными, что написанный код будет нормально работать.
Docker имеет многие фишки, которые есть у систем традиционной виртуализации. К примеру:
Однако в отличие от традиционной виртуализации, где образ мы, как правило, формируем сами, Docker работает с образами, взятыми из репозиториев. Существуют публичные и приватные хранилища официальных и неофициальных образов. В документации они называются docker registry. А самый популярный на сегодня и часто используемый репозиторий — это Docker Hub.
Docker image — это последовательный набор программных слоев. Каждый слой — результат работы команды в конфигурационном файле Dockerfile. То есть образ — это шаблон, на основе которого мы запускаем контейнер. А вот все, что запускается на основе этого образа, и есть сам контейнер (инстанс). В итоге у Docker появляется очень полезная фича, которая позволяет из одного подготовленного образа запускать несколько одинаковых копий этого образа, то есть контейнеров.
Docker, как и любое другое ПО, к сожалению, имеет свои уязвимости и недостатки безопасности, которые может проэксплуатировать хакер. Мы ранее уже писали про неверно настроенные root-аккаунты, подвергающие контейнеры компрометации, легальные образы с запиленными бэкдорами, рабочими PoC-эксплоитами и совсем свежий критический баг, для которого еще нет патча.
Давай пройдемся по типовым кейсам, связанным с безопасностью инфраструктуры Docker.
Один из самых простых и в то же время ключевых вопросов защиты Docker — это безопасность хостовой машины, в частности ядра ОС. Ведь в уже скомпрометированной системе изоляция и прочие механизмы безопасности контейнеров, которые мы могли бы использовать, нам вряд ли помогут. А все потому, что Docker спроектирован таким образом, что все запущенные контейнеры используют ядро хоста. Поэтому в качестве хоста должен быть пропатченный, обновленный дистрибутив Linux без известных уязвимостей и признаков инфицирования малварью.
Классический пример такого кейса — это побег из контейнера Docker. В официальной документации этот баг называется «выходом за пределы контейнера» (container breakout) и описывает ситуацию, при которой программе, запущенной внутри контейнера, удается преодолеть механизмы изоляции и получить рутовые привилегии или доступ к важной информации, хранящейся на хосте. Типичный пример этого бага — DirtyCow (CVE-2016-5195), мы о нем уже рассказывали.
Для реализации защиты от подобных ситуаций используется правило уменьшения количества привилегий для контейнера, выдаваемых ему по умолчанию. Так, если демон Docker выполняется под рутом, то мы создаем для него пользовательское пространство имен (user-level namespace) с минимальными привилегиями.
Если сравнивать контейнеры с виртуальными машинами, то первые более легковесны. Даже на старом и слабом железе можно запустить много контейнеров. Однако ошибки в конфигурации демонов, сетевого стека, недостатки проектирования архитектуры и атаки хакеров могут приводить к состояниям типа «отказ в обслуживании» (Denial of Service).
К примеру, некий контейнер или целый пул контейнеров может пожрать все процессорное время хоста и просадить его производительность. Аналогичная ситуация может сложиться и с сетевыми интерфейсами, когда количество генерируемых пакетов превысит нормальную пропускную способность сети. Но выход тут, в принципе, довольно прост: должным образом настроить лимиты ресурсов для контейнера.
Материалы из последних выпусков становятся доступны по отдельности только через два месяца после публикации. Чтобы продолжить чтение, необходимо стать участником сообщества «Xakep.ru».
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее
1 год7690 р. |
1 месяц720 р. |
Я уже участник «Xakep.ru»
Читайте также
Последние новости
2009-2024 © Все права защищены.
This website - is fan-site, not an official Huawei website. The Huawei logo is a trademark of Huawei Technologies. Other trademarks are the property of their respective owners.
|