Defender for Containers 体系结构

  • 10 分钟

Defender for Containers 的设计因运行它们的每个 Kubernetes 环境而异：

  • Azure Kubernetes 服务 (AKS)：Microsoft 的托管服务，用于开发、部署和管理容器化应用程序。
  • 在连接的 Amazon Web Services (AWS) 帐户中的 Amazon Elastic Kubernetes Service (EKS) - Amazon 的托管服务，用于在 AWS 上运行 Kubernetes，而无需安装、操作和维护自己的 Kubernetes 控制平面或节点。
  • 在已连接的 Google Cloud Platform (GCP) 项目中的 Google Kubernetes Engine (GKE) - Google 的托管环境，通过 GCP 基础结构部署、管理和缩放应用程序。
  • 非托管 Kubernetes 分发（使用启用了 Azure Arc 的 Kubernetes）- 托管在本地或 IaaS 上的经云原生计算基础 (CNCF) 认证的 Kubernetes 群集。

为了保护 Kubernetes 容器，Defender for Containers 接收并分析：

  • 来自 API 服务器的审核日志和安全事件
  • 来自控制平面的群集配置信息
  • Azure Policy 中的工作负载配置
  • 来自节点级别的安全信号和事件

用于每个 Kubernetes 环境的体系结构

Defender for Cloud 和 AKS 群集的体系结构示意图

当 Defender for Cloud 保护 Azure Kubernetes 服务中托管的群集时，审核日志数据的收集以无代理的方式进行，并通过 Azure 基础结构自动收集，无额外成本或配置注意事项。 以下是获得 Microsoft Defender for Containers 提供的完整保护所需的组件：

  • Defender 代理：在每个节点上部署的 DaemonSet 使用*扩展伯克利数据包筛选器 (eBPF) 技术*从主机收集信号，并提供运行时保护。 该代理向 Log Analytics 工作区注册，并用作数据管道。 但是，审核日志数据不会存储在 Log Analytics 工作区中。 Defender 代理可部署为 AKS 安全配置文件。

    • *eBPF 背景和信息*：扩展伯克利数据包筛选器 (eBPF) 是 Linux 内核中的一个强大且通用的框架，用于以编程方式分析和筛选网络数据包，以及执行各种其他系统级任务。 eBPF 最初基于上世纪 90 年代引入的伯克利数据包筛选器 (BPF)，通过允许用户定义的程序在内核中运行来扩展其功能，从而实现动态高效的数据包处理，而无需修改内核本身。
    • eBPF 程序用 C 语言限定子集编写，并加载到内核中，在安全的沙盒环境中执行。 这样就可以在内核中直接执行各种与网络相关的任务，例如数据包筛选、流量监视、安全强制，甚至进行自定义协议分析。
    • eBPF 的主要优势之一是其多功能性和性能。 通过在内核中执行，eBPF 程序可以直接访问和操作网络数据包，与传统的用户空间数据包处理方法相比，这大大减少了开销。 此外，eBPF 程序可以动态加载和附加到内核中的各种挂钩，从而实时响应和适应不断变化的网络环境。
    • eBPF 灵活且高效，在现代网络和安全应用程序中越来越受欢迎。 它在网络监视、入侵检测、流量分析和性能优化工具和框架中广泛使用。 此外，其功能不局限于网络，还扩展到系统可观测性和控制的其他领域，成为各种基于 Linux 的应用程序和服务的基本组成部分。

  • 适用于 Kubernetes 的 Azure Policy：扩展开放源代码 Gatekeeper v3 的 Pod，可注册为 Kubernetes 准入控制的 Webhook，支持你以集中且一致的方式在群集上应用大规模强制性操作和安全措施。 适用于 Kubernetes pod 的 Azure Policy 可部署为 AKS 加载项。 它仅安装在群集中的一个节点上。

示意图显示 Azure Kubernetes 服务体系结构的示例。

Defender 代理组件详细信息

Pod 名称 命名空间 Kind 简短描述 功能 资源限制 需要出口
microsoft-defender-collector-ds-* kube-system DaemonSet 一组容器，重点介绍从 Kubernetes 环境收集清单和安全事件。 SYS_ADMIN、
SYS_RESOURCE、
SYS_PTRACE		 内存：296Mi

CPU：360m		 否
microsoft-defender-collector-misc-* kube-system 部署 一组容器，重点介绍从 Kubernetes 环境收集不受特定节点限制的清单和安全事件。 不适用 内存：64Mi

cpu：60m		 否
microsoft-defender-publisher-ds-* kube-system DaemonSet 将收集的数据发布到 Microsoft Defender for Containers 后端服务，将在该服务中处理和分析数据。 不适用 内存：200Mi

cpu：60m		 Https 443

Azure 中 Kubernetes 的无代理发现是如何工作的？

发现过程基于每隔一段时间拍摄的快照：

