Defender для архитектуры контейнеров

Завершено

Defender для контейнеров разработан по-разному для каждой среды Kubernetes независимо от того, работают ли они в:

• Служба Azure Kubernetes (AKS). Это управляемая служба Майкрософт для разработки и развертывания контейнерных приложений, а также управления ими.
  
• Служба Amazon Elastic Kubernetes (EKS) в подключенной учетной записи Amazon Web Services (AWS) — это управляемая служба Amazon для запуска Kubernetes на AWS без установки, обработки и обслуживания собственного уровня управления и узлов Kubernetes.
  
• Google Kubernetes Engine (GKE) в подключенном проекте Google Cloud Platform (GCP) — это управляемая среда Google для развертывания, администрирования и масштабирования приложений с помощью инфраструктуры GCP.
  
• Неуправляемое распределение Kubernetes (с использованием Kubernetes с поддержкой Azure Arc) — это сертифицированные кластеры Kubernetes Cloud Native Computing Foundation (CNCF), которые размещены в локальной среде или в IaaS.

Чтобы защитить контейнеры Kubernetes, Defender для контейнеров получает и анализирует:

• журналы аудита и события безопасности с сервера API;
• сведения о конфигурации кластера с уровня управления;
• конфигурация рабочей нагрузки из Политики Azure;
• сигналы и события безопасности с уровня узла.

Архитектура для каждой среды Kubernetes

Схема архитектуры Defender для облака и кластеров AKS

Если Defender для облака защищает кластер, размещенный в Служба Azure Kubernetes, сбор данных журнала аудита без агента и автоматически собирается через инфраструктуру Azure без дополнительных затрат или рекомендаций по настройке. Это необходимые компоненты для получения полной защиты, предоставляемой Microsoft Defender для контейнеров:

• Агент Defender: DaemonSet, развернутый на каждом узле, собирает сигналы от узлов с помощью технологии *Extended Berkeley Packet Filter (eBPF) и обеспечивает защиту среды выполнения. Агент регистрируется в рабочей области Log Analytics и используется в качестве конвейера данных. Но данные журнала аудита не хранятся в рабочей области Log Analytics. Агент Defender развертывается в качестве профиля безопасности AKS.

  • *eBPF Background and Information*: Расширенный фильтр пакетов Berkeley (eBPF) — это мощная и универсальная платформа в ядре Linux для программного анализа и фильтрации сетевых пакетов, а также выполнения различных других задач на уровне системы. Первоначально на основе фильтра пакетов Berkeley (BPF), представленного в 1990-х годах, eBPF расширяет свои возможности, позволяя определяемым пользователем программам выполняться в ядре, обеспечивая динамическую и эффективную обработку пакетов, не требуя изменений в самом ядре.
  • Программы eBPF записываются в ограниченном подмножестве C и загружаются в ядро, где они выполняются в защищенной и изолированной среде. Это позволяет выполнять широкий спектр сетевых задач непосредственно в ядре, таких как фильтрация пакетов, мониторинг трафика, принудительное применение безопасности и даже анализ пользовательских протоколов.
  • Одним из ключевых преимуществ eBPF является его универсальность и производительность. Выполняя в ядре, программы eBPF могут обращаться к сетевым пакетам напрямую и управлять ими напрямую, что значительно снижает затраты по сравнению с традиционными методами обработки пакетов пространства пользователя. Кроме того, программы eBPF можно динамически загружать и подключать к различным перехватчикам в ядре, что позволяет реагировать в режиме реального времени и адаптироваться к изменению сетевых условий.
  • EBPF становится все более популярным в современных сетевых и безопасности приложениях из-за его гибкости и эффективности. Она широко используется в средствах и платформах для мониторинга сети, обнаружения вторжений, анализа трафика и настройки производительности. Кроме того, его возможности выходят за рамки сети в других областях наблюдаемости системы и контроля, что делает его основным стандартным блоком для широкого спектра приложений и служб на основе Linux.

