通过

Azure Policy 定义效果基本信息

  • 项目

Azure Policy 中的每个策略定义都在其 policyRule 中有单一 effect。 该 effect 确定了在评估匹配的策略规则时发生的情况。 如果这些效果适用于新资源、更新的资源或现有资源，则它们的行为会有所不同。

以下是支持的 Azure Policy 定义效果：

交换效果

有时，多个效果对于一个给定的策略定义可能有效。 参数通常用于指定允许的效果值 (allowedValues)，使单个定义可以在分配时更加通用。 但是，请务必注意，并非所有效果都是可交换的。 策略规则中的资源属性和逻辑可以确定是否认为某种效果对策略定义有效。 例如，具有 auditIfNotExists 效果的策略定义需要在策略规则中提供其他详细信息，对于具有 audit 效果的策略来说，则不需要这些信息。 效果的行为也不同。 audit 策略基于资源自己的属性评估资源的合规性，而 auditIfNotExists 策略基于子资源或扩展资源的属性评估资源的合规性。

以下列表提供了有关可互换效果的一些常规指导：

  • audit、deny 和 modify 或 append 通常可互换。
  • auditIfNotExists 和 deployIfNotExists 通常可互换。
  • manual 不可互换。
  • disabled 可与任何效果互换。

计算顺序

Azure Policy 首先评估创建或更新资源的请求。 Azure Policy 会创建将应用于资源的所有分配列表，然后根据每个定义评估资源。 对于资源管理器模式，Azure Policy 在将请求转交给相应的资源提供程序之前处理多个效果。 此顺序可以防止资源提供程序在资源不符合 Azure Policy 的设计治理控制时进行不必要的处理。 使用资源提供程序模式，资源提供程序管理评估和结果，并将结果报告回 Azure Policy。

  • 首先检查 disabled 以确定是否应评估策略规则。
  • 然后评估 append 和 modify。 由于这两个效果可能会改变请求，因此所做的更改可能会阻止“审核”或“拒绝”效果的触发。 这些效果仅在资源管理器模式下可用。
  • 之后再评估 deny。 通过在“审核”之前评估“拒绝”，可以防止两次记录不需要的资源。
  • 评估 audit。
  • 评估 manual。
  • 评估 auditIfNotExists。
  • 最后评估 denyAction。

资源提供程序在资源管理器模式请求上返回成功代码后，auditIfNotExists 和 deployIfNotExists 将会进行评估，以确定是否需要更多合规性日志记录或操作。

仅修改 tags 相关字段的 PATCH 请求会将策略评估限制为包含检查 tags 相关字段的条件的策略。

策略定义分层

多个分配可能会对资源产生影响。 这些分配可能处于相同或不同的范围。 这些分配中的每一个也可能具有不同的定义效果。 将单独评估每个策略的条件和效果。 例如：

  • 策略 1
    • 将资源位置限制为“chinanorth”
    • 分配到订阅 A
    • “拒绝”效果
  • 策略 2
    • 将资源位置限制为“chinaeast”
    • 分配到订阅 A 中的资源组 B
    • “审核”效果

此设置将产生以下结果：

  • 位于 chinaeast 的资源组 B 中的任何现有资源都符合策略 2，但不符合策略 1
  • 不位于 chinaeast 的资源组 B 中的任何现有资源都不符合策略 2，并且如果它们不在 westus 中，则也不符合策略 1
  • 策略 1 拒绝订阅 A 中任何不在 chinanorth 中的新资源
  • 位于 chinanorth 的订阅 A 和资源组 B 中的任何新资源将会创建，但不符合策略 2

如果策略 1 和策略 2 都具有“拒绝”效果，则情况变为：

  • 不位于 chinaeast 的资源组 B 中的任何现有资源都不符合策略 2
  • 不位于 chinanorth 的资源组 B 中的任何现有资源都不符合策略 1
  • 策略 1 拒绝订阅 A 中任何不在 chinanorth 中的新资源
  • 订阅 A 的资源组 B 中的任何新资源将被拒绝

单独评估每个分配。 因此，不存在因范围差异致使资源溜过间隙的可能性。 我们认为分层策略的最终结果是累积最多限制。 例如，如果策略 1 和策略 2 都具有 deny 效果，则重叠和冲突策略定义会阻止资源。 如果仍然需要在目标范围内创建资源，请查看每项分配的排除项，以验证策略分配是否正在影响相应的范围。

后续步骤