5000 слов о защите контейнеров

Графически взаимодействие компонентов Kubernetes представлено на рис. 1.

Получается, что Kubernetes есть не что иное, как информационная система, компоненты которой выполняют локальные задачи и взаимодействуют между собой через API, реализуя общую цель — управление запускаемыми в кластере приложениями-контейнерами.

Практически все компоненты Kubernetes, включая запущенные на нем приложения, могут быть использованы злоумышленником для начала/развития атаки. В качестве примера рассмотрим схему¹«Kubernetes Security», Liz Rice & Michael Hausenblas., представленную на рис. 2.

На ней приведены примеры векторов атак на кластер Kubernetes:

• [1] Доступ к серверу. Kubernetes можно установить как на физической, так и на виртуальной машине под управлением ОС семейства *nix. Доступ к серверу, наличие уязвимостей могут быть использованы злоумышленником для совершения атаки.
• [2] Доступ к kubernetes API (kube-apiserver). Злоумышленник может изменить существующую конфигурацию или создать сущность с повышенными привилегиями / минимальной конфигурацией безопасности, для того чтобы развить атаку.
• [3] Доступ к kubelet API. Используя kubelet (например, если доступна анонимная аутентификация), атакующий может запускать команды внутри контейнера для получения информации. Это даст ему возможность извлечь token, который впоследствии он сможет использовать для взаимодействия с kube-apiserver с целью манипуляции. Кроме того, kubelet обладает недекларированными возможностями, о которых тоже важно знать при моделировании угроз.
• [4] Escape через уязвимость, volume mount. Существует несколько возможностей реализации побега из контейнера на уровень node. Одним из самых опасных последствий может стать то, что права в контейнере и права на node будут идентичными, а при отсутствии корректных ИБ-настроек эти права будут привилегированными, в частности — root.
• [5] Доступ к etcd API. В etcd хранится полная конфигурация кластера. Получив к ней доступ, злоумышленник как минимум может начать собирать данные и планировать атаку.
• [6] Изменение/перехват трафика, инъекции (control plane). Влияние на трафик элементов control-plane способно привести к изменениям сущностей и созданию новых, что может потребоваться злоумышленнику для совершения атаки.
• [7] Изменение/перехват трафика, инъекции (application). Приложение, запущенное в контейнере, остается приложением: оно подвержено угрозам точно так же, как приложения, не упакованные в контейнеры (например, реализация RCE с последующим получением доступа к node).

Приведенные выше примеры не являются исчерпывающими. Более подробную информацию о техниках и тактиках, используемых злоумышленниками при реализации атак на Kubernetes, можно получить из материалов Microsoft, которая адаптировала структуру MITRE ATT&CK и создала матрицу атак Kubernetes («Threat Matrix for Kubernetes») с описанием 10 техник от Initial Access до Impact и 45 тактик, реализующих указанные техники (рис. 3).

Кроме того, можно обратиться непосредственно к материалам MITRE, выпустившей собственную матрицу («Containers Matrix») несколько позже, чем это сделала Microsoft. Также много полезной информации можно получить из отчетов по анализу угроз самого Kubernetes, реализуемых рабочей группой SIG-Security (Security Special Interest Group). Последний из них был выпущен в 2019 г., ведутся работы по подготовке нового отчета в 2021 г. 

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

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

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

Часть 2. Защита кластера, подход

В предыдущем разделе было продемонстрировано, что каждую сущность Kubernetes (включая запущенные на нем приложения) можно рассматривать как объект атаки или как средство для реализации атак. Поэтому при формировании стратегии защиты кластера можно выделить 2 ключевых блока:

• контроль информационной безопасности кластера (компоненты Kubernetes и Nodes кластера);
• контроль информационной безопасности запускаемых приложений (приложения, запущенные в виде контейнеров на кластере). 

Рассмотрим каждый блок более детально.

1. Контроль информационной безопасности кластера

Задача этапа — подготовить «безопасную» платформу для запуска приложений, которые, в свою очередь, подвержены угрозам. Кластер состоит из набора nodes и системных компонентов Kubernetes. Необходимо выстроить корректное сетевое взаимодействие между nodes, внедрить процесс управления уязвимостями, характерными для nodes, реализовать мониторинг инцидентов ИБ и т.д. Вообще говоря, задачи мало отличаются от задач «классической информационной безопасности ИТ-инфраструктуры».

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

