了解適用於 Kubernetes 叢集的 Azure 原則 $部分機器翻譯$

發行項
10/01/2024

Azure 原則會延伸 Gatekeeper v3 (Open Policy Agent (OPA) 的許可控制站 Webhook)，以集中且一致的方式，對叢集元件進行大規模的政策實施和保護。叢集元件包括 Pod、容器和命名空間。

Azure 原則可讓您從一個位置管理和報告 Kubernetes 叢集元件的合規性狀態。藉由使用 Azure 原則的附加元件或延伸模組，可透過 Azure 原則功能來增強控管叢集元件，例如使用選取器和覆寫安全原則推出和復原。

適用於 Kubernetes 的 Azure 原則支援下列叢集環境：

Azure Kubernetes Service (AKS)，透過 Azure 原則的 AKS 附加元件
已啟用 Kubernetes 的 Azure Arc，透過 Azure 原則的 Arc 延伸模組

重要

Azure 原則附加元件 Helm 模型和 AKS 引擎的附加元件已被取代。遵循指示來移除附加元件。

概觀

藉由在 Kubernetes 叢集上安裝 Azure 原則的附加元件或延伸項目，Azure 原則會制定下列功能：

使用 Azure 原則服務檢查叢集的原則指派。
將原則定義部署至叢集，作為條件約束範本和限制式自訂資源或變動範本資源 (視原則定義內容而定)。
將稽核和合規性詳細資料回報給 Azure 原則服務。

若要啟用 Azure 原則並與 Kubernetes 叢集搭配使用，請採取下列動作：

設定 Kubernetes 叢集，並針對啟用 Arc 的 Kubernetes 叢集，安裝 Azure Kubernetes Service (AKS) 附加元件，或 Azure 原則延伸項目 (視叢集類型而定)。

注意

如需了解安裝常見問題，請參閱疑難排解 - Azure 原則附加元件。
建立或使用面向 Kubernetes 的範例 Azure 原則定義
將定義指派給 Kubernetes 叢集
等候驗證
記錄和疑難排解
檢閱常見問題一節中的限制和建議

安裝 AKS 的 Azure 原則附加元件

適用於 AKS 的 Azure 原則附加元件是 Kubernetes 1.27 版的一部分，具有長期支援 (LTS)。

必要條件

註冊資源提供者和預覽功能。
- Azure 入口網站︰
  
  請註冊Microsoft.PolicyInsights資源提供者。如需相關步驟，請參閱資源提供者和類型。
- Azure CLI：
```
# Log in first with az login if you're not using Cloud Shell

# Provider register: Register the Azure Policy provider
az provider register --namespace Microsoft.PolicyInsights
```
您需要安裝並設定 Azure CLI 2.12.0 版或更新版本。若要尋找版本，請執行 az --version 命令。如果您需要安裝或升級，請參閱如何安裝 Azure CLI。
AKS 叢集必須是 Azure Kubernetes Service (AKS) 中支援的 Kubernetes 版本。使用下列指令碼來驗證您的 AKS 叢集版本：
```
# Log in first with az login if you're not using Cloud Shell

# Look for the value in kubernetesVersion
az aks list
```
開啟 Azure 原則延伸模組的連接埠。 Azure 原則延伸模組會使用這些網域和連接埠擷取原則定義和指派，並將叢集的合規性回報給 Azure 原則。

網域連接埠

data.policy.core.windows.net 443

store.policy.core.windows.net 443

login.windows.net 443

dc.services.visualstudio.com 443

網域	連接埠
`data.policy.core.windows.net`	`443`
`store.policy.core.windows.net`	`443`
`login.windows.net`	`443`
`dc.services.visualstudio.com`	`443`

完成必要條件後，請在您想要管理的 AKS 叢集中安裝 Azure 原則附加元件。

Azure 入口網站
1. 選取 [所有服務]，然後搜尋並選取 [Kubernetes 服務]，以在 Azure 入口網站中啟動 AKS 服務。
2. 選取您的其中一個 AKS 叢集。
3. 選取 [Kubernetes 服務] 頁面左側的 [原則]。
4. 在主頁面中，選取 [啟用附加元件] 按鈕。

Azure CLI

# Log in first with az login if you're not using Cloud Shell

az aks enable-addons --addons azure-policy --name MyAKSCluster --resource-group MyResourceGroup

若要驗證附加元件安裝是否成功，以及 azure-policy 和 gatekeeper Pod 是否正在執行，請執行下列命令：

# azure-policy pod is installed in kube-system namespace
kubectl get pods -n kube-system

# gatekeeper pod is installed in gatekeeper-system namespace
kubectl get pods -n gatekeeper-system

最後，請執行此 Azure CLI 命令，並將 <rg> 取代為您的資源群組名稱，然後將 <cluster-name> 取代為您的 AKS 叢集名稱：az aks show --query addonProfiles.azurepolicy -g <rg> -n <cluster-name>，以確認是否已安裝最新的附加元件。對於使用服務主體的叢集，結果應類似於下列輸出：

