Распространение контейнеризации: эффект Докера (часть 4)

• Распространение контейнеризации: эффект Докера (часть 2)
• Распространение контейнеризации: эффект Докера (часть 5)

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

Теперь, в части 4, мы продолжим с того места, на котором остановились в части 3.

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

Однако, поскольку контейнеры не запускают отдельные экземпляры операционной системы, как это делают виртуальные машины, а совместно используют один и тот же хост, сегрегация и изоляция не столь полны, а запуск демона Docker с правами root открывает брешь в безопасности. Таким образом, чтобы внедрить безопасность корпоративного уровня в среде Dockerized, вам необходимо знать и применять передовые методы обеспечения безопасности, а также использовать инструменты и механизмы безопасности помимо конфигураций по умолчанию.

SELinux

SELinux — это сокращенное название Security-Enhanced Linux. Один из способов защитить вашу среду Docker — использовать модуль безопасности SELinux. Для тех, кто не знаком с модулями безопасности Linux (LSM), это инфраструктура или интерфейс под лицензией GNU для загрузки кода, расширяющего функциональность ядра операционной системы. Для тех из нас, кто вырос в ориентированном на Windows мире, эти загружаемые модули ядра (LKM) похожи на драйверы режима ядра в Windows.

Функция SELinux заключается в том, чтобы позволить вам применять политики безопасности для реализации контроля доступа. Его архитектура фактически была разработана АНБ (Агентством национальной безопасности), в частности их Исследовательской группой доверенных систем, на основе архитектуры обязательного контроля доступа (MAC) под названием Flask. Затем он был внедрен в Linux и перенесен на FreeBSD и Solaris. SELinux также является частью модели безопасности Android.

Механизмы безопасности предназначены для разделения данных в соответствии с требованиями конфиденциальности и целостности и помогают ограничить (но не полностью предотвратить) ущерб от вредоносных приложений и несанкционированного доступа. Управление доступом может работать по одному из двух принципов: разрешить все по умолчанию и конкретно выбрать, что запрещать (занесение в черный список), или запретить все по умолчанию и конкретно выбрать, что разрешить (внесение в белый список).

Политики — это наборы правил, которые разрешают или запрещают операции. У вас может быть установлено более одной политики, но только одна из них может быть активной и использоваться одновременно. АНБ разработало SELinux для работы по принципу «Запретить все». Если что-то явно не разрешено, то это запрещено. Однако это работает не во всех сценариях, поэтому в дополнение к двум принципам и двум режимам есть еще две политики по умолчанию:

• Строгая политика
• Целевая политика

Строгая политика — это политика, в которой все запрещено по умолчанию. Правила политики определяют, что разрешено. Хотя это наиболее безопасный вариант, и это политика, предоставляемая АНБ, как вы понимаете, это может вызвать проблемы, когда пользователи не смогут получить доступ к тому, что им нужно для выполнения своей работы. Это основано на «принципе наименьших привилегий». Целенаправленная политика противоположна. Все разрешено по умолчанию, затем вы создаете запрещающие правила для управления доступом. Очевидно, что это менее безопасно.

Также важно отметить, что SELinux можно настроить для работы в одном из двух разных режимов. В «разрешающем» режиме он фактически запрещает выполнение неразрешенных операций; вместо этого он просто регистрирует выполнение этих операций. Другими словами, он используется для аудита доступа, который будет запрещен. Другой режим — принудительный режим, и, как следует из его названия, в этом режиме политики принудительно применяются, а запросы на доступ фактически отклоняются, а также регистрируются.

SELinux использует концепцию доменов безопасности, чтобы определить, на какие процессы влияет конкретная политика. Виртуальная машина — это процесс. Домен — это то, что определяет, какие действия может выполнять процесс. Роли пользователей определяют, какие домены могут использоваться пользователем. Администраторы Windows могут думать об этом как о том, как группы безопасности используются для предоставления прав доступа в Windows. Однако домены безопасности Linux применяются к процессам, к таким объектам, как файлы, каталоги и устройства. Они назначаются типу, а не домену.

Docker поддерживает SELinux двумя способами, один из которых основан на правилах для типа процесса, а другой называется MCS или разделением безопасности нескольких категорий (или svirt), где полю уровня метки SELinux каждого контейнера присваивается уникальное значение. Первый предназначен для защиты хоста, а второй — для защиты контейнеров друг от друга. SVirt (Secure Virtualization) интегрирует безопасность обязательного контроля доступа с виртуализацией Linux, чтобы изолировать виртуальные машины, работающие на одном и том же ядре хоста.

AppArmor

Модуль безопасности Application Armor (AppArmor) похож по функциям и назначению на SELinux, но реализован иначе. AppArmor включен в ядро Linux (версии 2.6.36 и выше), но сначала он появился в SUSE Linux. Вначале он назывался SubDomain, затем Novell переименовал его в AppArmor в 2005 году. Администраторам с ним было проще работать, чем с SELinux, и он может работать с любой файловой системой, тогда как SELinux не работает с NFS- смонтированные файлы, потому что нет поддержки меток безопасности.

AppArmor работает, позволяя вам использовать профили для каждого приложения, которые контролируют определенные возможности, которые будут разрешены. Возможности Linux (на основе возможностей POSIX) являются подмножеством привилегий root. Возможности называются «привилегиями» в некоторых других операционных системах UNIX. Всякий раз, когда процесс пытается выполнить операцию, требующую привилегий root, операционная система проверяет, назначена ли процессу эта возможность. В противном случае операция не будет разрешена.

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

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

AppArmor имеет два режима, которые работают так же, как и в SELinux, но в дополнение к «режиму принудительного применения» AppArmor имеет «режим жалоб», который регистрирует, когда приложения выполняют действия, ограниченные профилем, как это делает «разрешающий» режим SELinux.

Grsec и PaX

Еще одним механизмом безопасности Linux, который может принести пользу вашим контейнерам Docker, является Grsecurity (Grsec), представляющий собой набор исправлений, предназначенных для повышения безопасности ядра Linux. Он существует уже пятнадцать лет, и его можно использовать для реализации управления доступом на основе ролей, но он идет дальше, чем модули безопасности Linux, которые мы обсуждали до сих пор, и обеспечивает больше, чем просто контроль доступа.

Grsec также защищает от уязвимостей, связанных с повреждением памяти, которые являются одним из наиболее распространенных (и часто используемых) типов уязвимостей, и помогает предотвратить атаки нулевого дня — те, которые используют уязвимости, которые еще не были исправлены поставщиком программного обеспечения. Его можно использовать с любым дистрибутивом Linux.

PaX поставляется с Grsec, но был разработан другими разработчиками. Запуск ядра Linux с Grsec и PaX защитит ваш хост-компьютер Docker от атак и эксплойтов. Это обеспечит такие функции безопасности, как рандомизация расположения адресного пространства (ASLR), которая является важным средством защиты от атак переполнения буфера и других атак, зависящих от предсказуемой адресации. Фактически, проект PaX породил термин «ASLR», который теперь является функцией безопасности в других операционных системах, таких как Windows и iOS.

Резюме

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

• Распространение контейнеризации: эффект Докера (часть 2)
• Распространение контейнеризации: эффект Докера (часть 5)