適用於容器的 Defender 架構

  • 10 分鐘

適用於容器的 Defender 針對每個 Kubernetes 環境進行了不同的設計，無論它們是否在下列環境中執行：

  • Azure Kubernetes Service (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 會接收及分析：

  • 來自 API 伺服器的稽核記錄和安全性事件
  • 來自控制平面的叢集設定資訊
  • 來自 Azure 原則的工作負載設定
  • 來自節點層級中的安全性訊號和事件

每個 Kubernetes 環境的架構

適用於雲端的 Defender 和 AKS 叢集的架構圖

當適用於雲端的 Defender 保護裝載在 Azure Kubernetes Service 中的叢集時，稽核記錄資料的收集是無代理程式，且不會有額外的成本或設定考慮，透過 Azure 基礎結構自動收集。 這些是獲得適用於容器的 Microsoft Defender 所提供的全面保護所需的元件：

  • Defender 代理程式：部署在每個節點上的 DaemonSet 會使用 *Extended Berkeley Packet Filter (eBPF) 技術* 來收集主機中的訊號，並提供執行階段保護。 此代理程式會向 Log Analytics 工作區註冊，並當做資料管線使用。 不過，稽核記錄資料不會儲存在 Log Analytics 工作區中。 此 Defender 代理程式會作為 AKS 安全性設定檔來進行部署。

    • *eBPF 背景與資訊*：Extended Berkeley Packet Filter (eBPF) 是 Linux 核心內的一個強大且多功能架構，用於以程式設計方式分析和篩選網路封包，以及執行各種其他系統層級工作。 eBPF 最初是基於 20 世紀 90 年代推出的 Berkeley Packet Filter (BPF)，它透過允許使用者定義的程式可在核心內執行來擴充其功能，從而無需修改核心本身即可實現動態且有效的封包處理。
    • eBPF 程式是用 C 的受限子集撰寫的，並載入到核心 (在當中它們可在一個安全且沙盒化的環境內執行) 中。 這可讓您直接在核心內執行各種與網路相關的工作，例如封包篩選、流量監視、安全性強制執行，甚至是自訂通訊協定剖析。
    • eBPF 的主要優點之一是其多功能性和效能。 透過在核心內執行，eBPF 程式可以存取和直接操作網路封包，與傳統的使用者空間封包處理方法相比，大幅降低了額外的負荷。 此外，eBPF 程式還可以動態載入，並連結至核心內的各種勾點，從而實現即時回應並適應不斷變化的網路狀況。
    • 由於其彈性和效率，eBPF 在現代網路和安全性應用中變得越來越受歡迎。 它廣泛用於網路監視、入侵偵測、流量分析及效能微調的工具和架構中。 此外，其功能還超出了網路範圍，延伸到系統可檢視性和控制的其他領域，使其成為各種 Linux 型應用程式和服務的基本建置組塊。

  • 適用於 Kubernetes 的 Azure 原則：擴充開放原始碼 Gatekeeper v3 的 Pod，並註冊為 Kubernetes 許可控制的 Web 勾點，讓您能夠以集中式且一致的方式在叢集上套用大規模強制執行，並保護叢集。 適用於 Kubernetes 的 Azure 原則 Pod 會部署為 AKS 附加元件。 它只會安裝在叢集中的一個節點上。

顯示 Azure Kubernetes Service 架構範例的圖。

Defender 代理程式元件詳細資料

Pod 名稱 Namespace 種類 簡短描述 Capabilities 資源限制 所需的輸出
microsoft-defender-collector-ds-* kube-system DaemonSet 一組專注於從 Kubernetes 環境收集清查和安全性事件的容器。 SYS_ADMIN、
SYS_RESOURCE、
SYS_PTRACE		 memory: 296Mi

cpu: 360m		 No
microsoft-defender-collector-misc-* kube-system 部署 一組容器，著重於從未繫結至特定節點的 Kubernetes 環境收集詳細目錄和安全性事件。 N/A 記憶體：64Mi

CPU：60m		 No
microsoft-defender-publisher-ds-* kube-system DaemonSet 將收集的資料發佈至適用於容器的 Microsoft Defender 後端服務，以便處理和分析資料。 N/A 記憶體：200Mi

CPU：60m		 Https 443

在 Azure 中適用於 Kubernetes 的無代理程式探索如何運作？

探索流程是基於定期擷取的快照集：

顯示 Kubernetes 權限架構範例的圖。 當您啟用適用於 Kubernetes 的無代理程式探索的延伸模組時，會進行下列流程：

  • 建立：

    • 如果從 Defender CSPM 啟用延伸模組，適用於雲端的 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 會使用 API 呼叫 AKS 的 API 伺服器，以在您的環境中執行 AKS 叢集探索。

  • 繫結：探索到 AKS 叢集後，適用於雲端的 Defender 會透過在建立的身分識別和 Kubernetes ClusterRole aks:trustedaccessrole:defender-containers:microsoft-defender-operator 之間建立一個 ClusterRoleBinding 來執行 AKS 繫結作業。 ClusterRole 可透過 API 顯示，並為適用於雲端的 Defender 資料平面提供叢集內的讀取權限。

使用受信任存取權 (預覽版) 安全存取 Azure Kubernetes Service 中的 Azure 資源

許多與 Azure Kubernetes Service (AKS) 整合的 Azure 服務都需要存取 Kubernetes API 伺服器。 為了避免授與這些服務管理員存取權或將 AKS 叢集公開以供網路存取，您可以使用 AKS 受信任存取權功能。

此功能可讓服務使用 Azure 後端安全地存取 AKS 和 Kubernetes，而不需要私人端點。 此功能不需要依賴具有 Microsoft Entra 權限的身分識別，而是可以使用系統指派的受控識別，向您想要搭配 AKS 叢集使用的受控服務和應用程式進行驗證。

重要

AKS 預覽功能可透過自助服務，以加入方式使用。 預覽會以「現狀」和「可供使用時」提供，其其不受服務等級協定和有限瑕疵擔保所保護。 客戶支援部門會盡最大努力，部分支援 AKS 預覽。

注意

受信任存取權 API 已正式推出。 我們提供 Azure CLI 的正式發行 (GA) 支援，但它仍處於預覽狀態，且需要使用 aks-preview 延伸模組。

受信任存取權功能概觀

受信任存取權可解決下列情景的存取問題：

  • 如果授權的 IP 範圍已設定或位於私人叢集中，則 Azure 服務可能無法存取 Kubernetes API 伺服器 (除非您實作私人端點存取模型)。
  • 授與對 Kubernetes API 的 Azure 服務管理員存取權不會遵循最低權限存取的最佳做法，而且可能會導致權限提升或認證外洩的風險。 例如，您可能必須實施高特許權的服務對服務權限，而它們在稽核審查中並不理想。

您可以使用「受信任存取權」(Trusted Access)，透過使用稱為角色繫結的 Azure 資源，明確同意您的系統指派的允許資源的受控識別可以存取您的 AKS 叢集。 您的 Azure 資源會透過系統指派的受控識別驗證，以透過 AKS 區域閘道來存取 AKS 叢集。 適當的 Kubernetes 權限會透過一個稱為角色的 Azure 資源來指派。 透過「受信任存取權」(Trusted Access)，您可以存取具有不同設定的 AKS 叢集，包括但不限於私人叢集、已關閉本機帳戶的叢集、Microsoft Entra 叢集和授權的 IP 範圍叢集。

必要條件

  • 具有有效訂用帳戶的 Azure 帳戶。 免費建立帳戶。

  • 支援系統指派受控識別的資源類型。

    • 如果您使用 Azure CLI，則需要 aks-preview 延伸模組 0.5.74 版或更新版本。

  • 若要了解在不同場景中使用哪些角色，請參閱以下文章：

    • Azure Machine Learning 對具有特殊設定的 AKS 叢集的存取
    • 什麼是 Azure Kubernetes Service 備份？
    • 開啟無代理程式的容器態勢

適用於雲端的 Defender 和已啟用 Arc 的 Kubernetes 叢集的架構圖

必須具備下列元件，才能接收由適用於容器的 Microsoft Defender 所提供的完整保護：

  • 已啟用 Azure Arc 的 Kubernetes - 已啟用 Azure Arc 的 Kubernetes - 在叢集中的一個節點上安裝的代理程式型解決方案，會將叢集連線到適用於雲端的 Defender。 然後，適用於雲端的 Defender 就可以將下列兩個代理程式部署為 Arc 延伸模組:
  • Defender 代理程式:部署在每個節點上的 DaemonSet，使用 eBPF 技術和 Kubernetes 稽核記錄收集主機訊號，以提供執行階段保護。 此代理程式會向 Log Analytics 工作區註冊，並作為資料管線使用。 不過，稽核記錄資料不會儲存在 Log Analytics 工作區中。 Defender 代理程式會部署為已啟用 Arc 的 Kubernetes 延伸模組。
  • 適用於 Kubernetes 的 Azure 原則: 擴充開放原始碼 Gatekeeper v3 的 Pod，並註冊為 Kubernetes 許可控制的 Webhook，讓您能夠以集中式且一致的方式在叢集上套用大規模強制執行，並保護叢集。 適用於 Kubernetes 的 Azure 原則 Pod 會部署為已啟用 Arc 的 Kubernetes 延伸模組。 它只會安裝在叢集中的一個節點上。 如需詳細資訊，請參閱保護 Kubernetes 工作負載和了解適用於 Kubernetes 叢集的 Azure 原則。

顯示已啟用 Azure Arc 架構範例的圖。

適用於雲端的 Defender 和 EKS 叢集的架構圖

當適用於雲端的 Defender 保護裝載於 Elastic Kubernetes Service 中的叢集時，稽核記錄資料的收集會以無代理程式的方式進行。 必須具備下列元件，才能接收由適用於容器的 Microsoft Defender 所提供的完整保護：

  • Kubernetes 稽核記錄 (英文)：AWS 帳戶的 CloudWatch 會透過無代理程式收集器啟用並收集稽核記錄資料，然後將收集的資訊傳送到適用於雲端的 Microsoft Defender 後端，以進行進一步分析。
  • 已啟用 Azure Arc 的 Kubernetes - 已啟用 Azure Arc 的 Kubernetes - 在叢集中的一個節點上安裝的代理程式型解決方案，會將叢集連線到適用於雲端的 Defender。 然後，適用於雲端的 Defender 就可以將下列兩個代理程式部署為 Arc 延伸模組:
  • Defender 代理程式: 部署在每個節點上的 DaemonSet、使用 eBPF 技術從主機收集訊號，並提供運執行階段保護。 此代理程式會向 Log Analytics 工作區註冊，並作為資料管線使用。 不過，稽核記錄資料不會儲存在 Log Analytics 工作區中。 Defender 代理程式會部署為已啟用 Arc 的 Kubernetes 延伸模組。
  • 適用於 Kubernetes 的 Azure 原則: 擴充開放原始碼 Gatekeeper v3 的 Pod，並註冊為 Kubernetes 許可控制的 Webhook，讓您能夠以集中式且一致的方式在叢集上套用大規模強制執行，並保護叢集。 適用於 Kubernetes 的 Azure 原則 Pod 會部署為已啟用 Arc 的 Kubernetes 延伸模組。 它只會安裝在叢集中的一個節點上。

顯示 Amazon Elastic Kubernetes Service 架構範例的圖。 在 AWS 中適用於 Kubernetes 的無代理程式探索如何運作？

探索流程是基於定期擷取的快照集：

當您啟用 Kubernetes 延伸模組的無代理流程探索時，會發生下列流程:

  • 建立：

    • 適用於雲端的 Defender 角色 MDCContainersAgentlessDiscoveryK8sRole 必須新增至 EKS 叢集的 aws-auth ConfigMap。 您可以自訂名稱。

  • 指派: 適用於雲端的 Defender 會指派 MDCContainersAgentlessDiscoveryK8sRole 角色下列權限:

    • eks:UpdateClusterConfig
    • eks:DescribeCluster

  • 探索：透過使用系統指派的身分識別，適用於雲端的 Defender 會使用 API 呼叫 EKS 的 API 伺服器，以在您的環境中執行 EKS 叢集探索。

適用於雲端的 Defender 和 GKE 叢集的架構圖

當適用於雲端的 Defender 保護裝載於 Google Kubernetes Engine 中的叢集時，稽核記錄資料的收集會以無代理程式的方式進行。 必須具備下列元件，才能接收由適用於容器的 Microsoft Defender 所提供的完整保護：

  • Kubernetes 稽核記錄 (英文)：GCP Cloud Logging (英文) 會透過無代理程式收集器啟用並收集稽核記錄資料，然後將收集的資訊傳送到適用於雲端的 Microsoft Defender 後端，以進行進一步分析。
  • 已啟用 Azure Arc 的 Kubernetes - 已啟用 Azure Arc 的 Kubernetes - 在叢集中的一個節點上安裝的代理程式型解決方案，會將叢集連線到適用於雲端的 Defender。 然後，適用於雲端的 Defender 就可以將下列兩個代理程式部署為 Arc 延伸模組:
  • Defender 代理程式: 部署在每個節點上的 DaemonSet、使用 eBPF 技術從主機收集訊號，並提供運執行階段保護。 此代理程式會向 Log Analytics 工作區註冊，並作為資料管線使用。 不過，稽核記錄資料不會儲存在 Log Analytics 工作區中。 Defender 代理程式會部署為已啟用 Arc 的 Kubernetes 延伸模組。
  • 適用於 Kubernetes 的 Azure 原則: 擴充開放原始碼 Gatekeeper v3 的 Pod，並註冊為 Kubernetes 許可控制的 Webhook，讓您能夠以集中式且一致的方式在叢集上套用大規模強制執行，並保護叢集。 適用於 Kubernetes 的 Azure 原則 Pod 會部署為已啟用 Arc 的 Kubernetes 延伸模組。 它只需要安裝在叢集中的一個節點上。

顯示 Google Kubernetes Engine 架構叢集範例的圖。

在 GCP 中適用於 Kubernetes 的無代理程式探索如何運作？

探索流程是以間隔拍攝的快照集為基礎:

當您啟用 Kubernetes 延伸模組的無代理流程探索時，會發生下列流程:

  • 建立：

    • 系統會建立服務帳戶 mdc-containers-k8s-operator。 您可以自訂名稱。

  • 指派: 適用於雲端的 Defender 會將下列角色附加至服務帳戶 mdc-containers-k8s-operator:

    • 自訂角色 MDCGkeClusterWriteRole (具有container.clusters.update 權限)
    • 內建角色 container.viewer

  • 探索：透過使用系統指派的身分識別，適用於雲端的 Defender 會使用 API 呼叫 GKE 的 API 伺服器，以在您的環境中執行 GKE 叢集探索。