Усиливаем безопасность инфраструктуры Docker

Усиливаем безопасность инфраструктуры Docker

https://t.me/w2hack

Intro

На одном из своих проектов я вплотную столкнулся задачами обеспечения безопасности DevOps и в частности бек-енда построенного на Docker. В отличии от того, что приходилось делать раньше фишка состоит в том, что все тачки находяться не in-house, как это было в крупных организациях, а в облаке, к примеру в AWS или MS Azure. Да еще к тому же ИТ-инфраструктура идеологически построена как код. Это и хорошо и одновременно не очень хорошо. Из плюсов это гибкость, скорость, безшовная интеграция, удобное управление. Из минусов это использование не традиционных подходов ИБ к обеспечению безопасности этой ИТ-инфраструктуры. Но не будем уходить в полемику, двинемся ближе к технической части. Всеми силами и срдствами нам нужно обеспечить  ̶м̶а̶к̶с̶и̶м̶а̶л̶ь̶н̶ы̶й̶ хоть какой-то мало мальский уровень ИБ для Docker, т.к. почти все что есть в DevOps с точки зрени кода и конечного продукта крутится менно там.

Поэтому сегодня в статье обзор самых основных рекомендаций и натроек безопасности для Docker, которые может выполнить любой инженер ИБ или системный администратор DevOps.

1.Что такое Docker?

И так, давайте сначала совсем кратко разберемся, что такое Docker, зачем он нужен в современных реалиях DevOps и какие есть проблемы безопасности.

Docker  - это программное обеспечение для автоматизации развёртывания и управления приложениями в средах с поддержкой контейнеризации. Позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, который может быть перенесён на любую Linux-систему.

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

1.1 Ключевые отличия Docker от виртуализации:

Но он имеет многие похожие фишки, как и у виртуализации:

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

1.2 Хранилища образов для Docker

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

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

1.3 Дополнительное чтение о Docker для новичков:

Как и для чего использовать Docker

Введение в Docker с нуля

Основные термины Docker

Как начать использовать Docker в своих проектах

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

1.4.1 Безопасность Docker-хоста и ядра

В скомпрометированной системе изоляция и прочие механизмы безопасности контейнеров уже вряд ли помогут. Кроме того, система спроектирована таким образом, что контейнеры используют ядро хоста. Поэтому в качетве хоста (Linux) должна быть пропачтенная, обновленная ОС без CVE и малвари.

1.4.2 Побег из Docker-контейнера

Баг «Выход за пределы контейнера» (container breakout) используется для обозначения ситуации, при которой какой-либо программе, запущенной внутри Docker-контейнера, удается преодолеть механизмы изоляции и получить дополнительные привилегии или доступ к конфиденциальной информации на хосте. Для предотвращения подобных прорывов используется уменьшение количества привилегий контейнера, выдаваемых ему по умолчанию. Например, демон Docker по умолчанию выполняется под рутом, однако существует возможность создать пользовательское пространство имен (user-level namespace) или снять потенциально опасные привилегии контейнера. Типичный пример это бага DirtyCow

Dirty COW (CVE-2016-5195) privilege escalation vulnerability in the Linux Kernel

1.4.3. Исчерпание пула вычислительных ресурсов или DDoS

В среднем контейнеры по сравнению с виртуальными машинами гораздо более многочисленны. Они легковесны, что позволяет запустить множество контейнеров даже на весьма скромном железе. Ошибки в программном обеспечении, недостатки проектирования и атаки хакеров могут приводить к Отказам в обслуживании (Denial of Service). Для их предотвращения необходимо должным образом настраивать лимиты ресурсов.

2. Общие рекомендации по безопасности Docker

2.1. Использование достоверных образов

Начнем с пожалуй самой и довольно банальной проблемы для Docker — достоверность образа. Поэтому используйте приватные или доверенные репозитории (trusted repositories) вроде доверенных репозиториев Docker Hub. Что выделяет Docker Hub из других репозиториев, помимо прочего, — это то, что образы всегда сканирует и просматривает Docker’s Security Scanning Service.

2.2. Юзаем сервис Docker Content Trust

Еще один инструмент, которым стоит воспользоваться — Docker Content Trust. Это новая функция, доступная в Docker Engine 1.8. Она позволяет верифицировать владельца образа. Таким образом этот сервис защищает вас от подделок, атак повторного воспроизведения и компрометирования ваших ключей. Очень сильно рекомендую ознакомиться с этой статьей и с официальной документацией.

2.3. Практика проверки Docker Bench Security

Еще один инструмент, которым я недавно пользовался — это Docker Bench Security. Это большая подборка рекомендаций по развертыванию контейнеров в продакшене. Инструмент основывается на рекомендациях из the CIS Docker 1.13 Benchmark, и применяется в 6 областях:

  • Конфигурация хоста.
  • Конфигурация демона Docker.
  • Файлы конфигурации демона Docker.
  • Образы контейнеров и build файлы.
  • Runtime контейнера.
  • Операции Docker security.

