了解用于 Kubernetes 群集的 Azure Policy

项目
10/12/2024

Azure Policy 扩展了 Gatekeeper v3，这是一个用于 Open Policy Agent (OPA) 的许可控制器 Webhook，它以集中、一致的方式对群集组件应用大规模强制执行和安全保护措施。群集组件包括 Pod、容器和命名空间。

借助 Azure Policy，可以从一个位置管理和报告 Kubernetes 群集组件的符合性状态。通过使用 Azure Policy 的加载项或扩展，可以利用 Azure Policy 功能增强对群集组件的管理，例如使用选择器和替代进行安全策略推出和回滚的功能。

适用于 Kubernetes 的 Azure Policy 支持以下群集环境：

Azure Kubernetes 服务 (AKS)，通过适用于 AKS 的 Azure Policy 加载项
已启用 Azure Arc 的 Kubernetes，通过适用于 Arc 的 Azure Policy 扩展

重要

Azure Policy 加载项 Helm 模型和 AKS 引擎的加载项已弃用。按照说明删除加载项。

概述

通过在 Kubernetes 群集上安装 Azure Policy 的加载项或扩展，Azure Policy 会执行以下功能：

检查 Azure Policy 服务对群集的策略分配。
将策略定义部署到群集中，作为约束模板和约束自定义资源或者突变模板资源（具体取决于策略定义内容）。
向 Azure Policy 服务报告审核和符合性详细信息。

若要启用 Azure Policy 并将其用于 Kubernetes 群集，请执行以下操作：

配置 Kubernetes 群集并安装 Azure Kubernetes 服务 (AKS) 加载项或已启用 Arc 的 Kubernetes 群集的 Azure Policy 扩展（具体取决于群集类型）。

注意

有关安装的常见问题，请参阅故障排除 - Azure Policy 加载项。
为 Kubernetes 创建 Azure Policy 定义或使用示例定义
向 Kubernetes 群集分配定义
等待验证
日志记录和故障排除
查看常见问题解答部分中的限制和建议

为 AKS 安装 Azure Policy 加载项

适用于 AKS 的 Azure Policy 加载项是具有长期支持 (LTS) 的 Kubernetes 版本 1.27 的一部分。

先决条件

注册资源提供程序和预览功能。

Azure 门户：

注册Microsoft.PolicyInsights资源提供程序。有关步骤，请参阅资源提供程序和类型。

Azure CLI：

# Log in first with az login
az cloud set -n AzureChinaCloud
az login

# 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 服务 (AKS) 中受支持的 Kubernetes 版本。使用以下脚本验证 AKS 群集版本：
```
# Log in first with az login
az cloud set -n AzureChinaCloud
az login

# Look for the value in kubernetesVersion
az aks list
```
打开 Azure Policy 扩展的端口。 Azure Policy 扩展使用这些域和端口提取策略定义和分配，并将群集的符合性报告回 Azure Policy。

域端口

data.policy.core.chinacloudapi.cn 443

store.policy.core.chinacloudapi.cn 443

login.chinacloudapi.cn 443

dc.services.visualstudio.com 443

域	端口
`data.policy.core.chinacloudapi.cn`	`443`
`store.policy.core.chinacloudapi.cn`	`443`
`login.chinacloudapi.cn`	`443`
`dc.services.visualstudio.com`	`443`

完成先决条件后，立即在要管理的 AKS 群集中安装 Azure Policy 加载项。

Azure 门户
1. 在 Azure 门户中，选择“所有服务”，然后搜索并选择“Kubernetes 服务”，以启动 AKS 服务。
2. 选择 AKS 群集之一。
3. 选择“Kubernetes 服务”页左侧的“策略”。
4. 在主页中，选择“启用加载项”按钮。

Azure CLI

# Log in first with az login
az cloud set -n AzureChinaCloud
az login

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 Policy 扩展

借助适用于 Kubernetes 的 Azure Policy，可以从一个位置管理和报告 Kubernetes 群集的符合性状态。借助已启用 Arc 的 Kubernetes 群集的 Azure Policy 扩展，可以管理已启用 Arc 的 Kubernetes 群集组件，如 Pod 和容器。

本文介绍如何创建和删除适用于 Kubernetes 的 Azure Policy 扩展以及显示扩展的状态。

有关扩展平台的概述，请参阅 Azure Arc 群集扩展。

先决条件