{
  "config": null,
  "enabled": true,
  "identity": null
}

以及使用受控識別之叢集的下列輸出：

 {
   "config": null,
   "enabled": true,
   "identity": {
     "clientId": "########-####-####-####-############",
     "objectId": "########-####-####-####-############",
     "resourceId": "<resource-id>"
   }
 }

為 Azure Arc 啟用的 Kubernetes 安裝 Azure 原則延伸功能

適用於 Kubernetes 的 Azure 原則可以從單一位置管理和報告 Kubernetes 叢集的合規性狀態。使用已啟用 Arc 的 Kubernetes 叢集的 Azure 原則延伸模組，您可以控管已啟用 Arc 的 Kubernetes 叢集元件，例如 Pod 和容器。

本文說明如何建立、顯示延伸模組狀態以及刪除適用於 Kubernetes 的 Azure 原則的延伸模組。

如需延伸模組平台的概觀，請參閱 Azure Arc 叢集延伸模組。

必要條件

如果您已使用 Helm 直接在 Azure Arc 叢集上部署適用於 Kubernetes 的 Azure 原則，而不需延伸模組，請遵循所列指示來刪除 Helm 圖表。刪除完畢之後，就可以繼續進行。

請確定您的 Kubernetes 叢集是支援的散發套件。

注意

下列 Kubernetes 散發套件支援適用於 Arc 延伸模組的 Azure 原則。
請確定您符合此處所列的 Kubernetes 延伸模組適用的所有通用必要條件，包括將您的叢集連線到 Azure Arc。

注意

這些區域中已啟用 Arc 的 Kubernetes 叢集支援 Azure 原則延伸模組。
開啟 Azure 原則延伸模組的連接埠。 Azure 原則延伸模組會使用這些網域和連接埠擷取原則定義和指派，並將叢集的合規性回報給 Azure 原則。

網域連接埠

data.policy.core.windows.net 443

store.policy.core.windows.net 443

login.windows.net 443

dc.services.visualstudio.com 443

網域	連接埠
`data.policy.core.windows.net`	`443`
`store.policy.core.windows.net`	`443`
`login.windows.net`	`443`
`dc.services.visualstudio.com`	`443`

在安裝 Azure 原則延伸模組或啟用任何服務功能之前，您的訂用帳戶必須啟用 Microsoft.PolicyInsights 資源提供者。

注意

若要啟用資源提供者，請遵循資源提供者和類型中的步驟，或執行 Azure CLI 或 Azure PowerShell 命令。

Azure CLI

# Log in first with az login if you're not using Cloud Shell
# Provider register: Register the Azure Policy provider
az provider register --namespace 'Microsoft.PolicyInsights'

Azure PowerShell

# Log in first with Connect-AzAccount if you're not using Cloud Shell

# Provider register: Register the Azure Policy provider
Register-AzResourceProvider -ProviderNamespace 'Microsoft.PolicyInsights'

建立 Azure 原則延伸模組

注意

建立 Azure 原則延伸模組時，請注意下列事項：

系統會預設啟用自動升級，這會在部署任何新的變更時，將 Azure 原則延伸模組次要版本更新。
以參數傳遞至 connectedk8s 的任何 Proxy 變數，都會散佈到 Azure 原則延伸模組以支援輸出 Proxy。

若要為已啟用 Arc 的叢集建立延伸模組執行個體，請執行下列命令，用您的值取代 <>：

az k8s-extension create --cluster-type connectedClusters --cluster-name <CLUSTER_NAME> --resource-group <RESOURCE_GROUP> --extension-type Microsoft.PolicyInsights --name <EXTENSION_INSTANCE_NAME>

範例：

az k8s-extension create --cluster-type connectedClusters --cluster-name my-test-cluster --resource-group my-test-rg --extension-type Microsoft.PolicyInsights --name azurepolicy

範例輸出：

{
  "aksAssignedIdentity": null,
  "autoUpgradeMinorVersion": true,
  "configurationProtectedSettings": {},
  "configurationSettings": {},
  "customLocationSettings": null,
  "errorInfo": null,
  "extensionType": "microsoft.policyinsights",
  "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-test-rg/providers/Microsoft.Kubernetes/connectedClusters/my-test-cluster/providers/Microsoft.KubernetesConfiguration/extensions/azurepolicy",
 "identity": {
    "principalId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "tenantId": null,
    "type": "SystemAssigned"
  },
  "location": null,
  "name": "azurepolicy",
  "packageUri": null,
  "provisioningState": "Succeeded",
  "releaseTrain": "Stable",
  "resourceGroup": "my-test-rg",
  "scope": {
    "cluster": {
      "releaseNamespace": "kube-system"
    },
    "namespace": null
  },
  "statuses": [],
  "systemData": {
    "createdAt": "2021-10-27T01:20:06.834236+00:00",
    "createdBy": null,
    "createdByType": null,
    "lastModifiedAt": "2021-10-27T01:20:06.834236+00:00",
    "lastModifiedBy": null,
    "lastModifiedByType": null
  },
  "type": "Microsoft.KubernetesConfiguration/extensions",
  "version": "1.1.0"
}

