容器安全保護整個端到端的管線，從建置到運行於 Azure Kubernetes Service （AKS） 中的應用程式工作負載。
安全供應鏈包括組建環境和登錄。
Kubernetes 包括安全性元件，例如「Pod 安全性標準」和「祕密」。 Azure 包含 Microsoft Entra ID、Microsoft Defender for Containers、Azure 原則、Azure Key Vault、網路安全群組及編排叢集升級等元件。 AKS 合併這些安全性元件，以：
- 提供完整的驗證和授權劇本。
- 套用 AKS 內建的 Azure 原則 來保護你的應用程式。
- 搭配適用於容器的 Microsoft Defender ，取得從建置到應用程式的端對端深入解析。
- 讓您的 AKS 叢集持續執行最新的 OS 安全性更新和 Kubernetes 版本。
- 提供安全的 Pod 流量和敏感性認證存取。
AKS 支援兩種叢集模式： AKS 自動模式 與 AKS 標準模式。 除非另有說明，本文的安全概念適用於兩種模式。 AKS Automatic 包含強化的安全性基準，其中多個控制項已依預設預先設定，而 AKS Standard 則提供更大的設定彈性。
本文將介紹對 AKS 中的應用程式進行保護的核心概念。
這很重要
自2025 年 11 月 30 日起，Azure Kubernetes Service (AKS) 將不再支援或提供 Azure Linux 2.0 的安全更新。 Azure Linux 2.0 節點映像已凍結在 202512.06.0 發行版本。 自 2026 年 3 月 31 日起，節點映像將被移除，且你將無法擴展節點池。 遷移到支援的 Azure Linux 版本時，可以升級你的節點池到 支援的 Kubernetes 版本，或遷移到 osSku AzureLinux3。 欲了解更多資訊，請參閱 退休GitHub議題 及 Azure 更新退休公告。 欲掌握最新公告與更新，請參考AKS發布說明。
建置安全性
建築安全是您安全供應鏈的切入點。 在映像檔升級至部署環境前，先在 CI 中執行靜態分析及漏洞與合規評估。
在這兩種 AKS 模式中，請採用風險導向的分類處理方式，而不要因為任何漏洞就封鎖所有建置。 根據供應商狀態與嚴重程度優先處理修復，並對非可利用或有時間限制的例外申請寬限期。
AKS Automatic 透過讓叢集從經過強化的基準組態開始部署，並預先設定安全性控制項，有助於減少下游組態漂移。 這使得建置時驗證影像品質與政策合規性更為重要，因為受信任的影像更穩定地被提升為安全的執行時基線。
AKS Standard 提供更高的叢集層級彈性，因此建置管線應在部署前明確強制執行組織的映像來源、弱點閾值和原則閘門基準。
登錄安全性
登錄檔安全驗證只有受信任且合規的映像可供部署，並協助在建置後偵測漂移。 持續評估登錄檔中的映像脆弱性狀態，而非僅限於建置時。 登錄檔掃描會發現新揭露的漏洞和繞過核准建置路徑的映像檔。 使用影像簽名與驗證，如 Notary V2，確保工作負載來自可信且可驗證來源的來源。
對於預先設定多項執行時安全功能的 AKS 自動系統來說，登錄檔控制仍是維持執行時供應鏈潔淨的關鍵上游門檻。 對於 AKS 標準，請套用相同的登錄控制，並與叢集准入及政策設定對齊，以持續執行受信任映像的使用。
叢集安全性
在 AKS 中，Kubernetes 主要元件是 Microsoft 提供、管理及維護的託管服務的一部分。 每個 AKS 叢集都有自己的單一租用戶專用 Kubernetes 主節點，用於提供 API 伺服器、排程器等功能。如需詳細資訊，請參閱 Azure Kubernetes Service 的弱點管理。
根據預設，Kubernetes API 伺服器會使用公用 IP 位址和完整網域名稱 (FQDN)。 您可以使用已授權的 IP 範圍來限制對 API 伺服器端點的存取。 您也可以建立完全私人叢集，以限制 API 伺服器對虛擬網路的存取。
對於 AKS Automatic，API 伺服器虛擬網路整合已預先設定為預設安全態勢的一部分。 在 AKS 標準中，同樣的功能也可用，並可根據你的網路設計和安全需求啟用。
你可以使用 Kubernetes 角色基礎存取控制（Kubernetes RBAC）和 Azure RBAC 來控制對 API 伺服器的存取。 在 AKS Automatic 中，適用於 Kubernetes 授權的 Azure RBAC 已預先設定。 在 AKS 標準中，您可以選擇並配置最適合您環境的授權模式。 欲了解更多資訊，請參閱 Microsoft Entra 與 AKS 的整合。
保護部署管線的 API 伺服器存取
部署管線需要與 API 伺服器的網路連線，以及修改 Kubernetes 資源的授權。 這些控制項請分別設定，因為網路存取並不會授予管線身份權限。
- 公共 API 伺服器： 使用 API 伺服器授權的 IP 範圍 ，只允許受信任的來源網路。 新增部署代理程式所在網路的穩定對外公用 IP 位址或 CIDR 範圍。 如果代理流量通過防火牆或 NAT 閘道，請授權 API 伺服器所見的公開出口 IP 位址。 設定防火牆規則，允許代理程式存取 API 伺服器 FQDN。
- 私人 API 伺服器： 在叢集 VNet、對等 VNet 或其他能到達私有端點的網路中放置自架部署代理或受管 DevOps 池。 為 API 伺服器 FQDN 配置路由、網路安全群組、防火牆規則及私有 DNS 解析。 Azure DevOps Microsoft 主機代理不支援私有 AKS 叢集。 範例架構請參見「使用 Azure 防火牆 以協助保護 AKS 叢集」。
-
管線識別： 使用專用的管理身份或服務主體，並只授予部署所需的權限。 如果管線取得 kubeconfig 檔案，請授予 Azure Kubernetes Service 叢集用戶角色。 然後另外授權 Kubernetes API 操作。 對於使用 Azure RBAC 進行 Kubernetes 授權的叢集，請在實際可行的最小叢集或命名空間範圍內指派 AKS RBAC 角色，例如 Azure Kubernetes Service RBAC Writer。 對於使用 Kubernetes RBAC 的叢集，請將 Microsoft Entra 身份綁定到適當的 Kubernetes
Role或ClusterRole。 欲了解更多資訊，請參閱 叢集授權概念。
AKS 自動安全性預設值
AKS Automatic 預設包含強化的基準組態，且已預先設定好安全性控制項，包括：
- 適用於 Kubernetes 授權的 Azure RBAC
- API 伺服器虛擬網路整合
- 工作負載身分識別與 OIDC 簽發者
- 強制模式中的部署防護措施與基準 Pod 安全性標準
- 用於移除未使用的脆弱影像的影像清潔工具
- 管理系統節點池的安全限制，保留客戶工作負載與 AKS 管理基礎設施之間的界限
AKS 標準以更高的實作彈性支援這些功能，但可能需要明確啟用與操作管理。
節點安全性
AKS nodes 係 Azure 虛擬機（VMS）。 在 AKS Standard 中，你可以管理節點池的設定與生命週期選項。 在 AKS Automatic 中，AKS 代表你管理系統節點池和核心系統元件，包括擴展與升級，並對受管理系統基礎架構設置安全限制。
Linux 節點運行的是優化版的 Ubuntu 或 Azure Linux。 Windows Server節點會使用 containerd 容器執行時執行優化的 Windows Server 版本。
當 AKS 叢集建立或相應增加時，節點將會自動以最新的 OS 安全性更新和設定進行部署。
附註
AKS 叢集執行：
- Kubernetes 1.19 版及更新版本：Linux 節點集區使用
containerd作為其容器執行階段。 Windows Server 2019 和 Windows Server 2022 節點池使用containerd作為其容器執行環境。 更多資訊請參閱 新增 Windows Server 節點池containerd。 - Kubernetes 1.19 版及更早版本：Linux 節點集區使用 Docker 作為容器執行階段。
欲了解更多關於 Linux 及 Windows 工作節點安全升級流程的資訊，請參見 Security patching nodes。
運行 Azure 第二代虛擬機的 AKS 叢集支援 Trusted Launch。 此功能可結合您可以獨立啟用的技術，例如安全開機和信任平台模組 （vTPM） 的虛擬化版本，以防止進階和持續性攻擊技術。 系統管理員可使用已驗證和簽署的開機載入器、OS 核心和驅動程式來部署 AKS 背景工作角色節點，以確保基礎 VM 的整個開機鏈結完整性。
容器和安全最佳化作業系統選項
Azure Container Linux（ACL）是一個不可變、容器優化的 AKS 作業系統。 ACL 源自 Flatcar Container Linux 專案，建立在 Flatcar 經過驗證的容器優先不可變設計基礎上，同時加入 Azure Linux 套件、服務與平台整合。 這讓 ACL 能與上游 Flatcar 創新緊密對齊，同時滿足 Azure 的生產、安全與合規要求。 若要深入瞭解 Flatcar 容器 Linux，請參閱 Flatcar 文件。
ACL 自 AKS v1.34 起正式作為 AKS 的作業系統選項提供使用（GA）。 你可以在新的 AKS 叢集中部署 ACL 節點池，將 ACL 節點池加入現有叢集，並將現有的 Linux 節點池遷移到 ACL。
欲了解更多 ACL 資訊，請參閱 Azure 容器 Linux （ACL） 的 AKS 概覽。
節點授權
節點授權是特殊用途的授權模式，專門授權 kubelet API 要求，以防範東-西攻擊。 AKS 1.24 + 叢集預設會啟用節點授權。
節點部署
節點會部署至私人虛擬網路子網路中，且不會獲指派公用 IP 位址。 為了進行疑難排解和管理，預設會啟用 SSH，而且只能使用內部 IP 位址進行存取。 在叢集和節點集區建立期間或針對現有叢集或節點集區停用 SSH，目前處於預覽狀態。 如需詳細資訊，請參閱管理 SSH 存取 (部分機器翻譯)。
節點儲存體
節點提供儲存時，使用Azure 受控磁碟。 對於大多數 VM 節點大小，Azure 受控磁碟都是以高效能 SSD 為後盾的進階磁碟。 儲存在管理磁碟上的資料會在 Azure 平台上自動靜止加密。 為了提升冗餘性，Azure 受控磁碟 會安全地在 Azure 資料中心內複製。
惡意多租用戶工作負載
目前，如果惡意使用多租用戶，則 Kubernetes 環境不安全。 適用於節點的額外安全性功能 (例如「Pod 安全性原則」或 Kubernetes RBAC) 會有效率地封鎖惡意探索。 執行惡意多租用戶工作負載時，若要真正確保安全性，應該只信任 Hypervisor。 Kubernetes 的安全性網域會成為整個叢集，而非個別節點。
對於這些類型的惡意多租用戶工作負載，您應使用實際隔離的叢集。 如需如何隔離工作負載的詳細資訊，請參閱 AKS 中叢集隔離的最佳做法。
計算隔離
基於合規性或法規需求，某些工作負載可能需要與其他客戶工作負載高度隔離。 針對這些工作負載，Azure 提供：
- 核心隔離容器，用來作為 AKS 叢集中的代理程式節點。 這些容器完全隔離於特定硬體類型，並與 Azure 主機結構、主機作業系統及虛擬機監控程式隔離。 他們專注於單一客戶。 在建立 AKS 叢集或新增節點集區時，請選取其中一個隔離 VM 大小作為「節點大小」。
- 機密容器 (預覽版) 也是以 Kata 機密容器為基礎，會加密容器記憶體，並在計算期間防止記憶體中的資料成為純文字、可讀取格式及遭到竄改。 它有助於將您的容器與其他容器群組/Pod 和 VM 節點 OS 核心隔離。 機密容器 (預覽版) 會使用硬體型記憶體加密 (SEV-SNP)。
- Pod 沙箱功能 (預覽版) 提供容器應用程式與容器主機的共用核心和計算資源 (CPU、記憶體與網路) 之間的隔離界限。
網路安全性
為了與本地網路的連接與安全性，你可以將 AKS 叢集部署到現有的 Azure 虛擬網路子網中。 這些虛擬網路會透過 Azure Site-to-Site VPN 或 Express Route 回連到你的本地網路。 使用私人內部 IP 位址來定義 Kubernetes 輸入控制器，以限制服務對內部網路連線的存取。
在 AKS Automate 中，受管理的虛擬網路能力以及核心的入口與出口預設值都已預先設定，以提供安全的基準。 在 AKS 標準中，網路模型與出口/入口控制更具彈性，應根據你的安全架構來選擇。
Azure 網路安全群組
為了過濾虛擬網路流量，Azure 使用網路安全群組規則。 這些規則可定義允許或拒絕存取資源的來源和目的地 IP 範圍、連接埠和通訊協定。 系統會建立預設規則，以允許 Kubernetes API 伺服器的 TLS 流量。 您可以使用負載平衡器、連接埠對應或輸入路由來建立服務。 AKS 會自動針對流量修改網路安全性群組。
如果您提供自己的子網路給 AKS 叢集（無論是使用 Azure CNI 或 Kubenet），不要 修改由 AKS 管理的 NIC 層級網路安全群組。 您應建立更多子網路層級的網路安全性群組，以修改流量的流程。 請確定這些群組不會干擾到管理叢集所需的流量，例如，負載平衡器存取、與控制平面的通訊或輸出 (部分機器翻譯)。
Kubernetes 網路原則
為了限制叢集中 Pod 之間的網路流量，AKS 支援 Kubernetes 網路原則。 透過網路原則，您可以根據命名空間和標籤選取器，允許或拒絕叢集內的特定網路路徑。
應用程式安全性
為了保護在 AKS 上運行的 pod，可以考慮使用 Microsoft Defender for Containers 來偵測並限制針對你 Pod 中運行的應用程式的網路攻擊。 執行持續掃描以偵測應用程式弱點狀態的漂移，並實作「藍色/綠色/canary」程序來修補和取代易受攻擊的映像。
在 AKS Automate 中，工作負載身份與 OIDC 發行者已預先設定，以簡化對 Azure 服務的安全工作負載存取。 在 AKS 標準中，這些功能是可啟用的，作為你基準安全態勢的一部分。
保護容器對資源的存取
就如同您應授與使用者或群組所需的最低權限一樣，也應限制容器只能執行必要動作和流程。 為了將攻擊風險降到最低，請避免設定需要提升權限或根存取的應用程式和容器。 內建的 Linux 安全功能如 AppArmor 和 seccomp 被推薦作為保護容器存取資源的最佳實務。
Kubernetes 秘密
使用 Kubernetes「祕密」，您可以將敏感性資料插入至 Pod，例如存取認證或金鑰。
- 使用 Kubernetes API 來建立祕密。
- 定義 Pod 或部署，並要求特定的祕密。
- 祕密只會提供給已排程 Pod 所需要的祕密節點。
- 祕密會儲存至 tmpfs，而不會寫入至磁碟。
- 當您刪除節點上最後一個需要祕密的 Pod 時，該祕密就會從節點的 tmpfs 中刪除。
- 祕密會儲存於指定的命名空間內，且僅供相同命名空間中的 Pod 存取。
使用祕密可減少 Pod 或服務 YAML 資訊清單中所定義的敏感性資訊。 秘密會以 YAML 資訊清單的形式儲存在 Kubernetes API 伺服器中，供您要求。 此方法僅可供特定 Pod 存取祕密。
附註
原始祕密資訊清單檔包含 base64 格式的祕密資料。 如需了解更多資訊，請參閱官方文件。 請將這些檔案視為敏感性資訊，並且永遠都不要將其認可至原始檔控制。
Kubernetes 祕密會儲存至 etcd，這是分散式機碼值存放區。 AKS 允許 使用客戶管理的密鑰，在 etcd 中加密其他秘密。
相關內容
若要開始保護您的 AKS 叢集，請參閱升級 AKS 叢集 (部分機器翻譯)。
如果您正在評估特定模式的預設設定和作業責任，請參閱 什麼是 Azure Kubernetes Service (AKS) Automatic？
如需相關聯的最佳做法，請參閱 AKS 中叢集安全性和升級的最佳做法以及 AKS 中 Pod 安全性的最佳做法。
如需 Kubernetes 及 AKS 核心概念的詳細資訊，請參閱：