事件
使用 Azure 原則來保護 Azure Kubernetes Service (AKS) 叢集
您可以使用 Azure 原則以在 Azure Kubernetes Service (AKS) 叢集上套用和強制執行內建安全性原則。 Azure 原則有助於大規模強制執行組織標準及評定合規性。 在您安裝適用於 AKS 的 Azure 原則附加元件之後,可以將個別的原則定義或稱為「方案」(有時稱為「原則集」) 的原則定義群組套用至叢集。 如需 AKS 原則和方案定義的完整清單,請參閱適用於 AKS 的 Azure 原則內建定義。
此文章說明如何將原則定義套用至叢集,並驗證已強制執行那些指派。
- 本文假設您具有現有 AKS 叢集。 如果您需要 AKS 叢集,則可以使用 Azure CLI、Azure PowerShell 或 Azure 入口網站予以建立。
- 您需要在 AKS 叢集上安裝的適用於 AKS 的 Azure 原則附加元件。
您可以使用下列步驟,以在 Azure 入口網站中套用原則定義或方案:
- 在 Azure 入口網站中,導覽至稱為 [原則] 的 Azure 原則服務。
- 在 [Azure 原則] 頁面的左窗格中,選取 [定義]。
- 在 [類別] 下方,選取 [
Kubernetes
]。 - 選擇您想要套用的原則定義或方案。 在此範例中,選取 [適用於以 Linux 為基礎之工作負載的 Kubernetes 叢集 Pod 安全性基準標準] 方案。
- 選取指派。
- 將 [範圍] 設定為已啟用 Azure 原則附加元件的 AKS 叢集資源群組。
- 選取 [參數] 頁面,然後將 [效果] 從 [
audit
] 更新為 [deny
],以封鎖違反基準方案的新部署。 您也可以新增要從評估中排除的額外命名空間。 針對此範例,請保留預設值。 - 選取 [檢閱 + 建立] > 和 [建立] 來提交原則指派。
自訂原則可讓您定義使用 Azure 的規則。 例如,您可以強制執行下列類型的規則:
- 安全性作法
- 成本管理
- 組織專屬規則 (例如命名或位置)
建立自訂原則之前,請檢查常見模式和範例的清單,以查看是否已涵蓋您的案例。
自訂原則定義是以 JSON 撰寫。 若要深入了解如何建立自訂原則,請參閱 Azure 原則定義結構和建立自訂原則定義。
注意
Azure 原則現在會利用稱為 templateInfo 的新屬性,讓您能夠定義條件約束範本的來源類型。 當您在原則定義中定義 templateInfo 時,您不需要定義 constraintTemplate 或 constraint 屬性。 您仍然需要定義 apiGroups 和 kinds。 如需詳細資訊,請參閱了解 Azure 原則效果。
在您建立自訂原則定義之後,請參閱指派原則定義,以取得將原則指派給 Kubernetes 叢集的逐步解說。
執行下列
kubectl get
命令,以確認已將原則指派套用至您的叢集。kubectl get constrainttemplates
注意
原則指派最多可能需要 20 分鐘才能同步到每個叢集。
您的輸出應該與下列範例輸出類似:
NAME AGE k8sazureallowedcapabilities 23m k8sazureallowedusersgroups 23m k8sazureblockhostnamespace 23m k8sazurecontainerallowedimages 23m k8sazurecontainerallowedports 23m k8sazurecontainerlimits 23m k8sazurecontainernoprivilege 23m k8sazurecontainernoprivilegeescalation 23m k8sazureenforceapparmor 23m k8sazurehostfilesystem 23m k8sazurehostnetworkingports 23m k8sazurereadonlyrootfilesystem 23m k8sazureserviceallowedports 23m
讓我們先測試當您使用 privileged: true
的資訊安全內容對 Pod 進行排程時會發生什麼情況。 此資訊安全內容會提升 Pod 的權限。 此方案不允許具特殊權限的 Pod,因此會拒絕要求,進而導致拒絕部署。
建立名為
nginx-privileged.yaml
的檔案,並貼入下列 YAML 資訊清單。apiVersion: v1 kind: Pod metadata: name: nginx-privileged spec: containers: - name: nginx-privileged image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine securityContext: privileged: true
使用
kubectl apply
命令來建立 Pod,並指定 YAML 資訊清單的名稱。kubectl apply -f nginx-privileged.yaml
預期無法排程 Pod,如下列範例輸出所示:
Error from server ([denied by azurepolicy-container-no-privilege-00edd87bf80f443fa51d10910255adbc4013d590bec3d290b4f48725d4dfbdf9] Privileged container is not allowed: nginx-privileged, securityContext: {"privileged": true}): error when creating "privileged.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [denied by azurepolicy-container-no-privilege-00edd87bf80f443fa51d10910255adbc4013d590bec3d290b4f48725d4dfbdf9] Privileged container is not allowed: nginx-privileged, securityContext: {"privileged": true}
Pod 不會到達排程階段,因此在您繼續之前,不會有任何需要刪除的資源。
在上一個範例中,容器映像會自動嘗試使用根來將 NGINX 繫結至連接埠 80。 原則方案拒絕此要求,因此無法啟動 Pod。 現在,請在不具特殊權限存取權的情況下,嘗試執行相同的 NGINX Pod。
建立名為
nginx-unprivileged.yaml
的檔案,並貼入下列 YAML 資訊清單。apiVersion: v1 kind: Pod metadata: name: nginx-unprivileged spec: containers: - name: nginx-unprivileged image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
使用
kubectl apply
命令來建立 Pod,並指定 YAML 資訊清單的名稱。kubectl apply -f nginx-unprivileged.yaml
使用
kubectl get pods
命令來檢查 Pod 的狀態。kubectl get pods
您的輸出應該類似下列範例輸出,其顯示 Pod 已成功排程且狀態為「正在執行」:
NAME READY STATUS RESTARTS AGE nginx-unprivileged 1/1 Running 0 18s
此範例顯示的基準方案只會影響集合中違反原則的部署。 允許的部署將能繼續運作。
使用
kubectl delete
命令來刪除 NGINX 不具特殊權限的 Pod,並指定 YAML 資訊清單的名稱。kubectl delete -f nginx-unprivileged.yaml
您可以使用下列步驟,以在 Azure 入口網站中移除基準方案:
- 導覽至 Azure 入口網站上的 [原則] 窗格。
- 選取 [指派]。
- 選取 [適用於以 Linux 為基礎之工作負載的 Kubernetes 叢集 Pod 安全性基準標準] 方案旁邊的 [...] 按鈕。
- 選取 [刪除指派]。
如需 Azure 原則運作方式的詳細資訊,請參閱下列文章:
其他資源
訓練
模組
設定 Azure Kubernetes Service 叢集 - Training
使用 Azure 原則大規模在您的 Kubernetes 叢集上強制執行原則和保護。 Azure 原則可確保您的叢集在組織中安全、符合規範且一致。
認證
Microsoft Certified: Azure Security Engineer Associate - Certifications
示範實作安全性控制、維護組織的安全性狀態以及識別和修復安全性漏洞所需的技能。