顯示 Azure 原則延伸模組

若要檢查延伸模組執行個體是否建立成功，並檢查延伸模組中繼資料，請執行下列命令，用您的值取代 <>：

az k8s-extension show --cluster-type connectedClusters --cluster-name <CLUSTER_NAME> --resource-group <RESOURCE_GROUP> --name <EXTENSION_INSTANCE_NAME>

範例：

az k8s-extension show --cluster-type connectedClusters --cluster-name my-test-cluster --resource-group my-test-rg --name azurepolicy

若要驗證延伸模組是否安裝成功，以及 azure-policy 和 gatekeeper Pod 是否正在執行，請執行下列命令：

# azure-policy pod is installed in kube-system namespace
kubectl get pods -n kube-system

# gatekeeper pod is installed in gatekeeper-system namespace
kubectl get pods -n gatekeeper-system

刪除 Azure 原則延伸模組

若要刪除延伸模組執行個體，請執行下列命令，用您的值取代 <>：

az k8s-extension delete --cluster-type connectedClusters --cluster-name <CLUSTER_NAME> --resource-group <RESOURCE_GROUP> --name <EXTENSION_INSTANCE_NAME>

建立原則定義

用於管理 Kubernetes 的 Azure 原則語言結構會遵循現有原則定義的結構。 Azure 原則的內建原則程式庫中提供了可指派的範例定義檔案，可用控管叢集元件。

適用於 Kubernetes 的 Azure 原則也支援在元件層級為 Azure Kubernetes Service 叢集和已啟用 Azure Arc 的 Kubernetes 叢集建立自訂定義。 Gatekeeper 社群程式庫中提供了條件約束範本和變動範本範例。 Azure 原則的 Visual Studio Code 延伸模組可用來協助將現有的條件約束範本或變動範本轉譯為自訂 Azure 原則定義。

使用 Microsoft.Kubernetes.Data 的資源提供者模式時，會使用稽核、拒絕、已停用和變動效果來管理 Kubernetes 叢集。

稽核和拒絕必須提供 details 使用 OPA 條件約束架構和 Gatekeeper v3 的特定屬性。

作為原則定義中的 details.templateInfo 或 details.constraintInfo 屬性的一部分，Azure 原則會將這些 CustomResourceDefinitions (CRD) 的 URI 或 Base64Encoded 值傳遞至附加元件。 Rego 是 OPA 和 Gatekeeper 向 Kubernetes 叢集驗證要求時的支援語言。藉由支援現有的 Kubernetes 管理標準，Azure 原則可讓您重複使用現有的規則，並可將其與 Azure 原則結合，以取得統一的雲端合規性報告體驗。如需詳細資訊，請參閱什麼是 Rego？。

指派原則定義

若要將原則定義指派給 Kube 叢集，您必須獲指派適當的 Azure 角色型存取控制 (Azure RBAC) 原則指派作業。 Azure 內建角色資源原則參與者和擁有者具有這些作業。若要深入了解，請參閱 Azure 原則中的 Azure RBAC 權限。

使用 Azure 入口網站搭配下列步驟，尋找用於管理叢集的內建原則定義。如果使用自訂原則定義，請依名稱或您所建立的類別來搜尋它。

在 Azure 入口網站中啟動 Azure 原則服務。在左側窗格中選取 [所有服務]，然後搜尋並選取 [原則]。
在 [Azure 原則] 頁面的左窗格中，選取 [定義]。
從 [類別] 下拉式清單方塊中，使用 [全選] 來清除篩選，然後選取 [Kubernetes]。
選取原則定義，然後選取 [指派] 按鈕。
將 [範圍] 設定為套用原則指派之 Kube 叢集的管理群組、訂用帳戶，或資源群組。

注意

指派 Kubernetes 適用的 Azure 原則定義時，範圍必須包含叢集資源。
為原則指派指定一個名稱和描述，您可以輕鬆地用來識別它。
將原則強制執行設為下列其中一個值：
- [已啟用]: 在叢集上強制執行原則。會拒絕具有違規的 Kube 許可要求。
- [已啟用]: 不要在叢集上強制執行原則。會拒絕具有違規的 Kube 許可要求。合規性評定結果仍可供使用。將新的原則定義推出到執行中的叢集時，[已停用] 選項有助於測試原則定義，因為具有違規的許可要求不會遭到拒絕。
選取 [下一步]。
設定參數值
- 若要從原則評估中排除 Kubernetes 命名空間，請在 [命名空間排除] 參數中指定命名空間的清單。建議排除：kube-system、gatekeeper-system 和 azure-arc。
選取 [檢閱 + 建立]。

或者，使用指派原則 - 入口網站快速入門來尋找並指派 Kubernetes 原則。搜尋 Kubernetes 原則定義，而不是 audit vms 範例。

重要

內建原則定義適用於 Kubernetes 類別中的 Kubernetes 叢集。如需內建原則定義的清單，請參閱 Kubernetes 範例。

原則評估