• Политика Azure для Kubernetes: модуль pod, расширяющий шлюз с открытым исходным кодом версии 3 и регистрирующийся в качестве веб-перехватчика в Kubernetes, что позволяет применять принудительное применение в масштабе и защищать кластеры в централизованном и согласованном режиме. Политика Azure для pod Kubernetes развертывается как надстройка AKS. Он установлен только на одном узле в кластере.

Сведения о компоненте агента Defender

Имя pod	Пространство имен	Вид	Краткое описание	Capabilities	Ограничения ресурсов	Обязательный исходящий трафик
microsoft-defender-collector-ds-*	kube-system	DaemonSet	Набор контейнеров, которые фокусируются на сборе данных инвентаризации и событий безопасности из среды Kubernetes.	SYS_ADMIN, SYS_RESOURCE, SYS_PTRACE	память: 296Mi ЦП: 360 млн	No
microsoft-defender-collector-misc-*	kube-system	Развертывание	Набор контейнеров, которые фокусируются на сборе из среды Kubernetes данных инвентаризации и событий безопасности, которые не ограничены определенным узлом.	Н/П	memory: 64Mi cpu: 60m	No
microsoft-defender-publisher-ds-*	kube-system	DaemonSet	Опубликуйте собранные данные в серверной службе Microsoft Defender для контейнеров, в которой будут обрабатываться и анализироваться данные.	Н/П	memory: 200Mi cpu: 60m	Https 443

Как работает обнаружение без агента для Kubernetes в Azure?

Процесс обнаружения основан на моментальных снимках, сделанных через интервалы:

Если включить обнаружение без агента для расширения Kubernetes, происходит следующий процесс:

• Создание.

  • Если расширение включено из CSPM Defender, Defender для облака создает удостоверение в клиентских средах с именем CloudPosture/securityOperator/DefenderCSPMSecurityOperator.
    
  • Если расширение включено из Defender для контейнеров, Defender для облака создает удостоверение в клиентских средах с именем CloudPosture/securityOperator/DefenderForContainersSecurityOperator.
  • Назначение: Defender для облака назначает встроенную роль с именем "Оператор без агента Kubernetes" для этого удостоверения в области подписки. Роль содержит следующие разрешения:
  • Чтение AKS (Microsoft.ContainerService/managedClusters/read)
    
  • Доверенный доступ AKS со следующими разрешениями:
  • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/write
  • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/read
  • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/delete

• Обнаружение. Использование назначаемого системой удостоверения Defender для облака выполняет обнаружение кластеров AKS в вашей среде с помощью вызовов API к серверу API AKS.

• Привязка. При обнаружении кластера AKS Defender для облака выполняет операцию привязки AKS путем создания clusterRoleBinding между созданным удостоверением и кластером Kubernetes ClusterRole aks:trustedaccessrole:defender-containers:microsoft-defender-operator. ClusterRole отображается через API и предоставляет Defender для облака разрешение на чтение плоскости данных внутри кластера.

Получение безопасного доступа к ресурсам Azure в Служба Azure Kubernetes с помощью доверенного доступа (предварительная версия)

Многие службы Azure, которые интегрируются с Служба Azure Kubernetes (AKS), нуждаются в доступе к серверу API Kubernetes. Чтобы избежать предоставления доступа администратора этих служб или предоставления доступа к кластерам AKS для доступа к сети, можно использовать функцию доверенного доступа AKS.

Эта функция предоставляет службам безопасный доступ к AKS и Kubernetes с помощью внутренней части Azure, не требуя частной конечной точки. Вместо того чтобы полагаться на удостоверения, имеющие разрешения Microsoft Entra, эта функция может использовать управляемое удостоверение, назначаемое системой, для проверки подлинности с помощью управляемых служб и приложений, которые вы хотите использовать с кластерами AKS.

Внимание

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

Примечание.

