IT Partner

 Защитите контейнерные среды с помощью обновленной матрицы угроз для Kubernetes

 cloud security, modern security

Многое изменилось с момента публикации матрицы угроз в прошлом году:
• По мере того, как хакеры все больше нацеливались рабочие нагрузки Kubernetes, выявлялись новые угрозы.
• Мы с радостью наблюдали за тем, как матрица была принята сообществом в сфере безопасности и дополнена новыми методами.
• С развитием, Kubernetes по умолчанию становится более безопасным, и некоторые методы уже больше не актуальны.
Сегодня мы выпускаем вторую версию матрицы угроз для Kubernetes, которая учитывает все эти изменения. В обновленную матрицу добавлены новые методы, подобранные исследователями компании Microsoft, а также методы, предложенные сообществом. Мы также выступаем против некоторых методов, которые больше не подходят к новым версиям Kubernetes. В этой версии мы также добавляем новую тактику, взятую из MITER ATT & CK®: сбор.

Что устарело?

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

Открытая панель управления Kubernetes

За последнее время панель управления Kubernetes используется все реже. Кластеры с облачным управлением, такие как Microsoft AKS и Google GKE, отказались от этой службы и перешли на централизованный интерфейс на своих собственных порталах. Более того, в последних версиях панели инструментов Kubernetes требуются аутентификация. Вероятность того, что вы сможете найти открытые панели мониторинга, не требующие аутентификации, снижается. Следовательно, мы также удалили технику «Доступ к панели управления Kubernetes» в рамках тактики бокового перемещения. Более старые версии Kubernetes, включая новые кластеры, в которых панель управления установлена вручную, по-прежнему подвержены этой методике. Концепция этого старого метода была обобщена в новом: открытые чувствительные интерфейсы (описаны ниже).

Доступ к конечной точке румпеля

Начиная с версии 3, Helm не использует серверный компонент Tiller. Это серьезное улучшение безопасности Helm. В настоящее время Helm действует (по умолчанию) от имени учетных данных пользователя, указанных в файле kubeconfig. Пользователи более старых версий Helm по-прежнему подвержены этому методу.

Новые методы для матрицы угроз

1. Первоначальный доступ

Открытые чувствительные интерфейсы

Открытие доступа к конфиденциальному интерфейсу в Интернете создает угрозу безопасности. Некоторые популярные фреймворки не предназначены для доступа в Интернет и поэтому по умолчанию не требуют аутентификации. Таким образом, их открытость в интернете дает доступ без аутентификации к конфиденциальному интерфейсу, через который хакер может запускать код или развертывать контейнеры в кластере. Наглядные примеры интерфейсов, которые использовались в таких целях: Apache NiFi, Kubeflow, Argo Workflows, Weave Scope и панель управления Kubernetes.

2. Исполнение

h4 .Внедрение контейнера

Kubernetes Pod – это группа из одного или нескольких контейнеров с общим хранилищем и сетевыми ресурсами. Контейнер sidecar – это термин, который используется для описания дополнительного контейнера, находящегося рядом с основным контейнером. Например, прокси-серверы service-mesh работают как вспомогательные компоненты sidecar в модулях приложений. Хакеры могут запускать свой код и скрывать свою активность, внедряя дополнительный контейнер sidecar в допустимый модуль вместо запуска своего отдельного модуля в кластере.

3. Постоянство

Вредоносный контроллер допуска

Контроллер допуска – это компонент Kubernetes, который перехватывает и, в некоторых случаях, изменяет запросы к серверу Kubernetes API. Есть два типа контроллеров допуска: проверяющие и изменяющие контроллеры. Как следует из названия, изменяющий контроллер допуска может изменять перехваченный запрос и изменять его свойства. Kubernetes имеет встроенный универсальный контроллер доступа с именем MutatingAdmissionWebhook. Поведение этого контроллера доступа определяется веб-перехватчиком допуска, который пользователь развертывает в кластере. Злоумышленники могут использовать такие веб-перехватчики для обеспечения постоянства в кластере. Например, злоумышленники могут перехватить и изменить операции создания модуля в кластере и добавить свой вредоносный контейнер в каждый созданный модуль.