• ограничение «прямого» доступа на nodes кластера;
• реализация защищенного сетевого взаимодействия между nodes кластера;
• отключение анонимной аутентификации для компонентов (например, kubelet);
• использование RBAC для корректного распределения возможностей пользователей и системных учетных записей в кластере;
• шифрование данных в etcd;
• включение и настройка audit policy, для того чтобы собирать информацию о происходящем на кластере для последующей аналитики;
• настройка resource quotas на потребление ресурсов (CPU, RAM) запущенными pod;
• …

Существует достаточно много рекомендаций по безопасной настройке кластеров Kubernetes (hardening guide), и нужно выбрать то, что лучше всего подходит для достижения поставленных целей. Есть даже hardening guide от Агентства национальной безопасности США. Большинство настроек выполняются с использованием встроенных возможностей Kubernetes с минимальным использованием дополнительных (наложенных) средств защиты. Примером использования дополнительных механизмов защиты при обеспечении безопасности кластера могут быть решения Service Mesh, которые в том числе позволяют реализовать mTLS и «расширенные» возможности по реализации межсетевого экранирования.

Мы привели несколько возможных примеров того, что можно реализовать. Полноценный же список нужно составлять только для конкретного окружения после моделирования угроз и изучения того, что может предоставить Kubernetes по информационной безопасности.

2. Контроль информационной безопасности запускаемых приложений

Информационную безопасность запускаемых приложений следует обеспечивать сразу на нескольких «уровнях абстракции»:

• уровень Image: статический анализ образов на наличие несоответствий требованиям ИБ; 
• уровень Container: все, что связано с запущенными контейнерами, — от запускаемых процессов до устанавливаемых сетевых соединений.

Мы определили логические уровни, на которых необходимы механизмы контроля. Но что это за механизмы? Что они должны делать? Чтобы ответить на этот вопрос, рассмотрим жизненный цикл контейнера и сопоставим его с потребностями информационной безопасности.

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

Кроме того, такой подход служит своего рода страховкой. Допустим, на этапах «Сбор требований» и «Создание образа» работы по ИБ не проводились, но в компании реализованы механизмы контроля запускаемых образов. Тогда на этапе «Запуск контейнера» произойдет ошибка, вызванная несоответствием требованиям по ИБ. Альтернативная ситуация такова: механизмы контроля запускаемых образов не реализованы, однако присутствует контроль сетевых соединений, устанавливаемых контейнерами. В этом случае можно блокировать попытку установления соединения, например, с C’n’C-сервером, инициируемую вредоносным ПО, попавшим в образ контейнера, даже с учетом того, что это ПО не было своевременно идентифицировано на этапе «Создание образа».

Лучше не рисковать и реализовать меры по ИБ на разных этапах жизненного контроля, для того чтобы на этапе n+1 в случае чего можно было отследить/проконтролировать то, что было пропущено на этапе n. Объединив уровни абстракции и ожидания от ИБ на различных этапах жизненного цикла контейнера, получим таблицу, описывающую общие функциональные требования к технологиям защиты сред контейнерной оркестрации с точки зрения приложений (табл. 1).

Таблица 1. Возможный перечень функциональных требований для защиты контейнеров (зеленым цветом указана применимость требования к образу (Image) или контейнеру (Container))

Помимо функциональных требований, важно помнить о блоке интеграционных. Например:

• интеграция с инфраструктурными сервисами (служба каталогов, электронная почта);
• интеграция с CI/CD-решениями для анализа уязвимостей и compliance-несоответствий в образах в процессе сборки, а также для анализа конфигурации сущности, запускаемой на Kubernetes в момент deploy, на предмет соответствия требованиям ИБ;
• интеграция с Registry для анализа уязвимостей и compliance-несоответствий в образах при их хранении;
• интеграция с SIEM-системами для передачи данных о событиях ИБ, инцидентах ИБ;
• интеграция с системами ИТ-мониторинга для оценки количества потребляемых ресурсов и нагрузки на кластер, создаваемой средствами защиты;
• интеграция с системами Secret Management для инъекции секретов в контейнеры в качестве файлов и/или переменных окружения;
• интеграция с системами Task/Issue Tracking для постановки задач по устранению дефектов, идентифицированных при сканировании образов контейнеров.

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

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

