了解 Azure Policy 效果
Azure Policy 中的每个策略定义都有单一效果。 该效果确定了在评估匹配的策略规则时发生的情况。 如果这些效果适用于新资源、更新的资源或现有资源,则它们的行为会有所不同。
目前策略定义中支持以下效果:
交换效果
有时,多个效果对于一个给定的策略定义可能有效。 参数通常用于指定允许的效果值,使单个定义可以更加通用。 但是,请务必注意,并非所有效果都是可交换的。 策略规则中的资源属性和逻辑可以确定是否认为某种效果对策略定义有效。 例如,具有 AuditIfNotExists 效果的策略定义需要在策略规则中提供其他详细信息,对于具有 Audit 效果的策略来说,则不需要这些信息。 效果的行为也不同。 审核策略基于资源自己的属性评估资源的合规性,而 AuditIfNotExists 策略基于子资源或扩展资源的属性评估资源的合规性。
以下列表提供了有关可互换效果的一些常规指导:
- Audit、Deny 和 Modify 或 Append 通常是可交换的。
- AuditIfNotExists 和 DeployIfNotExists 通常是可交换的。
- Manual 是不可交换的。
- Disabled 可与任何效果交换。
评估顺序
Azure Policy 首先评估创建或更新资源的请求。 Azure Policy 会创建将应用于资源的所有分配列表,然后根据每个定义评估资源。 对于资源管理器模式,Azure Policy 在将请求转交给相应的资源提供程序之前处理多个效果。 此顺序可以防止资源提供程序在资源不符合 Azure Policy 的设计治理控制时进行不必要的处理。 使用资源提供程序模式,资源提供程序管理评估和结果,并将结果报告回 Azure Policy。
- 首先检查“已禁用”以确定是否应评估策略规则。
- 然后评估“附加”和“修改”。 由于这两个效果可能会改变请求,因此所做的更改可能会阻止“审核”或“拒绝”效果的触发。 这些效果仅在资源管理器模式下可用。
- 然后评估“拒绝”。 通过在“审核”之前评估“拒绝”,可以防止两次记录不需要的资源。
- 评估“审核”。
- Manual 被评估。
- AuditIfNotExists 被评估。
- denyAction 被最后评估。
资源提供程序针对资源管理器模式请求返回成功代码后,AuditIfNotExists 和 DeployIfNotExists 将进行评估,以确定是否需要更多合规性日志记录或操作。
仅修改 tags
相关字段的 PATCH
请求会将策略评估限制为包含检查 tags
相关字段的条件的策略。
追加
附加用于在创建或更新期间向请求的资源添加更多字段。 常见的示例是为存储资源指定允许的 Ip。
重要
附加用于非标记的属性。 尽管附加可以在创建或更新请求期间将标记添加到资源,但建议使用修改效果取代标记。
“附加”评估
在创建或更新资源期间,会在资源提供程序处理请求之前进行“附加”评估。 当满足策略规则的 if 条件时,“附加”会向资源添加字段。 如果“附加”效果使用其他值替代原始请求中的值,则它会充当拒绝效果并拒绝该请求。 若要将新值附加到现有数组,请使用 [*]
版本的别名。
当使用附加效果的策略定义作为评估周期的一部分运行时,它不会更改已存在的资源。 相反,它会将符合 if 条件的任意资源标记为不符合。
“附加”属性
附加效果只有“详细信息”数组,它是必需的。 因为“详细信息”是一个数组,它可能需要单个或多个字段/值对。 请参阅定义结构,获取可接受的字段列表。
“附加”示例
示例 1:单个“字段/值”对使用具有数组值的非 [*]
别名在存储帐户上设置 IP 规则。 如果非 [*]
别名是数组,则附加效果会将值附加为整个数组。 如果数组已存在,该冲突会导致拒绝事件发生。
"then": {
"effect": "append",
"details": [
{
"field": "Microsoft.Storage/storageAccounts/networkAcls.ipRules",
"value": [
{
"action": "Allow",
"value": "134.5.0.0/21"
}
]
}
]
}
示例 2:单个“字段/值”对使用具有数组值的 [*]
别名在存储帐户上设置 IP 规则。 使用 [*]
别名时,附加效果会将值附加到可能预先存在的数组。 如果数组尚不存在,将会创建它。
"then": {
"effect": "append",
"details": [
{
"field": "Microsoft.Storage/storageAccounts/networkAcls.ipRules[*]",
"value": {
"value": "40.40.40.40",
"action": "Allow"
}
}
]
}
审核
“审核”用于评估不合规资源时在活动日志中创建警告事件,但不会停止请求。
“审核”评估
“审核”是 Azure Policy 在创建或更新资源期间检查的最后一个效果。 对于资源管理器模式,Azure Policy 会将资源发送到资源提供程序。 评估资源的创建或更新请求时,Azure 策略会将 Microsoft.Authorization/policies/audit/action
操作添加到活动日志,并将资源标记为不合规。 在标准符合性评估周期期间,只会更新资源上的符合性状态。
“审核”属性
对于资源管理器模式,Audit 效果没有任何其他属性可用于策略定义的 then 条件。
对于 Microsoft.Kubernetes.Data
的资源提供程序模式,Audit 效果具有 details 的以下子属性。 新的策略定义或更新的策略定义需要使用 templateInfo
,因为 constraintTemplate
已被弃用。
- templateInfo(必需)
- 无法与
constraintTemplate
一起使用。 - sourceType(必需)
定义约束模板的源类型。 允许的值:PublicURL 或 Base64Encoded。
如果 PublicURL,则与
url
属性配合,以提供约束模板的位置。 位置必须可公开访问。警告
请勿使用 SAS URI、URL 令牌或可能以纯文本形式公开机密的任何其他内容。
如果是 Base64Encoded,则与
content
属性配合,以提供 base 64 编码的约束模板。 若要根据现有的 Open Policy Agent (OPA) Gatekeeper v3 约束模板创建自定义定义,请参阅基于约束模板创建策略定义。
- 无法与
- constraint(已弃用)
- 无法与
templateInfo
一起使用。 - 约束模板的 CRD 实现。 使用通过值传递的参数,如
{{ .Values.<valuename> }}
。 在下面的示例 2 中,这些值为{{ .Values.excludedNamespaces }}
和{{ .Values.allowedContainerImagesRegex }}
。
- 无法与
- constraintTemplate(已弃用)
- 无法与
templateInfo
一起使用。 - 创建或更新策略定义时必须替换为
templateInfo
。 - 约束模板 CustomResourceDefinition (CRD) 定义新约束。 该模板定义 Rego 逻辑、约束架构和通过 Azure Policy 的值传递的约束参数。 有关详细信息,请转到 Gatekeeper 约束。
- 无法与
- constraintInfo(可选)
- 不能与
constraint
、constraintTemplate
、apiGroups
、kinds
、scope
、namespaces
、excludedNamespaces
或labelSelector
一起使用。 - 如果未提供
constraintInfo
,则可以从templateInfo
和策略生成约束。 - sourceType(必需)
定义约束的源类型。 允许的值:PublicURL 或 Base64Encoded。
如果是 PublicURL,则与属性
url
配对以提供约束的位置。 位置必须可公开访问。警告
请勿在
url
或可能公开机密的任何其他内容中使用 SAS URI 或令牌。
- 不能与
- 命名空间(可选)
- 要将策略评估限制为的 Kubernetes 命名空间的数组。
- 空值或缺失值会导致策略评估包含所有未在 excludedNamespaces 中定义的命名空间。
- excludedNamespaces(可选)
- 要从策略评估中排除的 Kubernetes 命名空间的数组。
- labelSelector(可选)
- 一个包含 matchLabels(对象)和 matchExpression(数组)属性的对象,用于指定要针对所提供标签和选择器的匹配策略评估包含哪些 Kubernetes 资源。
- 空值或缺失值会导致策略评估包括所有标签和选择器,但 excludedNamespaces 中定义的命名空间除外。
- scope(可选)
- 包含范围属性的字符串,用于指定要匹配群集范围的资源还是命名空间范围的资源。
- apiGroups(使用 templateInfo 时需要)
- 包含要匹配的 API 组的数组。 空数组 (
[""]
) 是核心 API 组。 - 不允许为 apiGroups 定义
["*"]
。
- 包含要匹配的 API 组的数组。 空数组 (
- kinds(使用 templateInfo 时需要)
- 一个数组,其中包含要将评估限制到的 Kubernetes 对象的类型。
- 不允许为 kinds 定义
["*"]
。
- values(可选)
- 定义要传递给约束的任何参数和值。 每个值必须存在并匹配约束模板 CRD 的验证 openAPIV3Schema 部分中的属性。
“审核”示例
示例 1:对资源管理器模式使用 Audit 效果。
"then": {
"effect": "audit"
}
示例 2:对 Microsoft.Kubernetes.Data
的资源提供程序模式使用 Audit 效果。 details.templateInfo 中的其他信息声明了 PublicURL 的使用,并将 url
设置为约束模板的位置,以在 Kubernetes 中用于限制允许的容器镜像。
"then": {
"effect": "audit",
"details": {
"templateInfo": {
"sourceType": "PublicURL",
"url": "https://store.policy.core.windows.net/kubernetes/container-allowed-images/v1/template.yaml",
},
"values": {
"imageRegex": "[parameters('allowedContainerImagesRegex')]"
},
"apiGroups": [
""
],
"kinds": [
"Pod"
]
}
}
AuditIfNotExists
AuditIfNotExists 对与匹配 if 条件的资源相关的资源启用审核,但没有在 then 条件的 details 中指定的属性 。
AuditIfNotExists 评估
AuditIfNotExists 在资源提供程序处理资源创建或更新请求并返回成功状态代码后运行。 如果没有相关资源或如果由 ExistenceCondition 定义的资源未评估为 true,则会发生审核。 对于新资源和已更新的资源,Azure Policy 会将 Microsoft.Authorization/policies/audit/action
操作添加到活动日志,并将该资源标记为不合规。 触发后,满足 if 条件的资源是标记为不符合的资源。
AuditIfNotExists 属性
AuditIfNotExists 效果的“details”属性具有定义要匹配的相关资源的所有子属性。
- Type(必选)
- 指定要匹配的相关资源的类型。
- 如果 type 是 if 条件资源下的一个资源类型,则策略会在已评估资源范围内查询此“type”的资源。 否则,策略会在与已评估资源相同的资源组或订阅内进行查询,具体取决于 existenceScope。
- Name(可选)
- 指定要匹配的资源的确切名称,并使策略提取一个特定资源,而不是指定类型的所有资源。
- 当 if.field.type 和 then.details.type 的条件值匹配时,Name 将变为必需且必须为
[field('name')]
或子资源的[field('fullName')]
。 但是,应考虑改用审核效果。
注意
可组合使用“类型”和“名称”段,以一般方式检索嵌套资源。
要检索特定资源,可以使用 "type": "Microsoft.ExampleProvider/exampleParentType/exampleNestedType"
和 "name": "parentResourceName/nestedResourceName"
。
要检索嵌套资源的集合,可以提供通配符 ?
来代替姓氏段。 例如,"type": "Microsoft.ExampleProvider/exampleParentType/exampleNestedType"
和 "name": "parentResourceName/?"
。 这可以与 field 函数结合使用,来访问与所评估的资源相关的资源,例如 "name": "[concat(field('name'), '/?')]"
。”
- ResourceGroupName(可选)
- 允许相关资源的匹配来自不同的资源组。
- 如果 type 是 if 条件资源下的一个资源,则不适用。
- 默认值是 if 条件资源的资源组。
- ExistenceScope(可选)
- 允许的值为 Subscription 和 ResourceGroup。
- 设置从中获取相关资源以在其中进行匹配的范围。
- 如果 type 是 if 条件资源下的一个资源,则不适用。
- 对于 ResourceGroup,将限制为 ResourceGroupName 中的资源组(如果指定)。 如果未指定 ResourceGroupName,则将限制为 if 条件资源的资源组,这是默认行为。
- 对于 Subscription,则查询全部订阅以获取相关资源。 应在订阅或更高级别设置分配范围,以便进行正确评估。
- 默认值是 ResourceGroup。
- EvaluationDelay(可选)
- 指定何时应该评估相关资源的存在性。 延迟仅用于作为创建或更新资源请求的结果的评估。
- 允许的值为
AfterProvisioning
、AfterProvisioningSuccess
、AfterProvisioningFailure
或 ISO 8601 持续时间(介于 0 到 360 分钟之间)。 - AfterProvisioning 值会检查在策略规则的 IF 条件中进行评估的资源的预配结果。
AfterProvisioning
在完成预配后运行,与结果无关。 如果预配的时间超过 6 小时,则在确定 AfterProvisioning 评估延迟时,它会被视为失败。 - 默认值为
PT10M
(10 分钟)。 - 指定较长的评估延迟可能会导致资源的已记录符合性状态在下一个 评估触发器之前不会更新。
- ExistenceCondition(可选)
- 如果未指定,任何 type 的相关资源均满足此效果,并且不会触发审核。
- 使用与 if 条件的策略规则相同的语言,但会分别针对每个相关资源进行评估。
- 如果任何匹配的相关资源评估结果为 true,该效果就会得到满足并且不会触发审核。
- 可以使用 [field()] 检查 if 条件中的值的等效性。
- 例如,可用于验证父资源(位于 if 条件中)与匹配的相关资源位于相同的资源位置。
AuditIfNotExists 示例
示例:评估虚拟机以确定是否存在反恶意软件扩展,然后在缺失时进行审核。
{
"if": {
"field": "type",
"equals": "Microsoft.Compute/virtualMachines"
},
"then": {
"effect": "auditIfNotExists",
"details": {
"type": "Microsoft.Compute/virtualMachines/extensions",
"existenceCondition": {
"allOf": [
{
"field": "Microsoft.Compute/virtualMachines/extensions/publisher",
"equals": "Microsoft.Azure.Security"
},
{
"field": "Microsoft.Compute/virtualMachines/extensions/type",
"equals": "IaaSAntimalware"
}
]
}
}
}
}
拒绝
“拒绝”用于通过策略定义防止与定义的标准不匹配的资源请求,并使请求失败。
“拒绝”评估
在资源管理器模式下创建或更新匹配的资源时,Deny 会在发送给资源提供程序之前阻止请求。 该请求返回为 403 (Forbidden)
。 在门户中,可以将 Forbidden(禁止)视为策略分配阻止的部署状态。 对于资源提供程序模式,资源提供程序管理资源的评估。
在评估现有资源期间,与“拒绝”策略定义匹配的资源将标记为不合规。
“拒绝”属性
对于资源管理器模式,Deny 效果没有更多属性可用于策略定义的 then 条件。
对于 Microsoft.Kubernetes.Data
的资源提供程序模式,deny 效果具有 details 的以下子属性。 新的策略定义或更新的策略定义需要使用 templateInfo
,因为 constraintTemplate
已被弃用。
- templateInfo(必需)
- 无法与
constraintTemplate
一起使用。 - sourceType(必需)
定义约束模板的源类型。 允许的值:PublicURL 或 Base64Encoded。
如果 PublicURL,则与
url
属性配合,以提供约束模板的位置。 位置必须可公开访问。警告
请勿在
url
或可能公开机密的任何其他内容中使用 SAS URI 或令牌。如果是 Base64Encoded,则与
content
属性配合,以提供 base 64 编码的约束模板。 若要根据现有的 Open Policy Agent (OPA) Gatekeeper v3 约束模板创建自定义定义,请参阅基于约束模板创建策略定义。
- 无法与
- 约束选项(可选)
- 无法与
templateInfo
一起使用。 - 约束模板的 CRD 实现。 使用通过值传递的参数,如
{{ .Values.<valuename> }}
。 在下面的示例 2 中,这些值为{{ .Values.excludedNamespaces }}
和{{ .Values.allowedContainerImagesRegex }}
。
- 无法与
- constraintTemplate(已弃用)
- 无法与
templateInfo
一起使用。 - 创建或更新策略定义时必须替换为
templateInfo
。 - 约束模板 CustomResourceDefinition (CRD) 定义新约束。 该模板定义 Rego 逻辑、约束架构和通过 Azure Policy 的值传递的约束参数。 有关详细信息,请转到 Gatekeeper 约束。
- 无法与
- constraintInfo(可选)
- 不能与
constraint
、constraintTemplate
、apiGroups
或kinds
一起使用。 - 如果未提供
constraintInfo
,则可以从templateInfo
和策略生成约束。 - sourceType(必需)
定义约束的源类型。 允许的值:PublicURL 或 Base64Encoded。
如果是 PublicURL,则与属性
url
配对以提供约束的位置。 位置必须可公开访问。警告
请勿在
url
或可能公开机密的任何其他内容中使用 SAS URI 或令牌。
- 不能与
- 命名空间(可选)
- 要将策略评估限制为的 Kubernetes 命名空间的数组。
- 空值或缺失值会导致策略评估包括所有命名空间,但 excludedNamespaces 中定义的命名空间除外。
- excludedNamespaces(必需)
- 要从策略评估中排除的 Kubernetes 命名空间的数组。
- labelSelector(必需)
- 一个包含 matchLabels(对象)和 matchExpression(数组)属性的对象,用于指定要针对所提供标签和选择器的匹配策略评估包含哪些 Kubernetes 资源。
- 空值或缺失值会导致策略评估包括所有标签和选择器,但 excludedNamespaces 中定义的命名空间除外。
- apiGroups(使用 templateInfo 时需要)
- 包含要匹配的 API 组的数组。 空数组 (
[""]
) 是核心 API 组。 - 不允许为 apiGroups 定义
["*"]
。
- 包含要匹配的 API 组的数组。 空数组 (
- kinds(使用 templateInfo 时需要)
- 一个数组,其中包含要将评估限制到的 Kubernetes 对象的类型。
- 不允许为 kinds 定义
["*"]
。
- values(可选)
- 定义要传递给约束的任何参数和值。 每个值都必须在约束模板 CRD 中存在。
“拒绝”示例
示例 1:对资源管理器模式使用 Deny 效果。
"then": {
"effect": "deny"
}
示例 2:对 Microsoft.Kubernetes.Data
的资源提供程序模式使用 Deny 效果。 details.templateInfo 中的其他信息声明了 PublicURL 的使用,并将 url
设置为约束模板的位置,以在 Kubernetes 中用于限制允许的容器镜像。
"then": {
"effect": "deny",
"details": {
"templateInfo": {
"sourceType": "PublicURL",
"url": "https://store.policy.core.windows.net/kubernetes/container-allowed-images/v1/template.yaml",
},
"values": {
"imageRegex": "[parameters('allowedContainerImagesRegex')]"
},
"apiGroups": [
""
],
"kinds": [
"Pod"
]
}
}
DenyAction
DenyAction
用于根据对资源的预期操作大规模阻止请求。 目前唯一支持的操作是 DELETE
。 此效果和操作名称有助于防止意外删除关键资源。
DenyAction 评估
提交具有适用操作名称和目标范围的请求调用时,denyAction
会阻止请求成功。 该请求返回为 403 (Forbidden)
。 在门户中,可以将 Forbidden(禁止)视为策略分配阻止的部署状态。
Microsoft.Authorization/policyAssignments
、Microsoft.Authorization/denyAssignments
、Microsoft.Blueprint/blueprintAssignments
、Microsoft.Resources/deploymentStacks
、Microsoft.Resources/subscriptions
和 Microsoft.Authorization/locks
都免于强制实施 DenyAction,以防止出现锁定情况。
订阅删除
策略不会阻止在删除订阅期间删除资源。
资源组删除
策略会在删除资源组期间根据 DenyAction
策略评估支持位置和标记的资源。 只有在策略规则中将 cascadeBehaviors
设置为 deny
的策略才会阻止删除资源组。 策略不会阻止移除不支持位置和标记的资源,也不会阻止移除任何具有 mode:all
的策略。
级联删除
当删除父资源会隐式删除其所有子资源时,即发生级联删除。 当删除操作针对的是父资源时,策略不会阻止移除子资源。 例如,Microsoft.Insights/diagnosticSettings
是 Microsoft.Storage/storageaccounts
的子资源。 如果 denyAction
策略靶向 Microsoft.Insights/diagnosticSettings
,则对诊断设置(子级)的删除调用将失败,但对存储帐户(父级)的删除将隐式删除诊断设置(子级)。
下表描述了在给定适用于分配的 denyAction 策略资源和 DELETE 调用目标范围的情况下,是否会保护资源不被删除。 在此表的上下文中,索引资源是支持标记和位置的资源,非索引资源是不支持标记或位置的资源。 有关索引和非索引资源的详细信息,请参阅定义模式。 子资源是只存在于另一资源的上下文内的资源。 例如,虚拟机扩展资源是虚拟机的子级,而虚拟机是父资源。
正在删除的实体 | 适用于策略条件的实体 | 采取的操作 |
---|---|---|
资源 | 资源 | Protected |
订阅 | 资源 | Deleted |
资源组 | 索引资源 | 依赖cascadeBehaviors |
资源组 | 未编制索引的资源 | Deleted |
子资源 | 父资源 | 父级受保护;子级已删除 |
父资源 | 子资源 | Deleted |
DenyAction 属性
DenyAction 效果的“详细信息”属性具有定义操作和行为的所有子属性。
- actionNames(必需)
- 一个数组,用于指定要阻止执行的操作。
- 支持的操作名称为:
delete
。
- cascadeBehaviors(可选)
- 一个对象,用于定义通过删除资源组隐式删除资源时将遵循的行为。
- 仅在 mode 设置为
indexed
的策略定义中受支持。 - 允许的值为
allow
或deny
。 - 默认值为
deny
。
DenyAction 示例
示例:拒绝针对具有等于 prod 的标记环境的数据库帐户的任何删除调用。由于级联行为设置为“拒绝”,因此请阻止以具有适用数据库帐户的资源组为目标的任何 DELETE
调用。
{
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.DocumentDb/accounts"
},
{
"field": "tags.environment",
"equals": "prod"
}
]
},
"then": {
"effect": "denyAction",
"details": {
"actionNames": [
"delete"
],
"cascadeBehaviors": {
"resourceGroup": "deny"
}
}
}
}
DeployIfNotExists
与 AuditIfNotExists 类似,DeployIfNotExists 策略定义在条件满足时将执行模板部署。 效果设置为 DeployIfNotExists 的策略分配需要使用托管标识进行修正。
DeployIfNotExists 评估
当资源提供程序处理创建或更新订阅或资源请求并返回成功状态代码时,DeployIfNotExists 在可配置的延迟后运行。 如果没有相关资源或如果由 ExistenceCondition 定义的资源未评估为 true,则会发生模板部署。 部署持续时间取决于模板中包含资源的复杂性。
在评估周期中,具有与资源匹配的 DeployIfNotExists 效果的策略定义被标记为不合规,但不对该资源执行任何操作。 使用修正任务来修正现有不符合资源。
DeployIfNotExists 属性
DeployIfNotExists 效果的“details”属性具有定义要匹配的相关资源和要执行的模板部署的所有子属性。
- Type(必选)
- 指定要匹配的相关资源的类型。
- 如果 type 是 if 条件资源下的一个资源类型,则策略会在已评估资源范围内查询此“type”的资源。 否则,策略会在与已评估资源相同的资源组或订阅内进行查询,具体取决于 existenceScope。
- Name(可选)
- 指定要匹配的资源的确切名称,并使策略提取一个特定资源,而不是指定类型的所有资源。
- 当 if.field.type 和 then.details.type 的条件值匹配时,Name 将变为必需且必须为
[field('name')]
或子资源的[field('fullName')]
。
注意
可组合使用“类型”和“名称”段,以一般方式检索嵌套资源。
要检索特定资源,可以使用 "type": "Microsoft.ExampleProvider/exampleParentType/exampleNestedType"
和 "name": "parentResourceName/nestedResourceName"
。
要检索嵌套资源的集合,可以提供通配符 ?
来代替姓氏段。 例如,"type": "Microsoft.ExampleProvider/exampleParentType/exampleNestedType"
和 "name": "parentResourceName/?"
。 这可以与 field 函数结合使用,来访问与所评估的资源相关的资源,例如 "name": "[concat(field('name'), '/?')]"
。”
ResourceGroupName(可选)
- 允许相关资源的匹配来自不同的资源组。
- 如果 type 是 if 条件资源下的一个资源,则不适用。
- 默认值是 if 条件资源的资源组。
- 如果执行模板部署,则将其部署在此值的资源组中。
ExistenceScope(可选)
- 允许的值为 Subscription 和 ResourceGroup。
- 设置从中获取相关资源以在其中进行匹配的范围。
- 如果 type 是 if 条件资源下的一个资源,则不适用。
- 对于 ResourceGroup,将限制为 ResourceGroupName 中的资源组(如果指定)。 如果未指定 ResourceGroupName,则将限制为 if 条件资源的资源组,这是默认行为。
- 对于 Subscription,则查询全部订阅以获取相关资源。 应在订阅或更高级别设置分配范围,以便进行正确评估。
- 默认值是 ResourceGroup。
EvaluationDelay(可选)
- 指定何时应该评估相关资源的存在性。 延迟仅用于作为创建或更新资源请求的结果的评估。
- 允许的值为
AfterProvisioning
、AfterProvisioningSuccess
、AfterProvisioningFailure
或 ISO 8601 持续时间(介于 0 到 360 分钟之间)。 - AfterProvisioning 值会检查在策略规则的 IF 条件中进行评估的资源的预配结果。
AfterProvisioning
在完成预配后运行,与结果无关。 如果预配的时间超过 6 小时,则在确定 AfterProvisioning 评估延迟时,它会被视为失败。 - 默认值为
PT10M
(10 分钟)。 - 指定较长的评估延迟可能会导致资源的已记录符合性状态在下一个 评估触发器之前不会更新。
ExistenceCondition(可选)
- 如果未指定,任何 type 的相关资源均满足此效果,并且不会触发部署。
- 使用与 if 条件的策略规则相同的语言,但会分别针对每个相关资源进行评估。
- 如果任何匹配的相关资源评估结果为 true,该效果就会得到满足并且不会触发部署。
- 可以使用 [field()] 检查 if 条件中的值的等效性。
- 例如,可用于验证父资源(位于 if 条件中)与匹配的相关资源位于相同的资源位置。
roleDefinitionIds(必选)
- 此属性必须包含与可通过订阅访问的基于角色的访问控制角色 ID 匹配的字符串数组。 有关详细信息,请参阅修正 - 配置策略定义。
DeploymentScope(可选)
- 允许的值为 Subscription 和 ResourceGroup。
- 设置要触发的部署类型。 Subscription 指示在订阅级别部署,ResourceGroup 指示部署到资源组。
- 使用订阅级别部署时,必须在 Deployment 中指定 location 属性。
- 默认值是 ResourceGroup。
Deployment(必选)
- 该属性应包含完整的模板部署,因为它将传递给
Microsoft.Resources/deployments
PUT API。 有关详细信息,请参阅部署 REST API。 - 模板内嵌套的
Microsoft.Resources/deployments
应使用唯一名称以避免多个策略评估之间发生争用。 父部署的名称可通过[concat('NestedDeploymentName-', uniqueString(deployment().name))]
用作嵌套部署名称的一部分。
注意
Deployment 属性中的所有函数都将作为模板(而不是策略)的组件进行评估。 此异常是将值从策略传递到模板的 parameters 属性。 本节中模板参数名称下的 value 用于执行此值传递操作(请参阅 DeployIfNotExists 示例中的 fullDbName)。
- 该属性应包含完整的模板部署,因为它将传递给
DeployIfNotExists 示例
示例:评估 SQL Server 数据库以确定是否启用 transparentDataEncryption
。
如果未启用,则执行启用它的部署。
"if": {
"field": "type",
"equals": "Microsoft.Sql/servers/databases"
},
"then": {
"effect": "deployIfNotExists",
"details": {
"type": "Microsoft.Sql/servers/databases/transparentDataEncryption",
"name": "current",
"evaluationDelay": "AfterProvisioning",
"roleDefinitionIds": [
"/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/{roleGUID}",
"/providers/Microsoft.Authorization/roleDefinitions/{builtinroleGUID}"
],
"existenceCondition": {
"field": "Microsoft.Sql/transparentDataEncryption.status",
"equals": "Enabled"
},
"deployment": {
"properties": {
"mode": "incremental",
"template": {
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"fullDbName": {
"type": "string"
}
},
"resources": [
{
"name": "[concat(parameters('fullDbName'), '/current')]",
"type": "Microsoft.Sql/servers/databases/transparentDataEncryption",
"apiVersion": "2014-04-01",
"properties": {
"status": "Enabled"
}
}
]
},
"parameters": {
"fullDbName": {
"value": "[field('fullName')]"
}
}
}
}
}
}
已禁用
对于测试情况以及在策略定义已参数化效果时,此效果很有用。 借助这种灵活性可以禁用单个分配,而无需禁用该策略的所有分配。
注意
使用“禁用”效果的策略定义在分配后具有“符合”这一默认符合性状态。
“禁用”效果的替代是 enforcementMode,可在策略分配上设置。 enforcementMode 已禁用时,仍可评估资源。 日志(例如活动日志)和策略效果不会出现。 有关详细信息,请参阅策略分配 - 强制模式。
修改
Modify 用于在创建或更新期间在订阅或资源中添加、更新或删除属性或标记。 常见的示例是在 costCenter 等资源上更新标记。 使用修正任务来修正现有不符合资源。 单个修改规则可以有任意数量的操作。 效果设置为 Modify 的策略分配需要使用托管标识进行修正。
Modify 支持以下操作:
- 添加、替换或删除资源标记。 对于标记,除非目标资源是资源组,否则 Modify 策略的 mode 应设置为
indexed
。 - 添加或替换虚拟机和虚拟机规模集的托管标识类型 (
identity.type
) 的值。 只能修改虚拟机或虚拟机规模集的identity.type
。 - 添加或替换某些别名的值。
- 使用
Get-AzPolicyAlias | Select-Object -ExpandProperty 'Aliases' | Where-Object { $_.DefaultMetadata.Attributes -eq 'Modifiable' }
在 Azure PowerShell 4.6.0 或更高版本中,获取可与 Modify 一起使用的别名列表。
- 使用
重要
如果你正在管理标记,我们建议使用 Modify 而不要使用 Append,因为 Modify 提供更多的操作类型,且能够修正现有的资源。 但如果无法创建托管标识或 Modify 尚不支持资源属性的别名,则建议使用 Append。
修改评估
在创建或更新资源期间,修改会在资源提供程序处理请求之前进行评估。 如果策略规则的 if 条件得到满足,则 Modify 操作将应用于请求内容。 每个 Modify 操作可以指定一个条件来决定何时应用它。 将跳过条件评估为 false 的操作。
别名指定后,执行以下附加检查,确保 Modify 操作更改请求内容后不会导致资源提供程序拒绝该请求:
- 在请求 API 版本中,别名映射到的属性标记为“可修改”。
- Modify 操作中的令牌类型与请求 API 版本中的属性的预期令牌类型匹配。
如果这些检查中的任何一个失败,策略评估将回退到指定的 conflictEffect。
重要
建议包含别名的 Modify 定义采用“audit”冲突效果,避免使用 API 版本(其中映射的属性不是“可修改”)的请求失败。 如果同一别名在不同 API 版本中的行为不同,可以使用 Conditional Modify 操作来确定对每个 API 版本使用的 Modify 操作。
当使用修改效果的策略定义作为评估周期的一部分运行时,它不会更改已存在的资源。 相反,它会将符合 if 条件的任意资源标记为不符合。
修改属性
修改效果的“Details”属性包含定义修正所需权限以及用于添加、更新或删除标记值操作的所有子属性。
- roleDefinitionIds(必选)
- 此属性必须包含与可通过订阅访问的基于角色的访问控制角色 ID 匹配的字符串数组。 有关详细信息,请参阅修正 - 配置策略定义。
- 定义的角色必须包括所有授予参与者角色的操作。
- conflictEffect(可选)
- 确定在多个策略定义修改同一属性的情况下,或在 Modify 操作不适用于指定别名的情况下,哪个策略定义“胜出”。
- 对于新的或更新的资源,具有 Deny 的策略定义优先。 具有 Audit 的策略定义会跳过所有操作。 如果多个策略定义具有 deny 效果,则请求会因冲突而被拒绝。 如果所有策略定义都具有 Audit,则不处理冲突策略定义的任何操作。
- 对于现有资源,如果多个策略定义具有 deny 效果,则合规性状态为“冲突”。 如果一个或更少的策略定义具有 deny 效果,则每个分配都返回“不合规”的合规性状态。
- 可用值:audit、deny、disabled 。
- 默认值为 deny。
- 确定在多个策略定义修改同一属性的情况下,或在 Modify 操作不适用于指定别名的情况下,哪个策略定义“胜出”。
- operations(必选)
- 要在匹配资源上完成的所有标记操作的数组。
- 属性:
- operation(必选)
- 定义要在匹配资源上执行的操作。 选项为:addOrReplace添加删除。 添加行为与 附加效果类似。
- field(必选)
- 要添加、替换或删除的标记。 对于其他字段,标记名称必须遵循相同的命名约定。
- value(可选)
- 要设置标记的值。
- 如果操作是 addOrReplace 或添加,则需要此属性。
- condition(可选)
- 一个字符串,其中包含使用 Policy 函数的 Azure Policy 语言表达式,该表达式计算结果为 true 或 false 。
- 不支持以下 Policy 函数:
field()
、resourceGroup()
、subscription()
。
- operation(必选)
修改操作
操作属性数组能够以不同的方式从单个策略定义中更改多个标记。 每个操作都由操作字段和值属性组成。 操作确定修正任务对标记执行的操作,字段确定更改的标记,值定义该标记的新设置。 下面的示例进行了以下标记更改:
- 将
environment
标记设置为“Test”,即使它已存在并使用不同的值。 - 删除标记
TempResource
。 - 将
Dept
标记设置为在策略分配上配置的策略参数 DeptName。
"details": {
...
"operations": [
{
"operation": "addOrReplace",
"field": "tags['environment']",
"value": "Test"
},
{
"operation": "Remove",
"field": "tags['TempResource']",
},
{
"operation": "addOrReplace",
"field": "tags['Dept']",
"value": "[parameters('DeptName')]"
}
]
}
此操作属性具有以下选项:
Operation | 说明 |
---|---|
addOrReplace | 将定义的属性或标记和值添加到资源,即使该属性或标记已存在并使用不同的值。 |
添加 | 将定义的属性或标记和值添加到资源。 |
删除 | 从资源中删除定义的属性或标记。 |
修改示例
示例 1:添加 environment
标记并将现有 environment
标记替换为“Test”:
"then": {
"effect": "modify",
"details": {
"roleDefinitionIds": [
"/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
],
"operations": [
{
"operation": "addOrReplace",
"field": "tags['environment']",
"value": "Test"
}
]
}
}
示例 2:删除 env
标记并添加 environment
标记,或将现有 environment
标记替换为参数化的值:
"then": {
"effect": "modify",
"details": {
"roleDefinitionIds": [
"/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
],
"conflictEffect": "deny",
"operations": [
{
"operation": "Remove",
"field": "tags['env']"
},
{
"operation": "addOrReplace",
"field": "tags['environment']",
"value": "[parameters('tagValue')]"
}
]
}
}
示例 3:确保存储帐户不允许 blob 公共访问,仅在评估所用 API 版本大于或等于 2019-04-01
的请求时,才应用 Modify 操作:
"then": {
"effect": "modify",
"details": {
"roleDefinitionIds": [
"/providers/microsoft.authorization/roleDefinitions/17d1049b-9a84-46fb-8f53-869881c3d3ab"
],
"conflictEffect": "audit",
"operations": [
{
"condition": "[greaterOrEquals(requestContext().apiVersion, '2019-04-01')]",
"operation": "addOrReplace",
"field": "Microsoft.Storage/storageAccounts/allowBlobPublicAccess",
"value": false
}
]
}
}
变更(预览版)
适用于 Kubernetes 的 Azure Policy 中使用变更来修正 AKS 群集组件,例如 Pod。 此效果仅特定于 Microsoft.Kubernetes.Data策略模式定义。
若要了解更多信息,请转至了解适用于 Kubernetes 群集的 Azure Policy。
变更属性
- mutationInfo(可选)
- 不能与
constraint
、constraintTemplate
、apiGroups
或kinds
一起使用。 - 无法参数化。
- sourceType(必需)
- 定义约束的源类型。 允许的值:PublicURL 或 Base64Encoded。
- 如果是 PublicURL,则与
url
属性配对以提供变更模板的位置。 位置必须可公开访问。警告
请勿在
url
或可能公开机密的任何其他内容中使用 SAS URI 或令牌。
- 不能与
策略定义分层
资源可能会受到多个分配的影响。 这些分配可能处于相同或不同的范围。 这些分配中的每一个也可能具有不同的定义效果。 将单独评估每个策略的条件和效果。 例如:
- 策略 1
- 将资源位置限制为“chinanorth”
- 分配到订阅 A
- “拒绝”效果
- 策略 2
- 将资源位置限制为“chinaeast”
- 分配到订阅 A 中的资源组 B
- “审核”效果
此设置将产生以下结果:
- 位于“chinaeast”的资源组 B 中的任何现有资源都符合策略 2,但不符合策略 1
- 不位于“chinaeast”的资源组 B 中的任何现有资源都不符合策略 2,并且如果它们不在“chinanorth”中,则也不符合策略 1
- 订阅 A 中任何不在“chinanorth”中的新资源将会被策略 1 拒绝
- 位于“chinanorth”的订阅 A 和资源组 B 中的任何新资源将会创建,但不符合策略 2
如果策略 1 和策略 2 都具有“拒绝”效果,则情况变为:
- 不位于“chinaeast”的资源组 B 中的任何现有资源不符合策略 2
- 不位于“chinanorth”的资源组 B 中的任何现有资源不符合策略 1
- 订阅 A 中任何不在“chinanorth”中的新资源将会被策略 1 拒绝
- 订阅 A 的资源组 B 中的任何新资源将被拒绝
单独评估每个分配。 因此,不存在因范围差异致使资源溜过间隙的可能性。 我们认为分层策略的最终结果是累积最多限制。 例如,如果策略 1 和策略 2 都具有“拒绝”效果,则重叠和冲突策略定义会阻止资源。 如果仍然需要在目标范围内创建资源,请查看每项分配的排除项,以验证策略分配是否正在影响相应的范围。
后续步骤
- 在 Azure Policy 示例中查看示例。
- 查看 Azure Policy 定义结构。
- 了解如何以编程方式创建策略。
- 了解如何获取符合性数据。
- 了解如何修正不符合的资源。
- 参阅使用 Azure 管理组来组织资源,了解什么是管理组。