此附加元件會每隔 15 分鐘向 Azure 原則服務檢查原則指派中的變更。在此重新整理週期期間，附加元件會檢查是否有變更。這些變更會觸發條件約束範本和條件約束的建立、更新或刪除。

在 Kubernetes 叢集中，如果命名空間有適合叢集的標籤，則具有違規的許可要求不會遭到拒絕。合規性評定結果仍可供使用。

已啟用 Azure Arc 的 Kubernetes 叢集：admission.policy.azure.com/ignore

注意

雖然叢集管理員可能具備建立和更新 Azure 原則附加元件所安裝之條件約束範本和條件約束資源的權限，但這些不是支援的案例，因為手動更新會遭到覆寫。 Gatekeeper 會繼續評估安裝附加元件並指派 Azure 原則的原則定義之前已存在的原則。

每隔 15 分鐘，附加元件就會呼叫叢集的完整掃描。在收集完整掃描的詳細資料以及嘗試變更叢集的任何即時評估 (由 Gatekeeper 執行) 之後，此附加元件會將結果回報給 Azure 原則以納入合規性詳細資料，例如任何 Azure 原則指派。在稽核週期期間，只會傳回作用中原則指派的結果。稽核結果也可以視為失敗條件約束 [狀態] 欄位中所列的違規。如需不符合規範資源的詳細資訊，請參閱資源提供者模式的元件詳細資料。

注意

在 Kubernetes 叢集 Azure 原則中，每個合規性報告都包含過去 45 分鐘內的所有違規。時間戳記會指出違規發生的時間。

一些其他考量：

如果叢集訂用帳戶已向適用於雲端的 Microsoft Defender 註冊，則會自動在叢集上套用適用於雲端的 Microsoft Defender Kubernetes 原則。
在具有現有 Kubernetes 資源的叢集上套用拒絕原則時，任何不符合新原則規範的預先存在資源會繼續執行。當不符合規範的資源重新排程在不同的節點上時，Gatekeeper 會封鎖資源建立。
當叢集具有驗證資源的拒絕原則時，使用者在建立部署時看不到拒絕訊息。例如，請考慮包含和 Pod 的 replicasets Kubernetes 部署。當使用者執行 kubectl describe deployment $MY_DEPLOYMENT 時，它不會將拒絕訊息當作事件的一部分傳回。不過 kubectl describe replicasets.apps $MY_DEPLOYMENT 會傳回與拒絕相關聯的事件。

注意

在原則評估期間可能會包含 Init 容器。若要查看是否包含 Init 容器，請檢閱 CRD 以取得下列或類似的宣告：

input_containers[c] {
   c := input.review.object.spec.initContainers[_]
}

條件約束範本衝突

如果條件約束範本具有相同的資源中繼資料名稱，但原則定義會參考不同位置的來源，則會將原則定義視為衝突。範例：兩個原則定義會參考儲存在不同來源位置的同一個 template.yaml 檔案，例如 Azure 原則範本存放區 (store.policy.core.windows.net) 和 GitHub。

當指派原則定義及其條件約束範本，但尚未安裝在叢集且發生衝突時，會將其回報為衝突，而且在解決衝突之前不會安裝到叢集中。同樣地，任何現有的原則定義及其已在叢集上、而且與新指派原則定義衝突的條件約束範本，都會繼續正常運作。如果更新現有的指派，而且無法同步處理條件約束範本，叢集也會標示為衝突。如需所有衝突訊息，請參閱 AKS 資源提供者模式合規性原因

記錄

做為 Kubernetes 控制器/容器，azure-policy 和 gatekeeper Pod 都會將記錄保留在 Kubernetes 叢集中。一般而言，azure-policy 記錄可用來針對叢集和合規性報告的原則擷取問題進行疑難排解。 gatekeeper-controller-manager Pod 記錄可用來針對執行階段拒絕進行疑難排解。 gatekeeper-audit Pod 記錄可用來針對現有資源的稽核進行疑難排解。記錄可以在 Kubernetes 叢集的 [見解] 頁面中公開。如需詳細資訊，請參閱使用適用於容器的 Azure 監視器來監視您的 Kubernetes 叢集效能。

若要檢視附加元件記錄，請使用 kubectl：

# Get the azure-policy pod name installed in kube-system namespace
kubectl logs <azure-policy pod name> -n kube-system

# Get the gatekeeper pod name installed in gatekeeper-system namespace
kubectl logs <gatekeeper pod name> -n gatekeeper-system

如果您嘗試針對出現在合規性結果中的特定 ComplianceReasonCode 進行疑難排解，則可以在 azure-policy Pod 記錄中搜尋該程式碼以查看完整的隨附錯誤。

如需詳細資訊，請參閱 Gatekeeper 文件中的 Gatekeeper 偵錯。

檢視 Gatekeeper 成品

附加元件下載原則指派並將條件約束範本和條件約束安裝在叢集後，會使用原則指派識別碼和原則定義識別碼等 Azure 原則資訊來標注這兩者。若要設定用戶端以檢視附加元件相關成品，請執行下列步驟：

