УСИЛИВАЕМ БЕЗОПАСНОСТЬ DOCKER
Итак, как нам укрепить Docker? Сначала мы разберем общие рекомендации, а затем конкретные примеры конфигурирования правил и политик безопасности для контейнерного пула.
Использование достоверных образов
Начнем, пожалуй, с банальной для репозиториев Docker проблемы — достоверности образа. Чтобы избежать проблем с фейковыми образами, используй приватные (private) или строго доверенные репозитории (trusted repositories) вроде Docker Hub. В отличие от других репозиториев, образы, которые там хранятся, всегда сканирует и просматривает специальный робот безопасности Docker’s Security Scanning Service.
Верифицируем образы через сервис Docker Content Trust
Еще один полезный и доступный всем инструмент, которым стоит воспользоваться, — Docker Content Trust. Это новая функция, доступная с версии Docker Engine 1.8. Она позволяет верифицировать владельца образа. Таким образом этот сервис защищает тебя от фейков и подделок, атак повторного воспроизведения и компрометации ключей.
Проверка хоста и контейнера с помощью Docker Bench Security Очень полезный инструмент, которым я сам недавно пользовался, — это Docker Bench Security (см. также документацию к нему). По сути, это большая подборка рекомендаций, советов и практик по развертыванию контейнеров в продакшене. Инструмент основывается на рекомендациях из документа The CIS Docker 1.13 Benchmark (PDF) и применяется в следующих областях:
- конфигурация хоста (ядро, процессы, разрешения);
- конфигурация демона Docker (сеть, выделение RAM, CPU);
- файлы конфигурации демона Docker;
- образы контейнеров и build‐файлы;
- Runtime контейнера;
- опции «по умолчанию» Docker
Чтобы установить этот скрипт проверки, клонируй репозиторий следующей командой в терминале:
|
1 |
$ git clone git@github.com:docker/docker‐bench‐security.git |
После этого запускаем скрипт:
|
1 |
$ cd docker‐bench‐secutity |
и юзаем такую вот длинную команду:
|
1 2 3 4 5 |
$ docker run ‐it ‐‐net host ‐‐pid host ‐‐cap‐add audit_control \ ‐e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \ ‐v /var/lib:/var/lib \ ‐v /var/run/docker.sock:/var/run/docker.sock \ ‐v /etc:/etc ‐‐label docker_bench_security \ docker/docker‐bench‐security |
Выполнив эти шаги, ты соберешь все контейнеры и запустишь скрипт, который проверит безопасность хост‐машины (kernel OS) и ее контейнеров. И это займет всего лишь несколько минут!
Запуск скрипта Docker Bench Security
Использование нативных опций безопасности на хостовых ОС
Для усиления безопасности ты можешь воспользоваться штатными инструментами Linux. Среди них — AppArmor, SELinux, grsecurity и Seccomp.
Проще всего было бы скачать дефолтный профиль Seccomp для Docker. Чтобы обеспечить самый банальный уровень секьюрности, достаточно скоректировать белый список системных вызовов в районе строки 52 — то есть просто удалить из него рисковые команды chmod, fchmod и fchmodat.
Однако тонкая настройка этих механизмов безопасности выходит далеко за рамки нашей статьи. Если ты еще ни разу их не конфигурировал, обращайся к официальной документации. От себя рекомендую пару неплохих статей по Seccomp и SELinux.
НАСТРОЙКА ОПЦИЙ УСИЛЕНИЯ БЕЗОПАСНОСТИ ДЛЯ DOCKER
Вот мы наконец и добрались до консоли! Сейчас будем ручками выстраивать безопасность для Docker. Готов? Поехали!
Ограничения Docker Engine
Вспомним, что Docker Engine — это своего рода API, который прослушивает все входящие запросы и взаимодействует с базовым ядром хоста. Docker Engine поддерживает связь на трех сокетах: unix, tcp и fd.
Безопасное состояние по умолчанию — это прослушивание сокета unix.
Для активации этой опции набери в терминале
|
1 |
$ dockerd ‐H "unix:///var/run/docker.sock" |
Готово, больше ничего не требуется!
Выставляем ограничение на привилегии выполнения
По возможности запускай контейнеры как обычный пользователь без полномочий root:
|
1 2 |
$ docker run ‐d ‐u 1000 debian sleep infinity $ ps aux | grep sleep 1000 ... sleep infinity |
Чтобы максимально уменьшить площадь потенциальной атаки, подумай над следующими вопросами:
- Какое сетевое подключение требуется для работы приложения и вообще требуется ли оно?
- Нужен ли приложению прямой доступ к сокету?
- Требуется ли приложению отправлять и получать UDP‐запросы?
Для настройки ограничений будем использовать команды ‐‐cap‐drop и ‐‐cap‐add.
Предположим, приложению абсолютно не требуется изменять системные процессы или биндить привилегированные порты, но при этом нужно загружать и выгружать модули ядра. Соответствующие возможности можно удалить и добавить следующим образом:
|
1 |
$ docker run \ |
Также необходимо следить за случаями монтирования потенциально опасных ресурсов хоста (к примеру, таких, как /proc, /dev, /var/run/docker.sock). Несмотря на то что эти ресурсы нужны для работы контейнеров, все же стоит задуматься о необходимости ограничить доступ процессов к ним. К примеру, будет достаточно лишь установить к ним режим доступа «только чтение».
Для обеспечения безопасности сетевого взаимодействия можно настроить правила iptables, реализованные в Docker. Например, указать диапазон IP‐адресов для источника пакетов, чтобы ограничить трафик на контейнер. Это поможет предотвратить обращение глубоко изолированного контейнера во внешнюю сеть. Включить эту функцию можно всего парой команд:
|
1 2 |
$ iptables ‐t filter ‐A FORWARD ‐s <source_ip_range> ‐j REJECT ‐‐reject‐with icmp‐admin‐prohibited |
Ограничиваем потребление системных ресурсов
Чтобы откалибровать пул ресурсов, выделяемых для контейнера (CPU, RAM, SWAP, I/O), нужно задать пороговые значения следующими командами:
- m, memory — установить лимит выделения оперативной памяти (hard);
- memoryreservation — установить мягкий лимит памяти (soft);
- kernelmemory — установить лимит памяти ядра (kernel OS);
- cpus — ограничить количество используемых CPU;
- devicereadbps — ограничить пропускную способность чтения для конкретного устройства.
Также не забывай юзать специальную фичу под названием cgroups. Контрольные группы (cgroups) — это предоставляемый ядром Linux штатный инструмент, который позволяет ограничивать доступ процессов и контейнеров к системным ресурсам. Некоторые лимиты можно контролировать сразу из командной строки Docker, например:
|
1 |
$ docker run ‐it ‐‐memory=4G ‐‐memory‐swap=1G debian bash |
Этой командой мы выделяем для работы контейнера 4 Гбайт оперативной памяти и 1 Гбайт для кеширования в своп.
Мониторим активность работы контейнеров
Мониторинг, обнаружение аномального, подозрительного поведения контейнера и оповещение о нем — это один из ключевых инструментов анализа и своевременного реагирования на инциденты. Для этих целей можно использовать тулзу с открытым исходным кодом Sysdig Falco.
Sysdig Falco работает как система обнаружения вторжений и в особенности полезна при использовании Docker, поскольку в процессе создания правил поддерживает специфический для контейнеров контекст, такой как contain‐ er.id, container.image, ресурсы Kubernetes или пространства имен.
Да, кстати, еще одна вещь из стандартного набора контроля и аудита ОС — это журналирование событий. Для этого запускаем контейнер с ключом, ответственным за логирование:
|
1 2 3 |
$ docker run ‐v /dev/log:/dev/log <container_name> /bin/sh |
Палим CVE-уязвимости в контейнерах
Контейнеры Docker — это, по сути, изолированные черные ящики, которые крутятся на родительском хосте. Однако все может отлично работать, но при этом внутри оказывается уязвимое ПО. Причем в апстриме уязвимости могут быть давно пропатчены, но не в твоем локальном образе! И если не принять меры, такие проблемы могут долго оставаться незамеченными. И что, скажи на милость, с этим делать?
Многие реестры образов Docker предлагают услугу сканирования этих самых образов. Например, сервис CoreOS Quay использует сканер безопасности образов Docker с открытым исходным кодом под названием Clair. Clair — это приложение, написанное на Go, которое реализует набор HTTP API для выгрузки, загрузки и анализа образов. Данные об уязвимостях загружаются из разных источников, таких как Debian Security Tracker или Red Hat Security Data. В этом случае движок Clair работает по принципу статического анализатора без запуска контейнера на выполнение.
Ну и если ты совсем зеленый админ или руководство адски жмет денег, где‐то на просторах Сети, говорят, есть аналогичные сервисы с теми же возможностями, но при этом совершенно бесплатные! Правда, я таких пока не встречал. Поэтому, если уж совсем нет выбора, можно юзать старый добрый OpenVAS либо аналогичный секьюрный сканер, который ты будешь запускать ручками по расписанию внутри своей корпоративной сетки.
ЗАКЛЮЧЕНИЕ
Поздравляю! Сегодня мы прокачали твои админские скиллы в защите систем контейнеризации на базе Docker. Теперь ты знаешь об основных угрозах для DevOps‐окружения и понимаешь, чем можно поплатиться за беспечность, если не обращать внимания на тему секьюрности. Также мы собрали неплохой набор инструментов для обеспечения безопасности Docker. Надеюсь, он поможет тебе максимально защитить свои информационные активы, если не получиться обращайся [email protected]