如果已在 Azure Arc 群集上直接使用 Helm 部署了适用于 Kubernetes 的 Azure Policy（不带扩展），请按照说明删除 Helm 图表。删除操作完成后，可以继续操作。

确保 Kubernetes 群集是受支持的发行版。

注意

以下 Kubernetes 发行版支持 Azure Policy for Arc 扩展。
确保满足此处列出的针对 Kubernetes 扩展的所有常见先决条件，包括将群集连接到 Azure Arc。

注意

在这些区域，已启用 Arc 的 Kubernetes 群集支持 Azure Policy 扩展。
打开 Azure Policy 扩展的端口。 Azure Policy 扩展使用这些域和端口提取策略定义和分配，并将群集的符合性报告回 Azure Policy。

域端口

data.policy.core.chinacloudapi.cn 443

store.policy.core.chinacloudapi.cn 443

login.chinacloudapi.cn 443

dc.services.visualstudio.com 443

域	端口
`data.policy.core.chinacloudapi.cn`	`443`
`store.policy.core.chinacloudapi.cn`	`443`
`login.chinacloudapi.cn`	`443`
`dc.services.visualstudio.com`	`443`

在安装 Azure Policy 扩展或启用任何服务功能之前，订阅必须启用 Microsoft.PolicyInsights 资源提供程序。

注意

若要启用资源提供程序，请按照资源提供程序和类型中的步骤操作，或者运行 Azure CLI 或 Azure PowerShell 命令。

Azure CLI

# Log in first with az login
# Provider register: Register the Azure Policy provider
az provider register --namespace 'Microsoft.PolicyInsights'

Azure PowerShell

# Log in first with Connect-AzAccount -Environment AzureChinaCloud

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

创建 Azure Policy 扩展

注意

请注意以下有关创建 Azure Policy 扩展的事项：

默认情况下启用自动升级，如果部署了任何新更改，自动升级将更新 Azure Policy 扩展次要版本。
作为参数传递到 connectedk8s 的任何代理变量都将传播到 Azure Policy 扩展以支持出站代理。

要为已启用 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 Policy 扩展

要检查是否已成功创建扩展实例，请运行以下命令，并将 <> 替换为自己的值：

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 Policy 扩展

要删除扩展实例，请运行以下命令，并将 <> 替换为自己的值：

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

创建策略定义

用于管理 Kubernetes 的 Azure Policy 语言结构遵循现有策略定义。在 Azure Policy 的内置策略库中有可供分配的示例定义文件，这些文件可用于管理群集组件。

Azure Policy for Kubernetes 还支持在组件级别为 Azure Kubernetes 服务群集和已启用 Azure Arc 的 Kubernetes 群集创建自定义的定义。约束模板和突变模板示例在 Gatekeeper 社区库中可用。借助 Microsoft.Kubernetes.Data 的资源提供程序模式，审核、拒绝、禁用和修改效果可用来管理 Kubernetes 群集。

“审核”和“拒绝”必须提供特定于使用 OPA Constraint Framework 和 Gatekeeper v3 的详细信息属性。

作为策略定义中 details.templateInfo 或 details.constraintInfo 属性的一部分，Azure Policy 将这些 CustomResourceDefinitions (CRD) 的 URI 或 Base64Encoded 值传递给加载项。 Rego 是 OPA 和 Gatekeeper 支持的语言，用于验证对 Kubernetes 群集的请求。通过支持 Kubernetes 管理的现有标准，Azure Policy 可重用现有规则并将其与 Azure Policy 配对以获得统一的云符合性报告体验。有关详细信息，请参阅什么是 Rego？。

分配策略定义

若要为 Kubernetes 群集分配策略定义，系统必须为你分配适当的 Azure 基于角色的访问控制 (Azure RBAC) 策略分配操作。 Azure 内置角色“资源策略参与者”和“所有者”可进行这些操作。若要了解详细信息，请参阅 Azure Policy 中的 Azure RBAC 权限。

通过以下步骤，使用 Azure 门户查找用于管理群集的内置策略定义。如果使用某自定义策略定义，请按名称或创建时使用的类别来搜索该定义。

在 Azure 门户中启动 Azure Policy 服务。在左窗格中选择“所有服务”，然后搜索并选择“策略” 。
在“Azure Policy”页面的左侧窗格中，选择“定义”。
从“类别”下拉列表框中，使用“全选”清除筛选器，然后选择“Kubernetes” 。
选择策略定义，然后选择“分配”按钮。
将“范围”设置为要应用策略分配的 Kubernetes 群集的管理组、订阅或资源组。