設定叢集的 kubeconfig。

若是 Azure Kubernetes Service 叢集，請使用下列的 Azure CLI：

# Set context to the subscription
az account set --subscription <YOUR-SUBSCRIPTION>

# Save credentials for kubeconfig into .kube in your home folder
az aks get-credentials --resource-group <RESOURCE-GROUP> --name <CLUSTER-NAME>

測試叢集連線。

執行 kubectl cluster-info 命令。成功執行後，會讓每個服務以執行所在位置的 URL 回應。

檢視附加元件條件約束範本

若要檢視附加元件下載的條件約束範本，請執行 kubectl get constrainttemplates。以 k8sazure 開頭的條件約束範本是由附加元件所安裝。

檢視附加元件變動範本

若要檢視附加元件下載的變動範本，請執行 kubectl get assign、kubectl get assignmetadata 和 kubectl get modifyset。

取得 Azure 原則對應

若要識別下載至叢集的條件約束範本與原則定義之間的對應，請使用 kubectl get constrainttemplates <TEMPLATE> -o yaml。結果看起來會類似以下的輸出：

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
    annotations:
    azure-policy-definition-id: /subscriptions/<SUBID>/providers/Microsoft.Authorization/policyDefinitions/<GUID>
    constraint-template-installed-by: azure-policy-addon
    constraint-template: <URL-OF-YAML>
    creationTimestamp: "2021-09-01T13:20:55Z"
    generation: 1
    managedFields:
    - apiVersion: templates.gatekeeper.sh/v1beta1
    fieldsType: FieldsV1
...

<SUBID> 是訂用帳戶識別碼，而 <GUID> 是對應原則定義的識別碼。 <URL-OF-YAML> 是附加元件下載後要安裝在叢集上的條件約束範本的來源位置。

有了附加元件下載的條件約束範本名稱後，就可以使用該名稱來查看相關的條件約束。使用 kubectl get <constraintTemplateName> 取得清單。附加元件所安裝的條件約束從 azurepolicy- 開始。

檢視條件約束詳細資料

條件約束擁有關於違規與對應至原則定義和指派的詳細資料。若要查看詳細資料，請使用 kubectl get <CONSTRAINT-TEMPLATE> <CONSTRAINT> -o yaml。結果看起來會類似以下的輸出：

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAzureContainerAllowedImages
metadata:
  annotations:
    azure-policy-assignment-id: /subscriptions/<SUB-ID>/resourceGroups/<RG-NAME>/providers/Microsoft.Authorization/policyAssignments/<ASSIGNMENT-GUID>
    azure-policy-definition-id: /providers/Microsoft.Authorization/policyDefinitions/<DEFINITION-GUID>
    azure-policy-definition-reference-id: ""
    azure-policy-setdefinition-id: ""
    constraint-installed-by: azure-policy-addon
    constraint-url: <URL-OF-YAML>
  creationTimestamp: "2021-09-01T13:20:55Z"
spec:
  enforcementAction: deny
  match:
    excludedNamespaces:
    - kube-system
    - gatekeeper-system
    - azure-arc
  parameters:
    imageRegex: ^.+azurecr.io/.+$
status:
  auditTimestamp: "2021-09-01T13:48:16Z"
  totalViolations: 32
  violations:
  - enforcementAction: deny
    kind: Pod
    message: Container image nginx for container hello-world has not been allowed.
    name: hello-world-78f7bfd5b8-lmc5b
    namespace: default
  - enforcementAction: deny
    kind: Pod
    message: Container image nginx for container hello-world has not been allowed.
    name: hellow-world-89f8bfd6b9-zkggg

對附加元件進行疑難排解

如需為適用於 Kubernetes 的附加元件疑難排解的詳細資訊，請參閱 Azure 原則疑難排解文章中的 Kubernetes 一節。

如需 Arc 延伸模組相關問題的 Azure 原則延伸模組，請參閱：

已啟用 Azure Arc 的 Kubernetes 疑難排解

如需 Azure 原則相關問題，請參閱：

AKS 變更記錄的 Azure 原則附加元件

適用於 AKS 的 Azure 原則附加元件有一個版本號碼，指出附加元件映像版本。由於附加元件上新增了功能支援，版本號碼就會增加。

本節會協助您識別叢集上安裝的附加元件版本，並共用每個 AKS 叢集所安裝 Azure 原則附加元件版本的歷程記錄資料表。

識別叢集上安裝的附加元件版本

Azure 原則附加元件對每個版本使用標準語意化版本控制系統結構描述。若要識別正在使用的 Azure 原則附加元件版本，您可以執行下列命令：kubectl get pod azure-policy-<unique-pod-identifier> -n kube-system -o json | jq '.spec.containers[0].image'

若要識別 Azure 原則附加元件所使用的 Gatekeeper 版本，您可以執行下列命令：kubectl get pod gatekeeper-controller-<unique-pod-identifier> -n gatekeeper-system -o json | jq '.spec.containers[0].image'

最後，若要識別所使用的 AKS 叢集版本，請遵循連結的 AKS 指導。