Как можно реализовать защиту? Какие способы возможны? Чтобы ответить на эти вопросы, обратимся к следующему разделу.

Часть 3. Средства защиты, разница между решениями Enterprise и Open Source

Способы защиты приложений, запущенных на кластере, можно разделить на несколько групп в соответствии со схемой, представленной на рис. 5.

Штатные механизмы Kubernetes

Kubernetes предоставляет функционал, который может быть использован для защиты приложений. Например:

• Network Policy. Позволяет контролировать входящий (Ingress) и исходящий (Egress) трафик, если смотреть со стороны контролируемой сущности. Поддержка функционала зависит от используемого Container Network Interface (CNI). Большинство решений (Cilium, Calico, Canal и т.д.) обладают необходимым функционалом, исключение составляет Flannel.
• Role based access control, RBAC. Возможно создание Roles и RoleBinding, которые описывают возможности (verb) сущности и объект, к которому применяются указанные возможности. Например, можно создать ServiceAccount, обладающий ограниченными возможностями применительно к Pod или иной сущности Kubernetes.
• Audit Policy. О ней мы уже упоминали в разделе, посвященном безопасности кластера. Audit Policy может быть использована для сбора событий о происходящем на кластере для последующего анализа. Например, можно идентифицировать попытки exec в pod.
• Security Context. Указывается в конфигурации Pod/Deployment/ReplicaSet и т.д. При помощи Security Context можно, например, ограничить возможность использования Linux Capabilities, управлять возможностью запуска привилегированных контейнеров, настроить применение Seccomp профиля для контейнера и т.д.
• Resource Quotas. Ограничение ресурсов (CPU, Memory), потребляемых контейнером, что может быть использовано для противодействия DoS-атакам

У штатного ИБ-функционала Kubernetes есть ограничения: он не позволяет контролировать run time — то есть все, что происходит внутри запущенного контейнера (например, запуск какого-то процесса, который не должен был быть запущен, попытку чтения/записи информации из файла и т.д.). Для идентификации подобных действий рекомендуется использовать наложенные средства.

Анализируя возможности Kubernetes, важно помнить, что проект продолжает развиваться, появляются новые функции, а некоторые, наоборот, переходят в статус «deprecated» (отзыв функционала). Показательный пример — PodSecurityPolicy (PSP): механизм получил статус deprecated в версии 1.21, а в версии 1.25 он будет устранен полностью. Однако в релизе 1.22 взамен был добавлен функционал PodSecurity Admission в статусе Aplha²Отключены по умолчанию, могут быть bugs, не рекомендуется к использованию в production., который должен выполнять схожий с PSP функционал, но при этом быть удобней в использовании.

Open Source

Инструментов Open Source для защиты кластера очень много. Поэтому рассмотрим решения, которые, согласно данным отчета «State of Kubernetes Security Report» от Red Hat, используются наиболее часто:

• KubeLinter. Позволяет проводить анализ YAML-манифестов Kubernetes на соответствие лучшим практикам, в том числе по информационной безопасности.
• Open Policy Agent. При помощи OPA можно создавать политики и применять их с использованием Admission Controller. Если упростить, то процесс выглядит следующим образом: мы написали политику, которая анализирует конфигурацию pod на предмет наличия «securityContext: privileged: true». Пытаемся запустить pod, обладающий указанной конфигурацией, после чего OPA анализирует запрос и отклоняет его из-за наличия недопустимой конфигурации. OPA — крайне мощный инструмент, который можно использовать для контроля запускаемых сущностей. Но есть нюанс: политики пишутся на специфичном языке (REGO), в котором предстоит разобраться.
• Kube-bench. Позволяет анализировать кластер на предмет соответствия конфигурации рекомендациям лучших практик (как правило, CIS Benchmark).
• Kube-hunter. Идентифицирует некорректные настройки в кластере.
• Terrascan. Выполняет статический анализ для идентификации недостатков в конфигурации при использовании подхода Infrastructure as Code.
• Falco. Это инструмент создания политик для идентификации инцидентов в запущенных контейнерах. Например, он позволяет идентифицировать запуск процессов внутри контейнера. Перед использованием необходимо подготовить Falco Rules — набор правил, используемых для идентификации событий ИБ, или воспользоваться готовыми наборами.
• Clair. Сканер уязвимостей в образах контейнеров.