注意

为 Kubernetes 定义分配 Azure Policy 时，“范围”必须包括群集资源。
为策略分配提供可以用于轻松识别它的“名称”和“说明”。
将策略实施设置为下面的一个值：
- 已启用 - 在群集上强制实施策略。拒绝带有冲突的 Kubernetes 许可请求。
- 已禁用 - 不在群集上强制实施策略。不拒绝带有冲突的 Kubernetes 许可请求。符合性评估结果仍可用。向运行群集推出新策略定义时，已禁用选项可用于测试策略定义，因为不拒绝带有冲突的许可请求。
选择下一步。
设置参数值
- 若要从策略评估中排除 Kubernetes 命名空间，请在参数“命名空间排除”中指定命名空间的列表。建议排除以下内容：kube-system、gatekeeper-system 和 azure-arc。
选择“查看 + 创建”。

或者，使用分配策略 - 门户快速入门来查找和分配 Kubernetes 策略。搜索 Kubernetes 策略定义，而不是示例audit vms。

重要

内置策略定义适用于 Kubernetes 类别的 Kubernetes 群集。有关内置策略定义的列表，请参阅 Kubernetes 示例。

策略评估

加载项每 15 分钟使用 Azure Policy 服务签入一次，查看策略分配中的更改。在此刷新周期内，加载项将检查更改。这些更改将触发约束模板和约束的创建、更新或删除。

在 Kubernetes 群集中，如果命名空间具有适合群集的标签，则不拒绝带有冲突的许可请求。符合性评估结果仍可用。

已启用 Azure Arc 的 Kubernetes 群集：admission.policy.azure.com/ignore

注意

虽然群集管理员可能有权创建和更新 Azure Policy 加载项安装的约束模板和约束资源，但这些情况不受支持，因为手动更新会被覆盖。 Gatekeeper 会继续评估在安装加载项和分配 Azure Policy 策略定义之前已存在的策略。

每隔 15 分钟，加载项就会调用对群集的完全扫描。在收集完全扫描的详细信息和 Gatekeeper 对群集尝试更改的所有实时评估后，加载项将结果报告回 Azure Policy，以便像所有 Azure Policy 分配一样包含在符合性详细信息中。在审核周期中，仅返回活动策略分配的结果。审核结果也可以视为已失败约束的“状态”字段中列出的冲突。有关不符合资源的详细信息，请参阅资源提供程序模式的组件详细信息。

注意

适用于 Kubernetes 群集的 Azure Policy 中的每个符合性报告都包含过去 45 分钟内的所有冲突。时间戳指示发生冲突的时间。

一些其他注意事项：

如果将群集订阅注册到 Microsoft Defender for Cloud，则 Microsoft Defender for Cloud Kubernetes 策略会自动应用于群集。
将拒绝策略应用于带有现有 Kubernetes 资源的群集时，任何不符合新策略的预先存在的资源都将继续运行。如果在其他节点上重新计划了不符合的资源，则 Gatekeeper 会阻止资源创建。
如果群集具有用于验证资源的拒绝策略，则在创建部署时，用户不会收到拒绝消息。例如，考虑包含副本集和 Pod 的 Kubernetes 部署。用户执行kubectl describe deployment $MY_DEPLOYMENT时，不会返回拒绝消息作为事件的一部分。但是，kubectl describe replicasets.apps $MY_DEPLOYMENT 会返回与拒绝关联的事件。

注意

策略评估期间可能包含 Init 容器。若要查看是否包含 Init 容器，请查看 CRD 中的以下或类似声明：

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

约束模板冲突

如果约束模板具有相同的资源元数据名称，但策略定义引用不同位置的源，则策略定义被视为冲突。示例：两个策略定义引用存储在不同源位置（例如 Azure Policy 模板存储区 (store.policy.core.chinacloudapi.cn) 和 GitHub）的同一 template.yaml 文件。

如果策略定义及其约束模板在分配时未安装于群集并存在冲突，会将其报告为冲突，且在冲突解决之前不会将其安装到群集中。同样，群集上与新分配策略定义冲突的任何现有策略定义和它们的约束模板都会继续正常工作。如果更新现有分配，但未能同步约束模板，则群集也会标记为冲突。有关所有冲突消息，请参阅 AKS 资源提供程序模式符合性原因