Чтобы установить этот скрипт првоерки, клонируйте репозиторий командой:

    git clone git@github.com:docker/docker-bench-security.git

Далее стартуем cd docker-bench-secutity и запустите такую команду:

    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

Таким образом, вы соберете контейнеры и запустите скрипт, который проверит безопасность хост машины и ее контейнеров.

Один из вариантов реализации тут на ГитХабе

2.4. Использование нативных опций безопасности на хостовых ОС

Вы так же можете воспользоваться штатными инструментами безопасности в ОС Linux, такими как AppArmorSELinuxgrsecurity и Seccomp.

AppArmor - это модуль безопасности ядра Linux, который позволяет системному администратору ограничить возможности программы с помощью индивидуальных профилей программ. Профили могут выдавать разрешения на такие действия как read, write и execute для файлов on matching paths. 

SELinux — Linux с улучшенной безопасностью) — реализация системы принудительного контроля доступа, которая может работать параллельно с классической избирательной системой контроля доступа.

Seccomp - ещеобъект безопасности компьютера в ядре Linux, позволяет перевести процесс в "безопасный" режим, из которого нельзя делать никаких системных вызовов, кроме exit(), sigreturn(), read() и write() уже открытых файловых дескрипторов.

2.5. Ограничения Docker Engine

Docker Engine - это API, который прослушивает входящие запросы и, в свою очередь, взаимодействует с базовым ядром хоста (ОС Linux) для выполнения своей работы. Docker Engine поддерживает связь на 3 различных сокетов: unixtcp, и fd.

Поведение докера по умолчанию на сегодняшний день является самым безопасным предположением, которое заключается в прослушивании unixсокета.

# recommended
$ dockerd -H "unix:///var/run/docker.sock"

2.6. Ограничение привилегий выполнения

По возможности запускайте контейнеры как пользователи без полномочий root'а

# recommended (runtime example)
$ docker run -d -u 1000 ubuntu sleep infinity
$ ps aux | grep sleep
1000 ... sleep infinity

Песочница во время выполнения контейнера добавляет еще больше уверенности в безопасности вокруг всего спейса контейнеров во время их выполнения. Для затравки можно юзать  gvisor.

Подумайте над этими вопросами:

  • Какое сетевое подключение требуется для вашего приложения?
  • Нужен ли ему прямой доступ к сокету?
  • Надо ли ему отправлять и получать UDP-запросы?

Для настройки ограничений используйте опции --cap-drop and --cap-add.

Предположим, вашему приложению не надо изменять возможности процесса или биндить привилегированные порты, но требуется загружать и выгружать модули ядра. Соответствующие возможности можно удалить и добавить так:

docker run \
--cap-drop SETPCAP \
--cap-drop NET_BIND_SERVICE \
--cap-add SYS_MODULE \
-ti /bin/sh

2.7 Ограничьте потребление доступных ресурсов

Для этого используйте следующие команды для Docker:

    -m / --memory: # Установить лимит памяти
    --memory-reservation: # Установить мягкий лимит памяти
    --kernel-memory: # Установить лимит памяти ядра
    --cpus: # Ограничьте количество CPU
    --device-read-bps: # Ограничьте пропускную способность чтения для конкретного устройства

Контрольные группы (cgroups) — это предоставляемый ядром Linux инструмент, который позволяет ограничивать доступ процессов и контейнеров к системным ресурсам. Некоторые лимиты можно контролировать из командной строки Docker:

# docker run -it --memory=2G --memory-swap=3G ubuntu bash

2.8. Мониторинг активности работы контейнеров

Мониторинг, обнаружение и оповещение об аномальном, подозрительном и вредоносном поведении контейнера - один из ключевых инструментов анализа и своевременного реагирования на инциденты. К примеру, тулза с открытым исходным кодом  Sysdig Falco

2.9 Палим CVE баги в контейнерах

Контейнеры используемые в Docker — это по сути некие изолированные черные ящики. Трабл в том,что контейнер может отлично работать, но при этом использовать уязвимое программное обеспечение. Эти уязвимости могут быть давно исправлены в апстриме, но не в вашем локальном образе! Опа! Если не предпринимать соответствующие меры, проблемы подобного рода могут долгое время оставаться незамеченными. Какое де есть решение!?

Многие реестры образов Docker предлагают услугу сканирования образов. Выберем, например, CoreOS Quay, в котором используется сканер безопасности образов Docker с открытым исходным кодом под названием Clair

CoreOS Quay

Ну и, где то на просторах сети, говорят есть аналогичные сервисы с подобным функционал, но соверешенно бесплатно! Не плохо да!? Однако, я такие не юзаю. Мой выбор это как скан ИТ-инфраструктуры OpenVAS либо другим секруным сканером по расписанию.

Всем хороших выходных и отличного настроения! Берегите себя, свои данные и своих близких. И по прежнему все свежие посты и новости читай в нашем @w2hack паблике!

Report Page