每個 AKS 叢集版本可用的附加元件版本

1.9.1

增強安全性。

發行於 2025 年 1 月
Kubernetes 1.27+
閘道守衛 3.17.1

1.8.0

原則現在可以用來評估 CONNECT 作業，例如拒絕 exec。請注意，不符合規範的 CONNECT 作業沒有可用的棕色欄位合規性，因此以 CONNECT 為目標的原則不是任何作業。

增強安全性。

發行於 2024 年 11 月
Kubernetes 1.27+
閘道守衛 3.17.1

1.7.1

CEL 和 VAP 簡介。 Common Expression Language （CEL）是 Kubernetes 原生運算式語言，可用來宣告原則的驗證規則。驗證許可原則（VAP）功能提供樹狀結構內原則評估、減少許可要求延遲，以及改善可靠性和可用性。支持的驗證動作包括 Deny、Warn 和 Audit。允許 CEL/VAP 的自定義原則撰寫，而且現有的使用者不需要將 Rego 轉換成 CEL，因為它們都會受到支援，並用來強制執行原則。若要使用 CEL 和 VAP，用戶必須在命名空間的功能旗標 AKS-AzurePolicyK8sNativeValidation 中 Microsoft.ContainerService 註冊。如需詳細資訊，請檢視 Gatekeeper 檔。

增強安全性。

發行於 2024 年 9 月
Kubernetes 1.27+ （VAP 世代僅支援 1.30+）
閘道守衛 3.17.1

1.7.0

引進擴充功能，這是一種左移功能，可讓您預先了解您的工作負載資源 (部署、ReplicaSets、作業等) 是否會產生許可的 Pod。擴充功能不應變更原則的行為；相反地，它只會轉移 Gatekeeper 對 Pod 範圍原則的評估，以在工作負載許可時間發生，而不是在 Pod 許可時間。不過，若要執行此評估，它必須產生並評估以工作負載中定義的 Pod 規格為基礎的模擬 Pod，其元數據可能不完整。例如，假設 Pod 不會包含適當的擁有者參考。因為原則行為變更的風險很小，因此預設會停用擴充功能。若要啟用指定原則定義的擴充功能，請將 .policyRule.then.details.source 設定為 All。內建即將更新，以啟用此欄位的參數化。如果您測試原則定義，並發現為了評估目的而產生的假設狀況 Pod 不完整，您也可以使用來源 Generated 的變動來變動假設狀況 Pod。如需此選項的詳細資訊，請檢視 Gatekeeper 文件 (英文)。

擴充目前僅適用於 AKS 叢集，而非 Arc 叢集。

增強安全性。

發行日期：2024 年 7 月
Kubernetes 1.27+
Gatekeeper 3.16.3

1.6.1

增強安全性。

2024 年 5 月發行
Gatekeeper 3.14.2

1.5.0

增強安全性。

2024 年 5 月發行
Kubernetes 1.27+
Gatekeeper 3.16.3

1.4.0

預設會啟用變動和外部資料。在最壞的情況下，額外的變動 Webhook 和新增的驗證 Webhook 逾時上限可能會增加叫用的延遲。同時引進在合規性結果中檢視原則定義和設定定義版本的支援。

2024 年 5 月發行
Kubernetes 1.25+
Gatekeeper 3.14.0

1.3.0

引進原則發生錯誤時的錯誤狀態，使其與不符合規範狀態的原則區別開來。新增 v1 條件約束範本的支援，以及在變動原則中使用 excludedNamespaces 參數。在安裝後新增條件約束範本的錯誤狀態檢查。

發行日期︰2024 年 2 月
Kubernetes 1.25+
Gatekeeper 3.14.0

1.2.1

發行日期︰2023 年 10 月
Kubernetes 1.25+
Gatekeeper 3.13.3

1.1.0

發行日期：2023 年 7 月
Kubernetes 1.27+
Gatekeeper 3.11.1

1.0.1

發行日期︰2023 年 6 月
Kubernetes 1.24+
Gatekeeper 3.11.1

1.0.0

適用於 Kubernetes 的 Azure 原則現在支援變動以大規模補救 AKS 叢集！

移除附加元件

從 AKS 移除附加元件

若要從 AKS 叢集中移除 Azure 原則附加元件，請使用 Azure 入口網站或 Azure CLI：

Azure 入口網站
1. 選取 [所有服務]，然後搜尋並選取 [Kubernetes 服務]，以在 Azure 入口網站中啟動 AKS 服務。
2. 選取您想要停用 Azure 原則附加元件的 AKS 叢集。
3. 選取 [Kubernetes 服務] 頁面左側的 [原則]。
4. 在主頁面中，選取 [停用附加元件] 按鈕。

Azure CLI

# Log in first with az login if you're not using Cloud Shell

az aks disable-addons --addons azure-policy --name MyAKSCluster --resource-group MyResourceGroup

從已啟用 Azure Arc 的 Kubernetes 中移除附加元件

注意