日志记录

作为 Kubernetes 控制器/容器，azure-policy 和 gatekeeper Pod 在 Kubernetes 群集中保留日志。通常，azure-policy 日志可用于解决有关将策略引入群集和合规性报告的问题。 gatekeeper-controller-manager pod 日志可用于解决运行时拒绝问题。 gatekeeper-audit pod 日志可用于对现有资源的审核进行故障排除。日志可以在 Kubernetes 群集的“见解”页中公开。有关详细信息，请参阅使用适用于容器的 Azure Monitor 监视 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 策略 Pod 日志来查看完整的随附错误。

有关详细信息，请参阅 Gatekeeper 文档中的调试 Gatekeeper。

查看 Gatekeeper 项目

在外接程序下载策略分配并在群集上安装约束模板和约束后，会通过 Azure 策略信息（如策略分配 ID）和策略定义 ID 进行注释。若要配置客户端以查看外接程序相关项目，请使用以下步骤：

为群集设置kubeconfig。

对于 Azure Kubernetes 服务群集，请使用以下 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 Policy 映射

若要确定下载到群集的约束模板与策略定义之间的映射，请使用 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> 是订阅 ID，<GUID> 是映射的策略定义的 ID。 <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 Policy 故障排除一文的 Kubernetes 部分。

如有 Azure Policy for Arc 扩展相关问题，请转到：

已启用 Azure Arc 的 Kubernetes 故障排除

有关 Azure Policy 相关问题，请转到：

用于 AKS 的 Azure Policy 加载项更改日志

Azure Policy 的 AKS 加载项具有一个版本号，表示加载项的映像版本。由于加载项上新引入了功能支持，因此版本号也将增加。

本部分帮助确定哪些加载项版本安装在群集上，还会共享每个 AKS 群集安装的 Azure Policy 加载项版本的历史记录表。

确定在群集上安装了哪些加载项版本

Azure Policy 加载项对每个版本使用标准语义化版本控制架构。若要识别正在使用的 Azure Policy 加载项版本，可以运行以下命令：kubectl get pod azure-policy-<unique-pod-identifier> -n kube-system -o json | jq '.spec.containers[0].image'

若要识别 Azure Policy 加载项正在使用的 Gatekeeper 版本，可以运行以下命令：kubectl get pod gatekeeper-controller-<unique-pod-identifier> -n gatekeeper-system -o json | jq '.spec.containers[0].image'

最后，若要识别正在使用的 AKS 群集版本，请遵循链接的 AKS 指南。

每个 AKS 群集版本可用的加载项版本

1.7.0

引入扩展，这是一种左移功能，可让你提前知道工作负载资源（部署、副本集、作业等）是否会生成许可的 pod。扩展不应更改策略的行为，而只是将 Gatekeeper 对 pod 范围策略的评估转移到工作负载许可时间而不是 pod 许可时间。但是，若要执行此评估，它必须生成并评估基于工作负载中定义的 pod 规范的 what-if pod，而该 pod 的元数据可能不完整。例如，what-if pod 不包含正确的所有者引用。由于策略行为更改会导致这种轻微风险，我们引入的扩展默认处于禁用状态。若要为给定的策略定义启用扩展，请将 .policyRule.then.details.source 设置为 All。内置设置在不久后将会更新，以启用此字段的参数化。如果你在测试策略定义并发现针对评估目的生成的 what-if pod 不完整，则还可以使用源 Generated 的变动来转变 what-if pod。有关此选项的详细信息，请参阅 Gatekeeper 文档。

安全性改进。

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

Azure Policy for Kubernetes 现在支持突变以大规模修正 AKS 群集！

删除加载项

从 AKS 删除加载项

若要从 AKS 群集中删除 Azure Policy 加载项，请使用 Azure 门户或 Azure CLI：

Azure 门户
1. 在 Azure 门户中，选择“所有服务”，然后搜索并选择“Kubernetes 服务”，以启动 AKS 服务。
2. 选择要在其中禁用 Azure Policy 加载项的 AKS 群集。
3. 选择“Kubernetes 服务”页左侧的“策略”。
4. 在主页中，选择“禁用加载项”按钮。

Azure CLI

# Log in first with az login
az cloud set -n AzureChinaCloud
az login

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

从已启用 Azure Arc 的 Kubernetes 中删除加载项

注意

Azure Policy 加载项 Helm 模型现已弃用。应改为选择适用于已启用 Azure Arc 的 Kubernetes 的 Azure Policy 扩展。

