使用 Azure 原則來保護 Azure Kubernetes Service (AKS) 叢集

文章
08/02/2024

您可以使用 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 叢集的逐步解說。

驗證 Azure 原則正在執行

執行下列 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

驗證對具特殊權限 Pod 的拒絕

讓我們先測試當您使用 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 不會到達排程階段，因此在您繼續之前，不會有任何需要刪除的資源。

測試建立不具特殊權限的 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 原則運作方式的詳細資訊，請參閱下列文章：

分享方式：