Azure Kubernetes Service (AKS) 中叢集安全性與升級的最佳做法

適用於: ✔️ AKS 自動化 ✔️ AKS 標準

當您管理 Azure Kubernetes Service (AKS) 中的叢集時，工作負載和資料安全性是主要考量。 使用邏輯隔離執行多租用戶叢集時，您尤其需要保護資源和工作負載存取。 藉由套用最新的 Kubernetes 和節點作業系統安全性更新，將攻擊的風險降到最低。

本文著重在如何保護您的 AKS 叢集。 您將學習如何：

您也可以參閱容器映像管理和 Pod 安全性的最佳做法。

AKS 叢集模式的安全性責任

AKS 支援兩種叢集模式： AKS 自動模式 與 AKS 標準模式。 兩種模式的安全目標相同，但執行責任不同。

AKS Automatic 包含強化的基準設定，並在支援的組態中提供更多預先設定的控制項。 AKS 標準提供更廣泛的直接配置控制，增加操作員對基線設定及持續作業的責任。

啟用威脅保護

最佳做法指導方針

您可以啟用適用於容器的 Defender，以協助保護您的容器。 適用於容器的 Defender 可以評估叢集組態並提供安全性建議、執行弱點掃描，以及為 Kubernetes 節點和叢集提供即時保護和警示。

此指引適用於兩種模式。 即使 AKS Automatic 提供預先設定的安全預設，威脅防護、入職與警示回應工作流程仍是團隊的營運責任。

保護對 API 伺服器和叢集節點的存取

最佳做法指導方針

保護叢集最重要方式的其中一個是保護 Kubernetes API 伺服器的存取。 若要控制 API 伺服器的存取權，請整合 Kube RBAC 與 Microsoft Entra ID。 使用這些控制項，您可以用保護您 Azure 訂閱存取的相同方式來保護 AKS。

Kubernetes API 伺服器針對要求提供單一連線點，以在叢集內執行動作。 若要保護和稽核對 API 伺服器的存取，則必須限制存取並提供盡可能最低層次的權限。 雖然這種做法並非 Kubernetes 所獨有，但當您基於多租戶使用需求，在邏輯上隔離 AKS 叢集時，這種做法就顯得格外重要。

Microsoft Entra ID 提供的身分識別管理解決方案不僅符合企業需求，也整合了 AKS 叢集。 由於 Kubernetes 未提供身分識別管理解決方案，因此您可能難以精確地限制對 API 伺服器的存取。 在 AKS 中使用與 Microsoft Entra 整合的叢集，您就可以使用現有的使用者和群組帳戶，來對 API 伺服器驗證使用者。

使用 Kubernetes RBAC 和 Microsoft Entra ID 整合功能，您可以保護 API 伺服器，並將特定範圍資源集所需的最低權限授與該資源集，例如單一命名空間。 您可以向不同的 Microsoft Entra 使用者或群組授與不同的 Kubernetes 角色。 藉由這些細微的權限，您可以限制對 API 伺服器的存取，並提供所執行動作的清楚稽核線索。

在 AKS Automatic 中，授權與安全基線在支援的配置中較為預先設定，因此操作員專注於驗證、治理與異常處理。 在 AKS 標準中，操作員通常直接配置這些控制並維持其生命週期態勢。

如需 Microsoft Entra 整合、Kube RBAC 和 Azure RBAC 的詳細資訊，請參閱 AKS 中驗證和授權的最佳做法。

限制對執行個體中繼資料 API 的存取

最佳做法指導方針

在所有使用者命名空間中新增網路原則，以封鎖 Pod 輸出至中繼資料端點。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-instance-metadata
spec:
  podSelector:
    matchLabels: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 10.10.0.0/0#example
        except:
        - 169.254.169.254/32

在 AKS Standard 中，請確保您選擇的網路模型與政策引擎支援此政策路徑。 在 AKS Automatic 中，若叢集設定支援，請套用等效的命名空間層級輸出限制。

安全地以容器存取資源

最佳做法指導方針

限制存取容器可執行的動作。 僅授予最低限度的權限，並避免使用 root 存取或權限提升。