4. Доступ к учетным данным

Учетные данные для доступа к управляемой айдентити

Управляемые айдентити – это айдентити, которыми управляет облачный провайдер и которые могут назначаться облачным ресурсам, например, виртуальным машинам. Эти айдентити используются для аутентификации в облачных службах. Секрет айдентити полностью под управлением облачного провайдера, поэтому нет необходимости управлять учетными данными. Приложения могут получать токен айдентити, обращаясь к службе метаданных экземпляра (IMDS). Хакеры, получившие доступ к модулю Kubernetes, могут использовать свой доступ к конечной точке IMDS, чтобы заполучить токен управляемой айдетити. С помощью токена злоумышленники могут получить доступ к облачным ресурсам.

Вредоносный контроллер допуска

Помимо обеспечения постоянства, вредоносный контроллер допуска может использоваться для доступа к учетным данным. Один из встроенных контроллеров доступа в Kubernetes – это ValidatingAdmissionWebhook. Как и MutatingAdmissionWebhook, этот контроллер доступа –универсальный. Его поведение определяет веб-перехватчик допуска, развернутый в кластере. Хакеры могут использовать этот веб-перехватчик для перехвата запросов к серверу API, записи секретов и другой конфиденциальной информации.

5. Боковое движение

Отравление CoreDNS

CoreDNS – это модульный сервер системы доменных имен (DNS), написанный на Go и поддерживаемый Cloud Native Computing Foundation (CNCF). CoreDNS – это основная служба DNS, которая используется в Kubernetes. Конфигурацию CoreDNS можно изменить с помощью файла с именем corefile. В Kubernetes этот файл хранится в объекте ConfigMap, расположенном в пространстве имен kube-system. Если у злоумышленников есть права на изменение ConfigMap, например, с помощью учетной записи службы контейнера, они могут изменить поведение DNS кластера, отравить его и использовать сетевые идентификаторы других служб.

Отравление ARP и подмена IP

Kubernetes имеет множество сетевых плагинов (сетевых интерфейсов контейнера или CNI), которые можно использовать в кластере. Kubenet – это основной и во многих случаях сетевой плагин по умолчанию. В этой конфигурации на каждом узле (cbr0) создается мост, к которому различные поды подключаются с помощью пар veth. Тот факт, что межподовой трафик проходит через мост, компонент уровня 2, означает, что возможно выполнение ARP-отравления в кластере. Следовательно, если хакеры получают доступ к модулю в кластере, они могут выполнить отравление ARP и подделать трафик других модулей. Используя этот метод, злоумышленники могут выполнить несколько атак на сетевом уровне, способствующих боковым перемещениям, Например, подмену DNS или кражу облачных идентификаторов других модулей (CVE-2021-1677).

6. Сбор

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

Образы из частного реестра

Образы, запущенные в кластере, могут храниться в частном реестре. Для получения этих образов у движка среды выполнения контейнера (например, Docker или containerd) должны быть действительные учетные данные для этих реестров. Если реестр размещен у облачного провайдера, в таких сервисах, как реестр контейнеров Azure (ACR) или реестр эластичных контейнеров Amazon (ECR), учетные данные облака используются для аутентификации в реестре. Если злоумышленники получают доступ к кластеру, в некоторых случаях они могут получить доступ к частному реестру и получить его образы. Например, злоумышленники могут использовать маркер управляемой идентификации, как описано в методике «Доступ к учетным данным управляемой идентификации». Точно так же в EKS злоумышленники могут использовать политику AmazonEC2ContainerRegistryReadOnly, которая по умолчанию привязана к роли IAM узла.

Защитите свою контейнерную среду

Понимание всей поверхности атак контейнерной среды – это первый шаг в создании решений для ее безопасности. Пересмотренная матрица угроз для Kubernetes поможет организациям выявить существующие пробелы в их защите от различных кибер-атак, нацеленных на Kubernetes.
Мы рекомендуем вам доверить защиту контейнерной среды службе Azure Defender уже сегодня. Узнайте больше о поддержке безопасности контейнеров со стороны Azure Defender.