若要从已启用 Azure Arc 的 Kubernetes 群集中删除 Azure Policy 加载项和 Gatekeeper，请运行以下 Helm 命令：

helm uninstall azure-policy-addon

从 AKS 引擎删除加载项

注意

对于 Azure 公有云客户，AKS 引擎产品现已弃用。请考虑将 Azure Kubernetes 服务 (AKS) 用于托管 Kubernetes，或将群集 API 提供程序 Azure 用于自托管 Kubernetes。未规划任何新功能；此项目将仅针对 CVE 和类似项进行更新，Kubernetes 1.24 是接收更新的最终版本。

若要从 AKS 引擎群集中删除 Azure Policy 加载项和 Gatekeeper，请使用与加载项的安装方式一致的方法：

如果设置 AKS 引擎群集定义中的“加载项”属性进行安装：

将 azure-policy 的“加载项”属性更改为 false 后，将群集定义重新部署到 AKS 引擎：
```
"addons": [{
    "name": "azure-policy",
    "enabled": false
}]
```
有关详细信息，请参阅 AKS 引擎 - 禁用 Azure Policy 加载项。
如果安装有 Helm 图表，请运行以下 Helm 命令：
```
helm uninstall azure-policy-addon
```

限制

有关 Azure Policy 定义和分配限制的一般信息，请查看 Azure Policy 记录的限制
只能将适用于 Kubernetes 的 Azure Policy 加载项部署到 Linux 节点池。
每个群集的 Azure Policy 加载项支持的最大 Pod 数：10,000
每个群集每个策略的最大不符合记录数：500
每个订阅的最大不符合记录数：1000000
不支持在 Azure Policy 加载项之外安装 Gatekeeper。在启用 Azure Policy 加载项之前，卸载由以前的 Gatekeeper 安装的所有组件。
不合规的原因不适用于 Microsoft.Kubernetes.Data 资源提供程序模式。使用组件详细信息。
资源提供程序模式不支持组件级别豁免。 Azure Policy 定义中提供参数支持，可用于排除和包含特定的命名空间。
目前，仅允许针对内置策略来使用约束模板中的 metadata.gatekeeper.sh/requires-sync-data 注释配置从群集到 OPA 缓存的数据复制。原因是如果不谨慎使用，它可能会显著增加 Gatekeeper Pod 的资源使用率。

配置 Gatekeeper Config

不支持更改 Gatekeeper config，因为它包含关键安全设置。将对该 config 进行调整。

在约束模板中使用 data.inventory

目前，多个内置策略使用数据复制，它使用户能够将现有群集上的资源同步到 OPA 缓存，并在评估 AdmissionReview 请求期间引用它们。可以通过 Rego 中存在的 data.inventory 以及存在的 metadata.gatekeeper.sh/requires-sync-data 注释来区分数据复制策略，这会通知 Azure Policy 加载项需要缓存哪些资源才能使策略评估正常工作。（请注意，这不同于独立的 Gatekeeper，其中此批注是描述性的，而不是规范性的。）

目前在自定义策略定义中禁止使用数据复制，因为如果不谨慎使用，复制实例计数庞大的资源会极大地增加 Gatekeeper Pod 的资源使用。尝试创建包含约束模板（带有此批注）的自定义策略定义时，会出现 ConstraintTemplateInstallFailed 错误。

删除批注似乎可以缓解你看到的错误，但策略加载项不会将该约束模板的任何必需资源同步到缓存中。因此，将针对空 data.inventory 评估策略（假设没有分配任何内置复制机制来复制必要的资源）。这将导致误导性合规性结果。如前所述，也不允许手动编辑该 config 来缓存必需资源。

以下限制仅适用于 AKS 的 Azure Policy 加载项：

Azure Policy 附加产品评估自动排除的命名空间包括：kube-system 和 gatekeeper-system。

常见问题

安装 Azure Policy 加载项/Azure Policy 扩展时在群集上部署了哪些内容？

Azure Policy 附加产品需要三个 Gatekeeper 组件才能运行：一个审核 Pod 和两个 Webhook Pod 副本。还会安装一个 Azure Policy Pod 和一个 Azure Policy Webhook Pod。

预计 Azure Policy 加载项/扩展应在每个群集上使用多少资源消耗？