就如同您應授與使用者或群組所需的最低權限一樣，也應限制容器只能執行必要動作和流程。 為了將攻擊風險降到最低，請避免設定需要提升權限或根存取的應用程式和容器。

使用使用者命名空間，您可以改善主機隔離，並在容器中斷時限制橫向移動。 不論 Pod 是否以 root 身分執行，這些改善都很重要。

若要針對容器動作進行更細微的控制，您也可以使用內建的 Linux 安全性功能，例如 AppArmor 和 Seccomp。

即使 AKS Automatic 提供了強化預設值，工作負載層級的安全控管仍由應用程式與平台團隊負責。

如需詳細資訊，請參閱保護容器對資源的存取。

定期將 Kubernetes 更新至最新版本

最佳做法指導方針

為了持續取得最新功能和 Bug 修正，請定期升級 AKS 叢集中的 Kubernetes 版本。

Kubernetes 發行新功能的步調，比大部分傳統的基礎結構平台還快。 Kubernetes 更新包括：

• 新功能
• 錯誤或安全性修正

新功能在變得「穩定」之前一般會經歷 Alpha 和 Beta 狀態。 一旦穩定，即正式推出並建議用於生產環境。 Kubernetes 新功能發行版本週期可讓您在更新 Kubernetes 的同時，不會經常遇到中斷性變更，或需要調整部署及範本。

AKS 支援 Kubernetes 的三個次要版本。 引入新的次要修補檔版本時，即會淘汰最舊的次要版本和支援的修補檔版本。 次要 Kubernetes 更新會定期發生。 若要維持在支援範圍內，請確保您已建立治理程序，以確認是否需要進行必要的升級。 如需詳細資訊，請參閱支援的 Kubernetes 版本 AKS。

在 AKS Automatic 中，升級相關行為較多預先設定於支援的配置中，操作員應專注於工作負載準備度驗證與發布治理。 在 AKS 標準中，營運商更直接地選擇並管理升級策略與部署時機。

az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output table

Get-AzAksUpgradeProfile -ResourceGroupName myResourceGroup -ClusterName myAKSCluster |
Select-Object -Property Name, ControlPlaneProfileKubernetesVersion -ExpandProperty ControlPlaneProfileUpgrade |
Format-Table -Property *

如需有關在 AKS 中升級的詳細資訊，請參閱 AKS 中支援的 Kube 版本和升級 AKS 叢集。

處理 Linux 節點更新

每天晚上，AKS 中的 Linux 節點都會透過其所屬發行版本的更新通道接收安全性修補程式。 當節點部署到 AKS 叢集中時，即已自動設定此行為。 為了盡可能減少中斷，並降低對正在執行之工作負載的可能影響，如果安全性修補程式或核心更新需要重新啟動時，節點不會自動重新啟動。 如需如何處理節點重新啟動的詳細資訊，請參閱將安全性和核心更新套用至 AKS 中的節點。

在 AKS Automatic 中，節點更新行為在支援的設定中較為預先設定。 在 AKS 標準中，操作員通常定義修補與重啟治理，並明確設定操作控制。

節點映像升級

自動升級會將更新套用至 Linux 節點作業系統，但用來為叢集建立節點的映像會保持不變。 如果將新的 Linux 節點新增至您的叢集，則會使用原始映像來建立節點。 這個新節點會在每天晚上自動檢查期間收到全部可用的安全性和核心更新，但會保持未修補，直到全部檢查和重新啟動都完成為止。 您可以使用節點映像升級來檢查和更新叢集所使用的節點映像。 如需節點映像升級的詳細資訊，請參閱 Azure Kubernetes Service (AKS) 節點映像升級。

處理 Windows Server 節點更新

針對 Windows Server 節點，請定期執行節點映像升級作業，以安全地隔離和清空 Pod，以及部署更新的節點。

相關內容

欲了解更多關於 AKS 及保護 AKS 叢集的資訊，請參閱以下文章：

• AKS 自動與 AKS 標準功能比較
• AKS 認證與授權的最佳實務