Рассмотрим покрытие функциональных требований, указанных в табл. 1 (для упрощения сократим таблицу до уровня «Группа требований»), с использованием решений Open Source (табл. 2).

Таблица 2. Покрытие функциональных требований при помощи решений Open Source

Основные пользователи средства защиты:

• Разработка, ИТ- и ИБ-специалисты. Решения подобного рода называют еще «Observability». Их основная задача — предоставить максимум информации о том, что происходит (или происходило) на кластере в определенный момент времени. Такие данные могут быть использованы для нужд безопасности, поиска ошибок в конфигурациях deployment, для оптимизации производительности работы приложения и т.д. Примеры: Luntry, Sysdig.
• ИБ-специалисты. Решения, в большей степени сфокусированные на функционале по информационной безопасности, предоставляют множество возможностей по контролю запуска контейнеров, защите run time (в том числе в автоматическом режиме). Примеры: Aqua Enterprise, Prisma Cloud Compute Edition, Red Hat Advanced Security for Kubernetes (ex-StackRox).

Реализация защитных механизмов:

• Kubernetes-native. Решения, которые не используют интрузивных подходов и, грубо говоря, предоставляют удобный интерфейс взаимодействия с существующими ИБ-возможностями Kubernetes, помогают автоматизировать некоторые задачи (например, автоматическую генерацию Network Policy для приложения). Примеры: Luntry, Red Hat Advanced Security for Kubernetes (ex-StackRox).
• Иные. Решения, которые расширяют штатные возможности Kubernetes за счет собственных механизмов (например, позволяют контролировать запускаемые процессы в контейнерах). Примеры: Aqua Enterprise, Prisma Cloud Compute Edition, Sysdig.

Как может быть установлено средство защиты:

• Гибридная установка / локальная установка. Есть решения, модули защиты которых можно установить в периметре компании, а остальные компоненты (консоль управления, база данных и т.д.) будут размещены в облаке. Однако существует и альтернативный вариант — полностью локальная установка в периметре компании. Примеры: Aqua Enterprise, Prisma Cloud Compute Edition, Sysdig.
• Локальная установка. Решения, которые могут быть установлены только локально в периметре компании. Примеры: Luntry, Red Hat Advanced Security for Kubernetes (ex-StackRox).

Для того чтобы полноценно описать возможности решений (включая архитектурные особенности, интеграционные возможности, формат предоставления информации и т.д.), потребовалась бы отдельная статья. Тем более что, помимо общего функционала, у каждого из решений есть собственные особенности, которые делают его уникальным (например, vShield от Aqua Enterprise, WaaS от Prisma Cloud Compute Edition, «Машина времени» от Luntry и т.д.). Поэтому для общего понимания их возможностей рассмотрим функционал, имеющийся практически у всех представленных выше решений.

• Image Security:

- сканирование образов и nodes на наличие уязвимостей и compliance-несоответствий;

- идентификация вредоносного ПО в образах контейнеров;

- формирование политик, на основании которых принимается решение о запуске контейнеров (альтернатива/дополнение — использование Admission Controller для контроля запускаемых контейнеров);

- идентификация конфиденциальной информации (паролей, ssh-ключей).

• Container Security:

- контроль запуска процессов и системных вызовов внутри контейнера;

- контроль файловой системы: возможность указания объектов (файлов, папок), доступ к которым ограничивается;

- контроль сетевого взаимодействия за счет создания правил контроля исходящего и/или входящего трафика;

- профилирование контейнеров с последующим использованием созданной модели для реализации поведенческой аналитики и идентификации аномалий.

• Monitoring and Audit:

- сбор информации о событиях, создаваемых в среде контейнеризации (как для контейнеров, так и для nodes);

- возможность интеграции с системами мониторинга элементов ИТ-инфраструктуры;

- возможность интеграции с системами мониторинга и корреляции событий ИБ.

По аналогии с решениями Open Source, взглянем на покрытие функциональных требований, указанных в табл. 1 (для упрощения сократим таблицу до уровня «Группа требований») с использованием Enterprise-решений (табл. 3):

Таблица 3. Покрытие функциональных требований при помощи enterprise-решений