使用部署保全措施在 Azure Kubernetes Service (AKS) (預覽) 中強制執行最佳做法
本文說明如何使用部署保全措施,在 Azure Kubernetes Service (AKS) 叢集上強制執行最佳做法。
概觀
在整個開發生命週期中,如果 Kubernetes 資源的初始部署中有錯誤的設定,就常會發生 BUG 和其他問題。 為了減輕 Kubernetes 開發負擔,Azure Kubernetes Service (AKS) 提供了部署保全措施 (預覽)。 部署保全措施會透過 Azure 原則控制,在 AKS 叢集中強制執行 Kubernetes 最佳做法。
部署保全措施提供兩種設定層級:
Warning
:在程式碼終端中顯示警告訊息,向您警示任何不符合規範的叢集設定,但仍允許要求通過。Enforcement
:如果部署未遵循最佳做法,則拒絕並變動部署,以強制執行符合規範的設定。
在設定「警告」或「強制執行」的部署保全措施後,部署保全措施會以程式設計方式,評估正在建立或更新的叢集是否符合規範。 部署保全措施也會透過 Azure 入口網站、CLI 或終端中的 Azure 原則合規性儀表板,針對每個資源層級顯示跨工作負載所彙總的合規性資訊。 執行不符合規範的工作負載表示叢集未遵循最佳做法,且叢集上的工作負載可能會因為叢集設定而造成問題。
重要
AKS 預覽功能可透過自助服務,以加入方式使用。 預覽會以「現狀」和「可供使用時」提供,其其不受服務等級協定和有限瑕疵擔保所保護。 客戶支援部門會盡最大努力,部分支援 AKS 預覽。 因此,這些功能不適合實際執行用途。 如需詳細資訊,請參閱下列支援文章:
必要條件
您必須啟用適用於 AKS 的 Azure 原則附加元件。 如需詳細資訊,請參閱在 AKS 叢集上啟用 Azure 原則 (部分機器翻譯)。
若要設定部署保全措施,您必須有
aks-preview
延伸模組的2.0.0b1
版或更新版本。 若要安裝延伸模組,請參閱安裝 aks-preview CLI 延伸模組。 另外,建議您更新 Azure CLI,以確保您已安裝最新版本。若要建立和修改部署保全措施的設定,您需要有訂用帳戶,且其具有 AKS 叢集上的下列權限 (部分機器翻譯):
- Microsoft.Authorization/policyAssignments/write
- Microsoft.Authorization/policyAssignments/read
您必須註冊部署保全措施功能旗標。 若要註冊此功能旗標,請參閱註冊部署保全措施的功能旗標。
安裝 aks-preview CLI 延伸模組
使用
az extension add
命令安裝aks-preview
CLI 擴充功能。az extension add --name aks-preview
更新擴充功能,以確保您已使用
az extension update
命令安裝最新版本。az extension update --name aks-preview
註冊部署保全措施功能旗標
使用
az feature register
命令註冊SafeguardsPreview
功能旗標。az feature register --namespace Microsoft.ContainerService --name SafeguardsPreview
狀態需要幾分鐘的時間才會顯示「已註冊」。
使用
az feature show
命令確認註冊狀態。az feature show --namespace Microsoft.ContainerService --name SafeguardsPreview
當狀態反映「已註冊」時,使用
az provider register
(部分機器翻譯) 命令,重新整理 Microsoft.ContainerService 資源提供者的註冊。az provider register --namespace Microsoft.ContainerService
部署保全措施原則
注意
ReadOnlyRootFilesystem
和 RootfilesystemInitContainers
原則目前僅適用於 Linux。
下表列出當您啟用部署保全措施時,會啟用的原則及其目標 Kubernetes 資源。 您可以在 Azure 入口網站中以 Azure 原則定義的形式檢視目前可用的部署保全措施,也可以在適用於 Azure Kubernetes Service 的 Azure 原則內建定義 (部分機器翻譯) 中檢視。 此集合背後的意圖是建立適用於大部分使用者和使用案例,且常見和通用的最佳做法清單。
部署保全措施原則 | 目標 Kubernetes 資源 | 變動結果 (如果有的話) |
---|---|---|
[預覽]:無法編輯個別節點 | 節點 | N/A |
Kubernetes 叢集容器的 CPU 和記憶體資源限制不應超過指定的限制 | Pod | 將 CPU 資源限制設定為 500m (如果未設定的話),並將記憶體限制設定為 500Mi (如果沒有任何路徑的話) |
[預覽]:必須設定反親和性規則 | Deployment、StatefulSet、ReplicationController、ReplicaSet | N/A |
[預覽]:沒有 AKS 特定標籤 | Deployment、StatefulSet、Replicaset | N/A |
Kubernetes 叢集容器應該只使用允許的映像檔 | Pod | N/A |
[預覽]:已保留系統集區污點 | 節點 | 從使用者節點集區中移除 CriticalAddonsOnly 污點 (如果未設定的話)。 AKS 會使用 CriticalAddonsOnly 污點讓客戶 Pod 遠離系統集區。 此設定可確保 AKS 元件與客戶 Pod 之間有明顯區隔,並防止收回不容許 CriticalAddonsOnly 污點的客戶 Pod。 |
請確認叢集容器已設定整備或活躍度探查 | Pod | N/A |
Kubernetes 叢集應使用容器儲存體介面 (CSI) 驅動程式 StorageClass | StorageClass | N/A |
[預覽]:Kubernetes 叢集容器應該只在映像提取祕密存在時提取映像 | Pod | N/A |
[預覽]:Kubernetes 叢集應該實作精確的 Pod 中斷預算 | Deployment、ReplicaSet、StatefulSet | 將 PodDisruptionBudget 資源中的 maxUnavailable 設定為 1。 |
[預覽]:Kubernetes 叢集服務應該使用唯一選取器 | 服務 | N/A |
[預覽]:Pod 規格中的 ReadOnlyRootFilesystem 設定為 true |
Pod | 將 Pod 規格中的 readOnlyRootFilesystem 設定為 true (如果未設定的話)。 此設定可防止容器寫入到根檔案系統。 |
[預覽]:Pod 規格中的 RootfilesystemInitContainers 設定為 true |
Pod | 將 Pod 規格中的 rootFilesystemInitContainers 設定為 true (如果未設定的話)。 |
[預覽]:Kubernetes 叢集容器映像不應包含最新的映像標籤 | Deployment、StatefulSet、ReplicationController、ReplicaSet | N/A |
[預覽]:Kubernetes 叢集容器映像必須包含 preStop 勾點 | Deployment、StatefulSet、ReplicationController、ReplicaSet | N/A |
如果您想要提交關於部署保全措施的想法或要求,請在 AKS GitHub 存放庫 (英文) 中提出問題,並在標題開頭加上 [deployment safeguards request]
。
啟用部署保全措施
注意
如果您第一次啟用 Azure 原則以使用部署保全措施,您可能需要等候「最多 20 分鐘」,Azure 原則才會生效。
使用部署保全措施的 Enforcement
層級表示您選擇加入將會封鎖和變動的部署。 在啟用 Enforcement
之前,請先想好這些原則是否能與您的 AKS 叢集良好地搭配運作。
在新叢集上啟用部署保全措施
使用 az aks create
命令搭配 --safeguards-level
和 --safeguards-version
旗標,在新叢集上啟用部署保全措施。
如果您想要收到不符合規範的警告,請將 --safeguards-level
設定為 Warning
。 如果您想要拒絕或變動所有不符合規範的部署,請將其設定為 Enforcement
。 若要收到警告,請將 --safeguards-level
設定為 [Warning]。 若要拒絕或變動所有不符合部署保全措施的部署,請將 --safeguards-level
設定為 [Enforcement]。 若要設定部署保全措施版本,請使用 --safeguards-version
旗標。 目前,V2.0.0 是最新版的部署保全措施。
az aks create \
--name myAKSCluster \
--resource-group myResourceGroup \
--enable-addons azure-policy \
--safeguards-level Warning \
--safeguards-version v2.0.0 \
--generate-ssh-keys
在現有叢集上啟用部署保全措施
使用 az aks update
命令搭配 --safeguards-level
和 --safeguards-version
旗標,在已啟用 Azure 原則附加元件的現有叢集上啟用部署保全措施。 如果您想要收到不符合規範的警告,請將 --safeguards-level
設定為 Warning
。 如果您想要拒絕或變動所有不符合規範的部署,請將其設定為 Enforcement
。
az aks update --name myAKSCluster --resource-group myResourceGroup --safeguards-level Enforcement --safeguards-version v2.0.0
如果您想要更新現有叢集的部署保全措施層級,請使用 az aks update
命令,並將 --safeguards-level
旗標設定為 Warning
或 Enforcement
。
az aks update --name myAKSCluster --resource-group myResourceGroup --safeguards-level Enforcement
排除命名空間
您也可以從部署保全措施中排除特定命名空間。 當您排除命名空間時,該命名空間中的活動便不會受到部署保全措施的警告或強制執行所影響。
例如,若要排除命名空間 ns1
和 ns2
,請使用具有 --safeguards-excluded-ns
旗標的命名空間逗號分隔清單,如下列範例所示:
az aks update --name myAKSCluster --resource-group myResourceGroup --safeguards-level Warning --safeguards-version v2.0.0 --safeguards-excluded-ns ns1,ns2
更新您的部署保全措施版本
注意
v2.0.0 是最新版的部署保全措施。
使用 az aks update
命令,並將 --safeguards-version
旗標設定為新版本,以更新您的部署保全措施版本。 下列範例會更新現有叢集以使用 2.0.0 版:
az aks update --name myAKSCluster --resource-group myResourceGroup --safeguards-version v2.0.0
驗證跨叢集的合規性
在部署 Kubernetes 資訊清單後,如果叢集不符合部署保全措施的規範,您便會在 CLI 或終端中看到警告或潛在的拒絕訊息,如下列範例所示:
警告
$ kubectl apply -f pod.yml
Warning: [azurepolicy-k8sazurev2containerenforceprob-0e8a839bcd103e7b96a8] Container <my-container> in your Pod <my-pod> has no <livenessProbe>. Required probes: ["readinessProbe", "livenessProbe"]
Warning: [azurepolicy-k8sazurev2containerenforceprob-0e8a839bcd103e7b96a8] Container <my-container> in your Pod <my-pod> has no <readinessProbe>. Required probes: ["readinessProbe", "livenessProbe"]
Warning: [azurepolicy-k8sazurev1restrictedlabels-67c4210cc58f28acdfdb] Label <{"kubernetes.azure.com"}> is reserved for AKS use only
Warning: [azurepolicy-k8sazurev3containerlimits-a8754961dbd4c1d8b49d] container <my-container> has no resource limits
Warning: [azurepolicy-k8sazurev1containerrestrictedi-bde07e1776cbcc9aa8b8] my-pod in default does not have imagePullSecrets. Unauthenticated image pulls are not recommended.
pod/my-pod created
強制執行
使用部署保全措施變動時,Enforcement
層級會在適用時變動您的 Kubernetes 資源。 不過,您的 Kubernetes 資源仍然需要通過所有保全措施才能成功部署。 如果有任何保全措施原則失敗,您的資源便會遭到拒絕,且不會進行部署。
$ kubectl apply -f pod.yml
Error from server (Forbidden): error when creating ".\pod.yml": admission webhook "validation.gatekeeper.sh" denied the request: [azurepolicy-k8sazurev2containerenforceprob-0e8a839bcd103e7b96a8] Container <my-container> in your Pod <my-pod> has no <livenessProbe>. Required probes: ["readinessProbe", "livenessProbe"]
[azurepolicy-k8sazurev2containerenforceprob-0e8a839bcd103e7b96a8] Container <my-container> in your Pod <my-pod> has no <readinessProbe>. Required probes: ["readinessProbe", "livenessProbe"]
[azurepolicy-k8sazurev2containerallowedimag-1ff6d14b2f8da22019d7] Container image my-image for container my-container has not been allowed.
[azurepolicy-k8sazurev1restrictedlabels-67c4210cc58f28acdfdb] Label <{"kubernetes.azure.com"}> is reserved for AKS use only
[azurepolicy-k8sazurev1containerrestrictedi-bde07e1776cbcc9aa8b8] my-pod in default does not have imagePullSecrets. Unauthenticated image pulls are not recommended.
如果您的 Kubernetes 資源符合適用的變動保全措施,並符合所有其他保全措施需求,資源便會成功部署,如下列範例所示:
$ kubectl apply -f pod.yml
pod/my-pod created
使用 Azure 原則儀表板驗證跨叢集的合規性
若要確認您已套用部署保全措施,並檢查叢集的合規性,請瀏覽至叢集的 Azure 入口網站頁面,然後依序選取 [原則] 和 [移至 Azure 原則]。
從原則和倡議清單中,選取與部署保全措施相關聯的倡議。 您會看到顯示跨 AKS 叢集合規性狀態的儀表板。
注意
若要正確評估跨 AKS 叢集的合規性,Azure 原則倡議的範圍必須限定在叢集的資源群組。
停用部署保全措施
使用 az aks update
命令,並將 --safeguards-level
設定為 Off
,以停用叢集上的部署保全措施。
az aks update --name myAKSCluster --resource-group myResourceGroup --safeguards-level Off
--
常見問題集
我第一次使用 Azure 原則來啟用部署保全措施。 為什麼我看不到任何警告? 為什麼我的 Pod 沒有遭到拒絕?
Azure 原則在首次啟用後,最多可能需要 35 分鐘才能與您的叢集同步。
我剛從警告切換到強制執行。 這會立即生效嗎?
在切換部署保全措施層級時,可能需要等候最多 15 分鐘,新層級才會生效。
我可以建立自己的變動嗎?
否。 如果您有關於保全措施的想法,請在 AKS GitHub 存放庫 (英文) 中提出問題,並在標題開頭加上 [deployment safeguards request]
。
我可以挑選想在強制執行中使用的變動嗎?
否。 部署保全措施採用全有全無機制。 一旦開啟 [警告] 或 [強制執行],所有保全措施都會啟用。
為何即使部署資源未遵循最佳做法仍會獲得承認?
部署保全措施會透過 Azure 原則控制來強制執行最佳做法標準,並具有針對 Kubernetes 資源進行驗證的原則。 為了評估和強制執行叢集元件,Azure 原則會擴充 Gatekeeper (英文)。 Gatekeeper 強制執行目前還在 fail-open
模式 (英文) 下運作。 由於無法保證 Gatekeeper 會回應我們的網路通話,因此我們會確保在該情況下略過驗證,讓拒絕不會封鎖您的部署。
若要深入了解,請參閱 Gatekeeper 中的工作負載驗證 (英文)。
下一步
- 深入了解用於操作 AKS 叢集的最佳做法。