Azure 原則附加元件 Helm 模型現在已取代。您應該改用適用於已啟用 Azure Arc 的 Kubernetes 的 Azure 原則延伸模組。

若要從已啟用 Azure Arc 的 Kubernetes 叢集中移除 Azure 原則附加元件和 Gatekeeper，請執行下列 Helm 命令：

helm uninstall azure-policy-addon

從 AKS 引擎移除附加元件

注意

AKS 引擎產品現在已由 Azure 公用雲端客戶取代。考慮針對受控 Kubernetes 使用 Azure Kubernetes Service (AKS)，或針對自我管理的 Kubernetes 使用叢集 API 提供者 Azure。沒有計劃新功能；此專案僅針對類似 CVE 和類似內容進行更新，且 Kubernetes 1.24 是接收更新的最終版本。

若要從 AKS 引擎叢集中移除 Azure 原則附加元件和 Gatekeeper，請使用與安裝附加元件時一致的方法：

如果您藉由在 AKS 引擎的叢集定義中設定 addons 屬性來進行安裝：

將 azure-policy 的 addons 屬性變更為 false 之後，將叢集定義重新部署至 AKS 引擎：
```
"addons": [
  {
    "name": "azure-policy",
    "enabled": false
  }
]
```
如需詳細資訊，請參閱 AKS 引擎 - 停用 Azure 原則附加元件 $英文$。
如果使用 Helm Charts 安裝，請執行下列 Helm 命令：
```
helm uninstall azure-policy-addon
```

限制

如需一般 Azure 原則定義和指派限制，請檢閱 Azure 原則記載的限制
適用於 Kubernetes 的 Azure 原則附加元件只能部署至 Linux 節點集區。
每個叢集的 Azure 原則附加元件支援的 Pod 數目上限：10,000
各叢集每個原則不符合規範的記錄數目上限：500
每個訂用帳戶不符合規範的記錄數目上限：100 萬
不支援在 Azure 原則附加元件外部安裝 Gatekeeper。在啟用 Azure 原則附加元件之前，請先解除安裝先前安裝 Gatekeeper 時所安裝的任何元件。
Microsoft.Kubernetes.Data 資源提供者模式不提供不符合規範的原因。使用元件詳細資料。
資源提供者模式不支援元件層級的豁免。 Azure 原則定義中提供參數支援，以排除並包含特定命名空間。
在條件約束範本中使用 metadata.gatekeeper.sh/requires-sync-data 註釋，以從您的叢集將複製的資料設定到目前僅允許用於內建原則的 OPA 快取。其原因是因為如果不小心使用，Gatekeeper Pod 的資源使用量可能會大幅增加。

設定 Gatekeeper 設定

不支援變更 Gatekeeper 設定，因為其包含重要的安全性設定。對組態的編輯會協調。

在限制式範本中使用 data.inventory

目前，數個內建原則會使用數據復寫，讓用戶能夠將現有的叢集資源同步處理至 OPA 快取，並在評估 AdmissionReview 要求期間參考它們。數據復寫策略可以透過 Rego 的存在和批注的存在metadata.gatekeeper.sh/requires-sync-data來區分data.inventory，這會通知 Azure 原則附加元件需要快取哪些資源，原則評估才能正常運作。此程式與獨立的 Gatekeeper 不同，其中這個註釋是描述性的，而不是規範的。

資料複寫目前已針對在自訂原則定義中使用遭到封鎖，因為如果未謹慎使用，複寫具有高執行個體計數的資源可能會大幅增加 Gatekeeper Pod 的資源使用量。當您嘗試使用這個註釋建立包含條件約束範本的自定義原則定義時，您會看到 ConstraintTemplateInstallFailed 錯誤。

移除註釋看似能夠減輕您看到的錯誤，但原則附加元件不會將該限制式範本的任何必要資源同步處理至快取。因此，您的原則會根據空白 data.inventory 進行評估 (假設未指派任何內建複寫必要資源)。這會導致誤導合規性結果。如先前所述，也不允許手動編輯設定以快取所需的資源。

下列限制僅適用於 AKS 的 Azure 原則附加元件：

無法同時啟用 AKS Pod 安全性原則和 AKS 的 Azure 原則附加元件。如需詳細資訊，請參閱 AKS Pod 安全性限制。
Azure 原則附加元件在評估時自動排除的命名空間：kube-system 和 gatekeeper-system。

常見問題集

在安裝時，Azure 原則附加元件/Azure 原則延伸模組會在我的叢集上部署什麼？

Azure 原則附加元件需要三個 Gatekeeper 元件才能執行：一個稽核 Pod 和兩個 Webhook Pod 複本。也會安裝一個 Azure 原則 Pod 和一個 Azure 原則 Webhook Pod。

我期望 Azure 原則附加元件/延伸模組在每個叢集上使用多少資源耗用量？

在您的叢集上執行的適用於 Kubernetes 的 Azure 元件會取用更多資源，因為叢集中的 Kubernetes 資源和原則指派計數會增加，而這需要進行稽核和強制執行作業。

以下是協助您制定計劃的估計值：