关系图显示 kubernetes 权限体系结构的示例。 为 Kubernetes 扩展启用无代理发现时，会发生以下过程：

  • 创建：

    • 如果从 Defender CSPM 启用扩展，Defender for Cloud 会在客户环境中创建一个名为 CloudPosture/securityOperator/DefenderCSPMSecurityOperator 的标识。
    • 如果从 Defender for Containers 启用扩展，Defender for Cloud 会在客户环境中创建一个名为 CloudPosture/securityOperator/DefenderForContainersSecurityOperator 的标识。
    • 分配：Defender for Cloud 在订阅范围将一个名为“Kubernetes 无代理操作员”的内置角色分配给该标识。 该角色包含以下权限：
    • AKS 读取 (Microsoft.ContainerService/managedClusters/read)
    • 具有以下权限的 AKS 受信任访问：
    • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/write
    • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/read
    • Microsoft.ContainerService/managedClusters/trustedAccessRoleBindings/delete

  • 发现：Defender for Cloud 使用系统分配的标识，通过对 AKS 的 API 服务器执行 API 调用来发现环境中的 AKS 群集。

  • 绑定：发现 AKS 群集后，Defender for Cloud 通过在创建的标识与 Kubernetes ClusterRole aks:trustedaccessrole:defender-containers:microsoft-defender-operator 之间创建 ClusterRoleBinding 来执行 AKS 绑定操作。 该 ClusterRole 通过 API 可见，并授予群集中的 Defender for Cloud 数据平面读取权限。

使用受信任的访问（预览版）获取 Azure Kubernetes 服务中 Azure 资源的安全访问

许多与 Azure Kubernetes 服务 (AKS) 集成的 Azure 服务都需要访问 Kubernetes API 服务器。 若要避免授予这些服务管理员访问权限或将 AKS 群集公开供网络访问，可以使用 AKS 受信任访问功能。

此功能允许服务使用 Azure 后端安全地访问 AKS 和 Kubernetes，而无需专用终结点。 此功能可以使用系统分配的托管标识对要用于 AKS 群集的托管服务和应用程序进行身份验证，而不是依赖于具有 Microsoft Entra 权限的标识。

重要

AKS 预览功能是可选择启用的自助功能。 预览功能是“按现状”和“按可用”提供的，不包括在服务级别协议和有限保证中。 AKS 预览功能是由客户支持尽最大努力部分覆盖。

注意

受信任的访问 API 已正式发布。 我们为 Azure CLI 提供正式版 (GA) 支持，但它仍处于预览状态，需要使用 aks-preview 扩展。

受信任访问功能概述

受信任访问解决了以下情况：

  • 如果已设置或位于专用群集中，则除非实现专用终结点访问模型，否则 Azure 服务可能无法访问 Kubernetes API 服务器。
  • 授予 Azure 服务管理员对 Kubernetes API 的访问权限并不遵循最低特权访问最佳做法，并可能导致特权升级或凭据泄露风险。 例如，你可能必须实现高特权服务到服务权限，并且它们在审核评审中并不理想。

可以使用受信任的访问显式同意系统分配的允许资源的托管标识，以使用名为 角色绑定的 Azure 资源访问 AKS 群集。 Azure 资源通过系统分配的托管标识身份验证通过 AKS 区域网关访问 AKS 群集。 通过名为角色的 Azure 资源分配相应的 Kubernetes 权限。 通过受信任的访问，可以访问具有不同配置的 AKS 群集，包括但不限于专用群集、本地帐户已关闭的群集、Microsoft Entra 群集和授权 IP 范围群集。

先决条件

  • 具有活动订阅的 Azure 帐户。 免费创建帐户。

  • 支持系统分配的托管标识的资源类型。

    • 如果使用 Azure CLI，则需要 aks-preview 扩展版本 0.5.74 或更高版本。

  • 若要了解不同方案中要使用的角色，请参阅以下文章：

    • 对具有特殊配置的 AKS 群集的 Azure 机器学习访问
    • 什么是 Azure Kubernetes 服务备份？
    • 启用无代理容器状况

Defender for Cloud 和启用了 Arc 的 Kubernetes 群集的体系结构示意图

要想获得 Microsoft Defender for Containers 提供的完整保护，需要具有以下组件：

  • 已启用 Azure Arc 的 Kubernetes - 已启用 Azure Arc 的 Kubernetes - 一种基于代理的解决方案，安装在群集中的一个节点上，可将群集连接到 Defender for Cloud。 然后，Defender for Cloud 能够将以下两个代理部署为 Arc 扩展：
  • Defender 代理：在每个节点上部署的 DaemonSet 使用 eBPF 技术和 Kubernetes 审核日志收集主机信号，以提供运行时保护。 该代理向 Log Analytics 工作区注册，并用作数据管道。 但是，审核日志数据不会存储在 Log Analytics 工作区中。 Defender 代理可部署为已启用 Arc 的 Kubernetes 扩展。
  • 适用于 Kubernetes 的 Azure Policy：Pod 扩展开源 Gatekeeper v3 并注册为 Kubernetes 准入控制的 Webhook，因此能够以集中一致的方式在群集上应用大规模强制性操作和安全措施。 适用于 Kubernetes pod 的 Azure Policy 可部署为已启用 Arc 的 Kubernetes 扩展。 它仅安装在群集中的一个节点上。 有关详细信息，请参阅保护 Kubernetes 工作负载和了解适用于 Kubernetes 群集的 Azure Policy。