Api доверенного доступа общедоступен. Мы предоставляем общедоступную поддержку Azure CLI, но она по-прежнему находится в предварительной версии и требует использования расширения aks-preview.

Общие сведения о функции доверенного доступа

Доверенный доступ обращается к следующим сценариям:

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

Доверенный доступ можно использовать для предоставления явного согласия на управляемое удостоверение, назначаемое системой, для доступа к кластерам AKS с помощью ресурса Azure, называемого привязкой роли. Ресурсы Azure получают доступ к кластерам AKS через региональный шлюз AKS с помощью проверки подлинности управляемого удостоверения, назначаемого системой. Соответствующие разрешения Kubernetes назначаются через ресурс Azure, называемый ролью. С помощью доверенного доступа можно получить доступ к кластерам AKS с различными конфигурациями, включая не только частные кластеры, кластеры с локальными учетными записями, кластеры Microsoft Entra и авторизованные кластеры диапазонов IP-адресов.

Необходимые компоненты

• Учетная запись Azure с активной подпиской. Создайте учетную запись бесплатно .

• Типы ресурсов, поддерживающие управляемое удостоверение, назначаемое системой.

  • Если вы используете Azure CLI, требуется расширение aks-preview версии 0.5.74 или более поздней.

• Чтобы узнать, какие роли следует использовать в разных сценариях, см. в следующих статьях:

  • Машинное обучение Azure доступ к кластерам AKS с особыми конфигурациями
  • Что такое резервное копирование в службе Azure Kubernetes?
  • Включение состояния контейнера без агента

Схема архитектуры Defender для облака и кластеров Kubernetes с поддержкой Arc

Ниже описаны компоненты, необходимые для получения полной защиты, предлагаемой Microsoft Defender для контейнеров:

• Kubernetes с поддержкой Azure Arc — Kubernetes с поддержкой Azure Arc — решение на основе агента, установленное на одном узле в кластере, которое подключает кластеры к Defender для облака. Defender для облака затем сможет развернуть следующие два агента в виде расширений Arc:
• Агент Defender: DaemonSet, развернутый на каждом узле, собирает сигналы узла с помощью технологии eBPF и журналов аудита Kubernetes, чтобы обеспечить защиту среды выполнения. Агент регистрируется в рабочей области Log Analytics и используется в качестве конвейера данных. Но данные журнала аудита не хранятся в рабочей области Log Analytics. Агент Defender развертывается как расширение Kubernetes с поддержкой Arc.
• Политика Azure для Kubernetes: модуль pod, расширяющий шлюз с открытым исходным кодом версии 3 и регистрирующийся в качестве веб-перехватчика в Kubernetes, что позволяет применять принудительное применение в масштабе и защищать кластеры в централизованном и согласованном режиме. Политика Azure для pod Kubernetes развертывается как расширение Kubernetes с поддержкой Arc. Он установлен только на одном узле в кластере. Дополнительные сведения см. в статье "Защита рабочих нагрузок Kubernetes" и "Общие сведения о Политика Azure для кластеров Kubernetes".
  

Схема архитектуры Defender для облака и кластеров EKS

Если Defender для облака защищает кластер, размещенный в службе Elastic Kubernetes, сбор данных журнала аудита не является агентом. Это необходимые компоненты для получения полной защиты, предоставляемой Microsoft Defender для контейнеров:

• Журналы аудита Kubernetes. CloudWatch учетной записи AWS обеспечивает запись и сбор данных журнала аудита с помощью безагентного сборщика и отправляет собранные сведения в серверную часть Microsoft Defender для облака для дальнейшего анализа.
• Kubernetes с поддержкой Azure Arc — Kubernetes с поддержкой Azure Arc — решение на основе агента, установленное на одном узле в кластере, которое подключает кластеры к Defender для облака. Defender для облака затем сможет развернуть следующие два агента в виде расширений Arc:
• Агент Defender: DaemonSet, развернутый на каждом узле, собирает сигналы от узлов с помощью технологии eBPF и обеспечивает защиту среды выполнения. Агент регистрируется в рабочей области Log Analytics и используется в качестве конвейера данных. Но данные журнала аудита не хранятся в рабочей области Log Analytics. Агент Defender развертывается как расширение Kubernetes с поддержкой Arc.
• Политика Azure для Kubernetes: модуль pod, расширяющий шлюз с открытым исходным кодом версии 3 и регистрирующийся в качестве веб-перехватчика в Kubernetes, что позволяет применять принудительное применение в масштабе и защищать кластеры в централизованном и согласованном режиме. Политика Azure для pod Kubernetes развертывается как расширение Kubernetes с поддержкой Arc. Он установлен только на одном узле в кластере.

Как работает обнаружение без агента для Kubernetes в AWS?

Процесс обнаружения основан на моментальных снимках, сделанных через интервалы:

Если включить обнаружение без агента для расширения Kubernetes, происходит следующий процесс:

• Создание:

  • Необходимо добавить Defender для облака роль MDCContainersAgentlessDiscoveryK8sRole в конфигурацию aws-auth кластера EKS. Имя можно настроить.
    

• Назначение: Defender для облака назначает роль MDCContainersAgentlessDiscoveryK8sRole следующими разрешениями:

  • eks:UpdateClusterConfig
    
  • eks:DescribeCluster

• Обнаружение. Использование назначенного системой удостоверения Defender для облака выполняет обнаружение кластеров EKS в вашей среде с помощью вызовов API к серверу API EKS.

Схема архитектуры Defender для облака и кластеров GKE

Если Defender для облака защищает кластер, размещенный в подсистеме Google Kubernetes, сбор данных журнала аудита не является агентом. Это необходимые компоненты для получения полной защиты, предоставляемой Microsoft Defender для контейнеров:

• Журналы аудита Kubernetes.GCP Cloud Logging позволяет собирать данные журналов аудита с помощью сборщика без агента и отправлять собранные сведения в защитник Майкрософт для облачной серверной части для дальнейшего анализа.
• Kubernetes с поддержкой Azure Arc — Kubernetes с поддержкой Azure Arc — решение на основе агента, установленное на одном узле в кластере, которое подключает кластеры к Defender для облака. Defender для облака затем сможет развернуть следующие два агента в виде расширений Arc:
• Агент Defender: DaemonSet, развернутый на каждом узле, собирает сигналы от узлов с помощью технологии eBPF и обеспечивает защиту среды выполнения. Агент регистрируется в рабочей области Log Analytics и используется в качестве конвейера данных. Но данные журнала аудита не хранятся в рабочей области Log Analytics. Агент Defender развертывается как расширение Kubernetes с поддержкой Arc.
• Политика Azure для Kubernetes: модуль pod, расширяющий шлюз с открытым исходным кодом версии 3 и регистрирующийся в качестве веб-перехватчика в Kubernetes, что позволяет применять принудительное применение в масштабе и защищать кластеры в централизованном и согласованном режиме. Политика Azure для pod Kubernetes развертывается как расширение Kubernetes с поддержкой Arc. Его необходимо установить только на одном узле в кластере.

Как работает обнаружение без агента для Kubernetes в GCP?

Процесс обнаружения основан на моментальных снимках, сделанных через интервалы:

Если включить обнаружение без агента для расширения Kubernetes, происходит следующий процесс:

• Создание:

  • Создается оператор mdc-containers-k8s-operator. Имя можно настроить.

• Назначение: Defender для облака присоединяет следующие роли к учетной записи службы mdc-containers-k8s-operator:

  • Пользовательская роль MDCGkeClusterWriteRole, которая имеет разрешение container.clusters.update
  • Встроенный контейнер ролей.viewer

• Обнаружение. Использование назначенного системой удостоверения Defender для облака выполняет обнаружение кластеров GKE в вашей среде с помощью вызовов API к серверу API GKE.