對於單一叢集中少於 500 個 Pod 且最多 20 個條件約束：每個元件兩個 vCPU 和 350 MB 的記憶體。
對於單一叢集中超過 500 個 Pod 且最多 40 個條件約束：每個元件三個 vCPU 和 600 MB 的記憶體。

適用於 Kubernetes 的 Azure 原則定義是否可以套用在 Windows Pod 上？

Windows Pod 不支援資訊安全內容。因此，某些 Azure 原則定義 (例如不允許根權限) 無法在 Windows Pod 中呈報，而且僅適用於 Linux Pod。

Azure 原則附加元件會收集哪些類型的診斷資料？

適用於 Kubernetes 的 Azure 原則附加元件會收集有限的叢集診斷資料。此診斷資料是與軟體和效能相關的重要技術資料。資料的使用方式如下：

讓 Azure 原則附加元件保持在最新狀態。
確保 Azure 原則附加元件安全、可靠、高效能。
改善 Azure 原則附加元件 - 透過使用附加元件時的彙總分析。

附加元件所收集的資訊不是個人資料。目前會收集下列詳細資料：

Azure 原則附加元件代理程式版本
叢集類型
叢集區域
叢集資源群組
叢集資源識別碼
叢集訂用帳戶識別碼
叢集作業系統 (範例：Linux)
叢集城市 (範例：西雅圖)
叢集的州或省 (範例：華盛頓州)
叢集的國家或地區 (範例：美國)
在原則評估上安裝代理程式期間，Azure 原則附加元件所遇到的例外狀況/錯誤
Azure 原則附加元件未安裝的 Gatekeeper 原則定義數目

安裝 Azure 原則附加元件時，需記住哪些一般最佳做法？

使用帶有 CriticalAddonsOnly Taint 的系統節點集區來為 Gatekeeper Pod 排程。如需詳細資訊，請參閱使用系統節點集區。
保護來自 AKS 叢集的輸出流量。如需詳細資訊，請參閱控制叢集節點的輸出流量。
如果叢集 aad-pod-identity 已啟用，節點受控識別（NMI） Pod 會修改節點 iptables ，以攔截對 Azure 實例元數據端點的呼叫。此設定表示即使 Pod 未使用 aad-pod-identity，對中繼資料端點所做的任何要求仍會遭到 NMI 攔截。
AzurePodIdentityException CRD 可以設定為通知 aad-pod-identity 來自符合 CRD 中定義之標籤的 Pod 的任何元數據端點要求，都應該進行 Proxy 處理，而不需在 NMI 中進行任何處理。在 kube-system 命名空間中具有kubernetes.azure.com/managedby: aks標籤的系統 Pod 應該藉由設定 AzurePodIdentityException CRD 來排除。aad-pod-identity 如需詳細資訊，請參閱停用特定 Pod 或應用程式的 aad-pod-identity。若要設定例外狀況，請安裝 mic-exception YAML。

下一步

在 Azure 原則範例檢閱範例。
檢閱原則定義結構。
檢閱了解原則效果。
了解如何以程式設計方式建立原則。
了解如何取得合規性資料。
了解如何補救不符合規範的資源。
透過使用 Azure 管理群組來組織資源來檢閱何謂管理群組。

共用方式為

了解適用於 Kubernetes 叢集的 Azure 原則 \(部分機器翻譯\)

概觀

安裝 AKS 的 Azure 原則附加元件

必要條件

為 Azure Arc 啟用的 Kubernetes 安裝 Azure 原則延伸功能

必要條件

建立 Azure 原則延伸模組

範例：

範例輸出：

顯示 Azure 原則延伸模組

範例：

刪除 Azure 原則延伸模組

建立原則定義

指派原則定義

原則評估

條件約束範本衝突

記錄

檢視 Gatekeeper 成品

檢視附加元件條件約束範本

檢視附加元件變動範本

取得 Azure 原則對應

檢視與條件約束範本相關的條件約束

檢視條件約束詳細資料

對附加元件進行疑難排解

AKS 變更記錄的 Azure 原則附加元件

識別叢集上安裝的附加元件版本

每個 AKS 叢集版本可用的附加元件版本

1.9.1

1.8.0

1.7.1

1.7.0

1.6.1

1.5.0

1.4.0

1.3.0

1.2.1

1.1.0

1.0.1

1.0.0

移除附加元件

從 AKS 移除附加元件

從已啟用 Azure Arc 的 Kubernetes 中移除附加元件

從 AKS 引擎移除附加元件

限制

設定 Gatekeeper 設定

在限制式範本中使用 data.inventory

常見問題集

在安裝時，Azure 原則附加元件/Azure 原則延伸模組會在我的叢集上部署什麼？

我期望 Azure 原則附加元件/延伸模組在每個叢集上使用多少資源耗用量？

適用於 Kubernetes 的 Azure 原則定義是否可以套用在 Windows Pod 上？

Azure 原則附加元件會收集哪些類型的診斷資料？

安裝 Azure 原則附加元件時，需記住哪些一般最佳做法？

下一步

意見反應

其他資源