随着 Kubernetes 资源和策略分配计数在群集中增加，在群集上运行的 Azure Policy for Kubernetes 组件将消耗更多资源，这需要审核和执行操作。以下是可帮助你进行计划的估计值：

对于少于 500 个 Pod、最多 20 个约束的单个群集：每个组件 2 个 vCPU，350 MB 内存。
对于超过 500 个 Pod、最多 40 个约束的单个群集：每个组件 3 个 vCPU，600 MB 内存。

是否可以将 Azure Policy for Kubernetes 定义应用在 Windows Pod 上？

Windows Pod 不支持安全上下文。因此，一些 Azure Policy 定义（比如禁止根权限）不能在 Windows Pod 中升级，它们仅适用于 Linux Pod。

Azure Policy 加载项会收集哪些类型的诊断数据？

适用于 Kubernetes 的 Azure Policy 加载项收集有限的群集诊断数据。该诊断数据是与软件和性能相关的重要技术数据。数据以下列方式使用：

不断更新 Azure Policy 加载项。
让 Azure Policy 加载项保持安全性、可靠性和高性能。
改进 Azure Policy 加载项 - 通过对此加载项的使用情况进行聚合分析。

加载项收集的信息不是个人数据。当前正在收集以下详细信息：

Azure Policy 加载项代理版本
群集类型
群集区域
群集资源组
群集资源 ID
群集订阅 ID
群集 OS（示例：Linux）
群集所在城市
群集所在州/省/自治区/直辖市
群集所在国家/地区
在策略评估的代理安装期间，Azure Policy 加载项遇到异常/错误
Azure Policy 加载项未安装的 Gatekeeper 策略数

安装 Azure Policy 加载项时要记住有哪些常见的最佳做法？

使用具有 CriticalAddonsOnly 排斥的系统节点池来计划 Gatekeeper Pod。有关详细信息，请参阅使用系统节点池。
保护来自 AKS 群集的出站流量。有关详细信息，请参阅控制群集节点的出口流量。
如果群集启用了 aad-pod-identity，节点托管标识 (NMI) pod 将修改节点的 iptable，以拦截对 Azure 实例元数据终结点的调用。此配置意味着对元数据终结点发出的任何请求都将被 NMI 拦截，即使 pod 不使用 aad-pod-identity。
可以将 AzurePodIdentityException CRD 配置为通知 aad-pod-identity 应在不使用 NMI 进行出任何处理的情况下，代理与 CRD 中定义的标签匹配的 pod 所发起的对元数据终结点的任何请求。通过配置 AzurePodIdentityException CRD，应在 aad-pod-identity 中排除其在 kube-system 命名空间中的标签为 kubernetes.azure.com/managedby: aks 的系统 pod。有关详细信息，请参阅禁用特定 pod 或应用程序的 aad-pod-identity。若要配置例外情况，请安装 mic-exception YAML。

后续步骤

查看 Azure Policy 示例中的示例。
查看策略定义结构。
查看了解策略效果。
了解如何以编程方式创建策略。
了解如何获取符合性数据。
了解如何修正不符合的资源。
参阅使用 Azure 管理组来组织资源，了解什么是管理组。

通过

了解用于 Kubernetes 群集的 Azure Policy

概述

为 AKS 安装 Azure Policy 加载项

先决条件

安装适用于已启用 Azure Arc 的 Kubernetes 的 Azure Policy 扩展

先决条件

创建 Azure Policy 扩展

示例：

示例输出：

显示 Azure Policy 扩展

示例：

删除 Azure Policy 扩展

创建策略定义

分配策略定义

策略评估

约束模板冲突

日志记录

查看 Gatekeeper 项目

查看外接程序约束模板

查看加载项突变模板

获取 Azure Policy 映射

查看与约束模板相关的约束

查看约束详细信息

对加载项进行故障排除

用于 AKS 的 Azure Policy 加载项更改日志

确定在群集上安装了哪些加载项版本

每个 AKS 群集版本可用的加载项版本

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 Config

在约束模板中使用 data.inventory

常见问题

安装 Azure Policy 加载项/Azure Policy 扩展时在群集上部署了哪些内容？

预计 Azure Policy 加载项/扩展应在每个群集上使用多少资源消耗？

是否可以将 Azure Policy for Kubernetes 定义应用在 Windows Pod 上？

Azure Policy 加载项会收集哪些类型的诊断数据？

安装 Azure Policy 加载项时要记住有哪些常见的最佳做法？

后续步骤

其他资源