Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Azure Policy扩展Gatekeeper v3,这是适用于Open Policy Agent (OPA) 的admission controller webhook,以集中一致的方式对群集组件应用大规模强制措施和安全措施。 群集组件包括 Pod、容器和命名空间。
Azure Policy使你能够从一个位置管理和报告 Kubernetes 群集组件的符合性状态。 通过使用 Azure Policy 的加载项或扩展,您可以利用 Azure Policy 的功能来增强对群集组件的管理,例如使用 选择器 和 覆盖 功能来安全地推出和回滚策略。
Azure Policy for Kubernetes 支持以下群集环境:
- Azure Kubernetes Service (AKS),通过 Azure Policy 的 Add-on AKS
- Azure Arc 启用的 Kubernetes,通过 Azure Policy 的 扩展 for Arc
重要
Azure Policy 加载项 Helm 模型和 AKS 引擎的加载项已弃用。 按照说明删除加载项。
重要
不支持在 Azure Policy 加载项外部安装 Gatekeeper。 在启用 Azure Policy 组件加载项之前,请卸载之前 Gatekeeper 安装的任何组件。
概述
通过在 Kubernetes 群集上安装Azure Policy的加载项或扩展,Azure Policy执行以下功能:
- 使用Azure Policy服务检查群集的策略分配。
- 将策略定义部署到群集中,作为约束模板和约束自定义资源或者突变模板资源(具体取决于策略定义内容)。
- 将审核和合规性详细信息报告回Azure Policy服务。
若要在 Kubernetes 群集中启用和使用Azure Policy,请执行以下步骤:
配置您的 Kubernetes 群集,并安装 Azure Kubernetes Service (AKS) 加载项,或 Azure Policy 的 Arc 启用的 Kubernetes 群集扩展(具体取决于群集类型)。
注意
有关安装常见问题,请参阅 Troubleshoot - Azure Policy加载项。
为 AKS 安装 Azure Policy 的插件
Azure Policy 加载项针对 AKS 是 Kubernetes 版本 1.27 的一部分,并且属于长期支持版本 (LTS)。
先决条件
注册资源提供程序和预览功能。
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 Service (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.cn443store.policy.core.chinacloudapi.cn443login.chinacloudapi.cn443dc.services.visualstudio.com443
先决条件完成后,在要管理的 AKS 群集中安装Azure Policy加载项。
Azure门户
通过在Azure门户中选择“所有服务启动 AKS 服务,然后搜索并选择Kubernetes 服务。
选择一个 AKS 群集。
在 Kubernetes 服务页面的左侧选择 策略。
在主页面中,选择“启用加载项”按钮。
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 扩展
Azure Policy for Kubernetes使你能够从一个位置管理和报告 Kubernetes 群集的符合性状态。 借助 Azure Policy 的已启用 Arc 的 Kubernetes 群集扩展功能,可以管理已启用 Arc 的 Kubernetes 群集组件,例如 pod 和容器。
本文介绍如何创建、显示扩展状态和删除 Kubernetes 扩展的 Azure 政策。
有关扩展平台的概述,请参阅 Azure Arc 群集扩展。
先决条件
如果您已经在 Azure Arc 群集上通过 Helm 直接部署了 Kubernetes 的 Azure Policy 并且没有使用扩展,请按照说明执行,删除 Helm 安装包。 删除操作完成后,可以继续操作。
确保 Kubernetes 群集是受支持的发行版。
注意
Azure Policy for Arc 扩展支持以下 Kubernetes 发行版。
确保满足
here 列出的 Kubernetes 扩展的所有常见先决条件,包括将群集连接到 Azure Arc。 注意
Arc 启用的 Kubernetes 集群支持 Azure Policy 扩展 在这些区域。
打开Azure Policy扩展的端口。 Azure Policy扩展使用这些域和端口提取策略定义和分配,并将群集的符合性报告回Azure Policy。
域 端口 data.policy.core.chinacloudapi.cn443store.policy.core.chinacloudapi.cn443login.chinacloudapi.cn443dc.services.visualstudio.com443在安装Azure Policy扩展或启用任何服务功能之前,订阅必须启用
Microsoft.PolicyInsights资源提供程序。注意
若要启用资源提供程序,请按照 Resource 提供程序和类型中的步骤作,或运行 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 的内置策略库中分配,可用于管理群集组件。
对于 Kubernetes,Azure Policy还支持在组件级别为Azure Kubernetes Service群集和启用了Azure Arc的 Kubernetes 群集创建自定义定义。 约束模板和突变模板示例在 Gatekeeper 社区库中可用。 Azure Policy的Visual Studio Code扩展可用于帮助将现有约束模板或突变模板转换为自定义Azure Policy策略定义。
借助 的Microsoft.Kubernetes.Data,审核、拒绝、禁用和修改效果可用来管理 Kubernetes 群集。
“审核”和“拒绝”必须提供特定的 details 属性,以便与 OPA Constraint Framework 和 Gatekeeper v3 一起使用。
作为策略定义中的 details.templateInfo 或 details.constraintInfo 属性的一部分, Azure Policy将这些Base64Encoded(CRD)的 URI 或 值传递给加载项。 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页的左窗格中,选择Definitions。
从“类别”下拉列表框中,使用“全选”清除筛选器,然后选择“Kubernetes” 。
选择策略定义,然后选择“分配”按钮。
将 Scope 设置为 Kubernetes 群集中策略分配适用的管理组、订阅或资源组。
注意
为 Kubernetes 定义分配Azure Policy时,Scope必须包含群集资源。
为策略分配一个便于识别的名称和说明。
将策略实施设置为下面的一个值:
已启用 - 在群集上强制实施策略。 拒绝带有违规的 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 分配一样。 在审核周期中,仅返回活动策略分配的结果。 审核结果也可以视为已失败约束的“状态”字段中列出的冲突。 有关不符合资源的详细信息,请参阅资源提供程序模式的组件详细信息。
注意
Azure Policy 中针对您的 Kubernetes 群集的每个符合性报告都包含过去 45 分钟内的所有违规。 时间戳指示违规发生的时间。
一些其他注意事项:
如果群集订阅已注册Microsoft Defender for Cloud,则会自动在群集上应用 Microsoft Defender for Cloud Kubernetes 策略。
将拒绝策略应用于带有现有 Kubernetes 资源的群集时,任何不符合新策略的预先存在的资源都将继续运行。 当不符合的资源被重新调度到其他节点时,Gatekeeper 会阻止资源的创建。
如果群集具有用于验证资源的拒绝策略,则在创建部署时,用户不会收到拒绝消息。 例如,考虑包含
replicasets和 Pods 的 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 Policy模板存储(store.policy.core.chinacloudapi.cn)和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 策略 Pod 日志来查看完整的随附错误。
有关详细信息,请参阅 Gatekeeper 文档中的调试 Gatekeeper。
查看 Gatekeeper 项目
插件下载策略分配,并在群集上安装约束模板和约束后,使用Azure Policy信息(如策略分配 ID 和策略定义 ID)对其进行批注。 若要配置客户端以查看加载项相关项目,请使用以下步骤:
为群集设置
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> 是订阅 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 扩展中与 Arc 扩展相关的问题,请访问:
- 启用 Azure Arc 的 Kubernetes 故障排除
有关Azure Policy相关问题,请转到:
- 检查 Azure Policy 日志
- 在 Kubernetes 上对 Azure Policy 进行一般故障排除
AKS 更改日志的Azure Policy加载项
Azure Policy 的 AKS 加载项有一个版本号,表示加载项的镜像版本。 由于加载项上新引入了功能支持,因此版本号也将增加。
本部分可帮助你确定哪些加载项版本安装在群集上,并共享每个 AKS 群集安装的 Azure Policy 加载项版本的历史记录表。
确定群集上安装的加载项版本
Azure Policy加载项为每个版本使用标准 Semantic Versioning 架构。 若要标识正在使用的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.15.4
修补程序编号 CVE-2025-61727
- 发布日期:2025 年 12 月
- Kubernetes 1.27+
- 门卫 3.20.1-2
1.15.3
修补 CVE-2025-47914、CVE-2025-58181、CVE-2025-58187、CVE-2025-22872
- 发布日期:2025 年 12 月
- Kubernetes 1.27+
- 门卫 3.20.1-2
1.15.1
- 发布日期:2025 年 11 月
- Kubernetes 1.27+
- 门卫 3.20.1-2
1.14.2
- 发布日期:2025 年 10 月
- Kubernetes 1.27+
- 门卫 3.20.1-2
门卫 3.20.1-2
Gatekeeper 版本:https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.20.1 更改:https://github.com/open-policy-agent/gatekeeper/compare/v3.19.1...v3.20.1
1.13.1
补丁 CVE-2025-47907。
- 发布日期:2025 年 8 月
- Kubernetes 1.27+
- Gatekeeper 3.20.0
1.13.0
补丁 CVE-2025-22874。
安全性改进。
- 发布日期:2025 年 7 月
- Kubernetes 1.27+
- Gatekeeper 3.20.0
守护程序 3.20.0-1
Gatekeeper 版本:https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.20.0 更改:https://github.com/open-policy-agent/gatekeeper/compare/v3.19.1...v3.20.0
1.12.3
修补 CVE-2025-22874 和 GHSA-vrw8-fxc6-2r93 漏洞。
- 发布日期:2025 年 7 月
- Kubernetes 1.27+
- 守护程序 3.19.1
1.12.2
安全性改进。
- 发布日期:2025 年 6 月
- Kubernetes 1.27+
- 守护程序 3.19.1
1.11.1
安全性改进。
- 发布日期:2025 年 5 月
- Kubernetes 1.27+
- 守护程序 3.19.1
门卫 3.19.1-1
Gatekeeper 版本:https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.19.1 更改:https://github.com/open-policy-agent/gatekeeper/compare/v3.18.2...v3.19.1 修补程序 CVE-2025-22872。
1.10.1
将 policy-kubernetes-addon-prod 和 policy-kubernetes-webhook 映像更新为修补 CVE-2025-30204 和 CVE-2025-22870。
- 发布日期:2025 年 4 月
- Kubernetes 1.27+
- 守护程序 3.18.2
1.10.0
安全性改进。
默认情况下,CEL 已启用,可以继续使用 Rego。 引入了新的 CRD configpodstatuses.status.gatekeeper.sh (参考: https://github.com/open-policy-agent/gatekeeper/issues/2918)
- 发布时间:2025 年 2 月
- Kubernetes 1.27+
- 守护程序 3.18.2
门卫 3.18.2-1
Gatekeeper 版本:https://github.com/open-policy-agent/gatekeeper/releases/tag/v3.18.2 更改:https://github.com/open-policy-agent/gatekeeper/compare/v3.17.1...v3.18.2
1.9.1
安全性改进。
修补补丁 CVE-2024-45337 和 CVE-2024-45338。
- 发布日期:2025 年 1 月
- Kubernetes 1.27+
- 守护程序 3.17.1
门卫 3.17.1-5
修补补丁 CVE-2024-45337 和 CVE-2024-45338。
1.8.0
策略现在可用于评估 CONNECT 操作,例如拒绝 exec。 请注意,对于不符合规定的 CONNECT 操作,没有棕地合规方案可用,因此针对 CONNECT 操作且具有审计效果的策略是无效的。
安全性改进。
- 发布日期:2024 年 11 月
- Kubernetes 1.27+
- 守护程序 3.17.1
1.7.1
介绍 CEL 和 VAP。 公共表达式语言 (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
引入扩展,这是一种左移功能,可让你提前了解工作负载资源(部署、副本集、作业等)是否会生成可接受的 Pod。 扩展不应改变策略的行为,而是将 Gatekeeper 对 Pod 范围策略的评估从 Pod 准入时提前到工作负载准入时。 但是,为了执行此评估,必须生成一个基于工作负载中定义的 Pod 规范的假设 Pod 并进行评估,该 Pod 可能包含不完整的元数据。 例如,假设 Pod 不会包含正确的所有者引用。 由于策略行为更改会导致这种轻微风险,我们引入的扩展默认处于禁用状态。 若要为给定的策略定义启用扩展,请将 .policyRule.then.details.source 设置为 All。 内置设置在不久后将会更新,以启用此字段的参数化。 如果测试策略定义时发现为评估目的生成的假设 Pod 不完整,还可以使用源 Generated 的变异来修改假设 Pod。 有关此选项的详细信息,请参阅 Gatekeeper 文档。
扩展目前仅在 AKS 群集上可用,在 Arc 群集上不可用。
安全性改进。
- 2024 年 7 月发布
- Kubernetes 1.27+
- 门卫 3.16.3
1.6.1
安全性改进。
- 发布日期:2024 年 5 月
- 门卫 3.14.2
1.5.0
安全性改进。
- 发布日期:2024 年 5 月
- Kubernetes 1.27+
- 门卫 3.16.3
1.4.0
默认情况下启用突变和外部数据。 额外的变异 Webhook 和增加的验证 Webhook 超时上限在最坏情况下可能会增加调用的延迟。 还支持在合规性结果中查看策略定义以及设置定义版本。
- 发布日期:2024 年 5 月
- Kubernetes 1.25+
- 守护程序 3.14.0
1.3.0
为出错的策略引入错误状态,使它们与处于不符合状态的策略区分开来。 添加了对 v1 约束模板的支持,并在突变策略中使用 excludedNamespaces 参数。 添加在安装后对约束模板进行错误状态检查的功能。
- 发布时间:2024 年 2 月
- Kubernetes 1.25+
- 守护程序 3.14.0
1.2.1
- 发布日期:2023 年 10 月
- Kubernetes 1.25+
- 门卫 3.13.3
1.1.0
- 发布日期:2023 年 7 月
- Kubernetes 1.27+
- 门卫 3.11.1
1.0.1
- 发布日期:2023 年 6 月
- Kubernetes 1.24+
- 门卫 3.11.1
1.0.0
kubernetes Azure Policy现在支持突变来大规模修正 AKS 群集!
移除加载项
从 AKS 移除加载项
若要从 AKS 群集中删除Azure Policy加载项,请使用Azure门户或Azure CLI:
Azure门户
通过在Azure门户中选择“所有服务启动 AKS 服务,然后搜索并选择Kubernetes 服务。
选择要在其中禁用Azure Policy加载项的 AKS 群集。
在 Kubernetes 服务页面的左侧选择 策略。
在主页中,选择“禁用加载项”按钮。
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 Engine 移除附加组件
注意
AKS 引擎产品现已弃用于 Azure 公有云客户。 请考虑将 Azure Kubernetes Service (AKS) 用于托管 Kubernetes 或将 Cluster 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 的记录限制
- Azure Policy Add-on for Kubernetes 只能部署到 Linux 节点池。
- 每个群集的 Azure Policy 加载项支持的最大 pod 数:10,000
- 每个策略每个群集的不符合记录数最大为500
- 每个订阅的最大不合规记录数:100万
- 不支持在 Azure Policy 加载项外部安装 Gatekeeper。 在启用“Azure Policy”附加组件之前,请卸载由先前 Gatekeeper 安装的任何组件。
- 不合规的原因不适用于 Microsoft.Kubernetes.Data 资源提供程序模式。 使用组件详细信息。
- 资源提供程序模式不支持组件级别豁免。 参数支持在Azure Policy定义中提供,用于排除和包含特定命名空间。
- 目前,仅允许内置策略使用约束模板中的
metadata.gatekeeper.sh/requires-sync-data注释配置从你的群集到 OPA 缓存的数据复制。 原因是如果不谨慎使用,它可能会显著增加 Gatekeeper Pod 的资源使用率。
配置 Gatekeeper 配置文件
不支持更改 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 Add-on/Azure Policy Extension 会在群集上部署什么?
Azure Policy加载项需要三个 Gatekeeper 组件才能运行:一个审核 Pod 和两个 Webhook Pod 副本。 还安装了一个 Azure Policy pod 和一个 Azure Policy webhook pod。
我可以预期 Azure Policy 加载项/扩展在每个群集上会消耗多少资源?
在群集上运行的 Kubernetes 组件的 Azure 策略会消耗更多资源,因为随着 Kubernetes 资源的数量和策略分配在群集中增加,审核和执行操作的需求也随之增加。
以下是可帮助你进行计划的估计值:
- 对于少于 500 个 Pod、最多 20 个约束的单个群集:每个组件 2 个 vCPU,350 MB 内存。
- 对于一个包含超过 500 个 Pod 和最多 40 个约束的单个集群:每个组件需要 3 个 vCPU 和 600 MB 内存。
是否可以对 Windows Pod 应用 Kubernetes 定义的Azure Policy?
Windows Pod 不支持安全上下文。 因此,某些 Azure 策略定义(如禁止根权限)无法在 Windows Pod 中提升,并且仅适用于 Linux Pod。
Azure Policy加载项收集哪些类型的诊断数据?
Kubernetes 的 Azure Policy 加载项收集有限的群集诊断数据。 该诊断数据是与软件和性能相关的重要技术数据。 数据以下列方式使用:
- 使Azure Policy加载项保持最新状态。
- 保持Azure Policy加载项的安全、可靠、高性能。
- 通过对加载项的使用进行聚合分析,改进Azure Policy加载项。
加载项收集的信息不是个人数据。 当前正在收集以下详细信息:
Azure Policy 插件代理版本
群集类型
群集区域
群集资源组
群集资源 ID
群集订阅 ID
群集 OS(示例:Linux)
群集所在城市
群集所在州/省
群集所在国家/地区
在策略评估过程中安装代理时Azure策略附加组件遇到的异常/错误
Azure Policy 附加组件未安装的 Gatekeeper 策略定义数量
安装 Azure Policy 加载项时要记住的一般最佳做法是什么?
- 使用具有
CriticalAddonsOnly排斥的系统节点池来计划 Gatekeeper Pod。 有关详细信息,请参阅使用系统节点池。 - 保护来自 AKS 群集的出站流量。 有关详细信息,请参阅控制群集节点的出口流量。
- 如果群集已启用
aad-pod-identity,则节点托管标识(NMI)Pod 将修改节点iptables以拦截对Azure实例元数据终结点的调用。 此配置意味着对元数据终结点发出的任何请求都将被 NMI 拦截,即使 pod 不使用aad-pod-identity。 - 可以将
AzurePodIdentityExceptionCRD 配置为通知aad-pod-identity应在不使用 NMI 进行出任何处理的情况下,代理与 CRD 中定义的标签匹配的 Pod 所发起的对元数据终结点的任何请求。 应通过配置kubernetes.azure.com/managedby: aksCRD 在aad-pod-identity中排除在 kube-system 命名空间中具有AzurePodIdentityException标签的系统 Pod。 有关详细信息,请参阅禁用特定 Pod 或应用程序的 aad-pod-identity。 若要配置异常,请安装 mic-exception YAML。
后续步骤
- 在 Azure Policy 示例中查看示例。
- 查看策略定义结构。
- 请查看理解政策效果。
- 了解如何以编程方式创建策略。
- 了解如何获取符合性数据。
- 了解如何修正不符合的资源。
- 了解什么是管理组,与使用Azure管理组来组织资源。