示意图显示已启用 Azure Arc 的体系结构的示例。

Defender for Cloud 和 EKS 群集的体系结构示意图

当 Defender for Cloud 保护 Elastic Kubernetes 服务中托管的群集时，审核日志数据的收集以无代理的方式进行。 以下是获得 Microsoft Defender for Containers 提供的完整保护所需的组件：

  • Kubernetes 审核日志 - AWS 帐户的 CloudWatch 通过无代理收集器启用和收集审核日志数据，并将收集的信息发送到 Microsoft Defender for Cloud 后端以进一步分析。
  • 已启用 Azure Arc 的 Kubernetes - 已启用 Azure Arc 的 Kubernetes - 一种基于代理的解决方案，安装在群集中的一个节点上，可将群集连接到 Defender for Cloud。 然后，Defender for Cloud 能够将以下两个代理部署为 Arc 扩展：
  • Defender 代理：部署在每个节点上的 DaemonSet 使用 eBPF 技术从主机收集信号，并提供运行时保护。 该代理向 Log Analytics 工作区注册，并用作数据管道。 但是，审核日志数据不会存储在 Log Analytics 工作区中。 Defender 代理可部署为已启用 Arc 的 Kubernetes 扩展。
  • 适用于 Kubernetes 的 Azure Policy：Pod 扩展开源 Gatekeeper v3 并注册为 Kubernetes 准入控制的 Webhook，因此能够以集中一致的方式在群集上应用大规模强制性操作和安全措施。 适用于 Kubernetes pod 的 Azure Policy 可部署为已启用 Arc 的 Kubernetes 扩展。 它仅安装在群集中的一个节点上。

示意图显示 Amazon Elastic Kubernetes 服务体系结构的示例。 AWS 中 Kubernetes 的无代理发现如何工作？

发现过程基于每隔一段时间拍摄的快照：

启用 Kubernetes 的无代理发现扩展后，将发生以下过程：

  • 创建：

    • 必须将 MDCContainersAgentlessDiscoveryK8sRole 的 Defender for Cloud 角色添加到 EKS 群集的 aws-auth ConfigMap。 可以自定义名称。

  • 分配：Defender for Cloud 为 MDCContainersAgentlessDiscoveryK8sRole 角色分配以下权限：

    • eks：UpdateClusterConfig
    • eks:DescribeCluster

  • 发现：Defender for Cloud 使用系统分配的标识，通过对 EKS 的 API 服务器执行 API 调用来发现环境中的 EKS 群集。

Defender for Cloud 和 GKE 群集的体系结构示意图

当 Defender for Cloud 保护 Google Kubernetes 引擎中托管的群集时，审核日志数据的收集以无代理的方式进行。 以下是获得 Microsoft Defender for Containers 提供的完整保护所需的组件：

  • Kubernetes 审核日志 - GCP 云日志记录通过无代理收集器启用和收集审核日志数据，并将收集的信息发送到 Microsoft Defender for Cloud 后端以进一步分析。
  • 已启用 Azure Arc 的 Kubernetes - 已启用 Azure Arc 的 Kubernetes - 一种基于代理的解决方案，安装在群集中的一个节点上，可将群集连接到 Defender for Cloud。 然后，Defender for Cloud 能够将以下两个代理部署为 Arc 扩展：
  • Defender 代理：部署在每个节点上的 DaemonSet 使用 eBPF 技术从主机收集信号，并提供运行时保护。 该代理向 Log Analytics 工作区注册，并用作数据管道。 但是，审核日志数据不会存储在 Log Analytics 工作区中。 Defender 代理可部署为已启用 Arc 的 Kubernetes 扩展。
  • 适用于 Kubernetes 的 Azure Policy：Pod 扩展开源 Gatekeeper v3 并注册为 Kubernetes 准入控制的 Webhook，因此能够以集中一致的方式在群集上应用大规模强制性操作和安全措施。 适用于 Kubernetes pod 的 Azure Policy 可部署为已启用 Arc 的 Kubernetes 扩展。 它只需安装在群集中的一个节点上。

示意图显示 Google Kubernetes 引擎体系结构群集的示例。

GCP 中 Kubernetes 的无代理发现是如何工作的？

发现过程基于每隔一段时间拍摄的快照：

启用 Kubernetes 的无代理发现扩展后，将发生以下过程：

  • 创建：

    • 创建服务帐户 mdc-containers-k8s-operator。 可以自定义名称。

  • 分配：Defender for Cloud 将以下角色附加到服务帐户 mdc-containers-k8s-operator：

    • 自定义角色 MDCGkeClusterWriteRole 具有 container.clusters.update 权限
    • 内置角色容器查看器

  • 发现：Defender for Cloud 使用系统分配的标识，通过对 GKE 的 API 服务器执行 API 调用来发现环境中的 GKE 群集。