共用方式為

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

  • 發行項

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

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

  • 使用 Microsoft Entra ID 和 Kube 角色型存取控制 (Kube RBAC) 來保護 API 伺服器存取。
  • 保護容器對節點資源的存取。
  • 將 AKS 叢集升級至最新版 Kubernetes。
  • 讓節點保持在最新狀態，並自動套用安全性修補檔。

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

啟用威脅保護

最佳做法指導方針

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

保護對 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 伺服器驗證使用者。

AKS 叢集的 Microsoft Entra 整合

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

建議的最佳做法是使用「群組」來提供檔案和資料夾的存取權，而不是個別身分識別。 例如，使用 Microsoft Entra ID 群組成員資格將使用者繫結至 Kube 角色，而不是個別使用者。 由於使用者的群組成員資格會變更，因此其位在 AKS 叢集上的存取權限也會隨之變更。

同時，假設您將個別使用者直接繫結至角色，且其作業函式變更。 雖然 Microsoft Entra 群組成員資格會更新，但成員在 AKS 叢集上的權限不會更新。 在這種情況下，使用者最後會被授與比所需更多的權限。

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

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

最佳做法指導方針

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

注意

若要實作網路原則，請在建立 AKS 叢集時包含屬性 --network-policy azure。 請使用下列命令建立叢集：az aks create -g myResourceGroup -n myManagedCluster --network-plugin azure --network-policy azure --generate-ssh-keys

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

保護資源的容器存取

最佳做法指導方針

限制存取容器可執行的動作。 提供最低權限數量，並避免使用根存取或提升的權限。

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

若要針對容器動作進行更細微的控制，您也可以使用內建的 Linux 安全性功能，例如 AppArmor 和 Seccomp。 如需詳細資訊，請參閱保護容器對資源的存取。

定期更新至最新版的 Kubernetes

最佳做法指導方針

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

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

  • 新功能
  • Bug 或安全性修正

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

AKS 支援 Kubernetes 的三個次要版本。 引入新的次要修補檔版本時，即會淘汰最舊的次要版本和支援的修補檔版本。 次要 Kubernetes 更新會定期發生。 若要保持支援，請確定您有治理流程可檢查必要的升級。 如需詳細資訊，請參閱支援的 Kubernetes 版本 AKS。

若要檢查可用於您叢集的版本，請使用 az aks get-upgrades 命令，如下列範例所示：

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

接著您可以使用 az aks upgrade 命令升級 AKS 叢集。 升級流程能夠安全地：

  • 一次隔離和清空一個節點。
  • 排定剩餘節點上的 Pod。
  • 部署執行最新作業系統和 Kubernetes 的新節點。

重要

在開發測試環境中測試新的次要版本，並驗證您的工作負載是否對於新的 Kubernetes 版本保持良好狀態。

Kubernetes 可能會取代您工作負載所用的 API (例如在 1.16 版中)。 將新版本帶入生產環境時，請考量在個別版本上使用多個節點集區，並一次升級一個集區，以漸進方式在叢集間進行更新。 如果執行多個叢集，請一次升級一個叢集，以漸進方式監視影響或變更。

az aks upgrade --resource-group myResourceGroup --name myAKSCluster --kubernetes-version KUBERNETES_VERSION

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

處理 Linux 節點更新

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

節點映像升級

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

處理 Windows Server 節點更新

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