策略分配定义检查哪些资源受到策略定义或计划的评估。 此外,策略分配可以确定分配时该组资源的参数值,因此,可以重复使用能够处理相同资源属性并满足不同合规性需求的策略定义。
使用 JavaScript 对象表示法 (JSON) 创建策略分配。 策略分配包含以下各项的元素:
例如,以下 JSON 显示包含以下参数,且处于 DoNotEnforce 模式的示例策略分配请求:
{
"properties": {
"displayName": "Enforce resource naming rules",
"description": "Force resource names to begin with DeptA and end with -LC",
"definitionVersion": "1.*.*",
"metadata": {
"assignedBy": "Cloud Center of Excellence"
},
"enforcementMode": "DoNotEnforce",
"notScopes": [],
"policyDefinitionId": "/subscriptions/{mySubscriptionID}/providers/Microsoft.Authorization/policyDefinitions/ResourceNaming",
"nonComplianceMessages": [
{
"message": "Resource names must start with 'DeptA' and end with '-LC'."
}
],
"parameters": {
"prefix": {
"value": "DeptA"
},
"suffix": {
"value": "-LC"
}
},
"identity": {
"principalId": "<PrincipalId>",
"tenantId": "<TenantId>",
"identityType": "SystemAssigned",
"userAssignedIdentities": null
},
"location": "chinaeast2",
"resourceSelectors": [],
"overrides": [],
}
}
Scope
用于分配资源创建时间的范围是资源适用性的主要驱动因素。 有关分配范围的详细信息,请参阅 Azure Policy 中的
策略定义 ID 和版本
此字段必须是策略定义或计划定义的完整路径名称。
policyDefinitionId 是字符串,而不是数组。 每次评估策略分配时,都将检索已分配的策略定义或计划的最新内容。 如果经常要一起分配多个策略,我们建议改用计划。
对于内置定义和计划,可以使用具体 definitionVersion 来评估这些定义和计划。 默认情况下,版本会设置为最新的主版本,并自动引入次要版本和修补程序更改。
- 若要自动引入定义的任何次要更改,版本号将为
#.*.*。 通配符表示自动引入更新。 - 若要固定到次要版本路径,版本格式将为
#.#.*。 - 出于安全目的,必须自动引入所有修补程序更改。 修补更改仅限于文本更改和不可挽回的方案。
显示名称和说明
使用 displayName 和 description 来标识策略分配,并提供它与特定资源集配合使用时的上下文。
displayName 的最大长度为 128 个字符, 的最大长度为 512 个字符。description
元数据
metadata 可选属性用于存储关于策略分配的信息。 客户可在 metadata 中定义对其组织有用的任何属性和值。 但是,Azure Policy使用的一些common属性。 每个 metadata 属性有 1024 个字符的限制。
常见元数据属性
-
assignedBy(字符串):创建此分配的安全主体的友好名称。 -
createdBy(字符串):创建分配的安全主体的 GUID。 -
createdOn(字符串):用于表示分配创建时间的通用 ISO 8601 日期时间格式。 -
updatedBy(字符串):更新分配的安全主体的友好名称(如果有)。 -
updatedOn(字符串):分配更新时间的通用 ISO 8601 日期时间格式(如果有)。
场景特定的元数据属性
parameterScopes(对象):键值对的集合,其中键与 strongType 配置的参数名称匹配,值定义门户中使用的资源范围,该范围通过匹配 strongType 来提供可用资源的列表。 如果范围不同于分配范围,门户将设置此值。 如果已设置,则在门户中编辑策略分配后,会自动将参数的作用域设置为此值。 但是,该作用域不会锁定到值,并且可以更改为其他作用域。下面的
parameterScopes示例是针对名为 strongType 的参数backupPolicyId,用于在门户中编辑分配时设置资源选择的范围。"metadata": { "parameterScopes": { "backupPolicyId": "/subscriptions/{SubscriptionID}/resourcegroups/{ResourceGroupName}" } }evidenceStorages(对象):建议的默认存储帐户,该帐户应该用于保存证明具有manual效果的策略分配的证据。displayName属性是存储帐户的名称。evidenceStorageAccountID属性是存储帐户的资源 ID。evidenceBlobContainer属性是计划在其中存储证据的 Blob 容器名称。{ "properties": { "displayName": "A contingency plan should be in place to ensure operational continuity for each Azure subscription.", "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/{definitionId}", "metadata": { "evidenceStorages": [ { "displayName": "Default evidence storage", "evidenceStorageAccountId": "/subscriptions/{subscriptionId}/resourceGroups/{rg-name}/providers/Microsoft.Storage/storageAccounts/{storage-account-name}", "evidenceBlobContainer": "evidence-container" } ] } } }
资源选择器
可选的 resourceSelectors 属性使你能够根据资源位置、资源类型或资源是否具有位置等因素逐步推出策略分配,从而推进安全部署做法 (SDP)。 使用资源选择器时,Azure Policy仅评估适用于资源选择器中的规范的资源。 资源选择器也可以用来以同样方式缩小 豁免 和 注册 范围。
在以下示例方案中,仅当资源的位置为 “中国东部 2 ”或 “中国北部 2”时,才会评估新的策略分配。
{
"properties": {
"policyDefinitionId": "/subscriptions/{subId}/providers/Microsoft.Authorization/policyDefinitions/ResourceLimit",
"definitionVersion": "1.1.*",
"resourceSelectors": [
{
"name": "SDPRegions",
"selectors": [
{
"kind": "resourceLocation",
"in": [
"chinaeast2",
"chinanorth2"
]
}
]
}
]
},
"systemData": { ...
},
"id": "/subscriptions/{subId}/providers/Microsoft.Authorization/policyAssignments/ResourceLimit",
"type": "Microsoft.Authorization/policyAssignments",
"name": "ResourceLimit"
}
准备好扩展策略的评估范围时,只需更新任务即可。 以下示例演示了策略分配,其中又添加了两个Azure区域添加到 SDPRegions 选择器。 注意,在此示例中,SDP 表示“安全部署做法”:
{
"properties": {
"policyDefinitionId": "/subscriptions/{subId}/providers/Microsoft.Authorization/policyDefinitions/ResourceLimit",
"definitionVersion": "1.1.*",
"resourceSelectors": [
{
"name": "SDPRegions",
"selectors": [
{
"kind": "resourceLocation",
"in": [
"chinaeast2",
"chinanorth2",
"chinanorth3"
]
}
]
}
]
},
"systemData": { ...
},
"id": "/subscriptions/{subId}/providers/Microsoft.Authorization/policyAssignments/ResourceLimit",
"type": "Microsoft.Authorization/policyAssignments",
"name": "ResourceLimit"
}
资源选择器具有以下属性:
name:资源选择器的名称。selectors:(可选)用于确定哪部分资源适用于策略分配的因素应进行合规性评估。kind:选择器的属性,用于描述哪些特征将缩小评估的资源集。 每种只能在一个资源选择器中使用一次。 允许值包括:resourceLocation:此属性用于根据资源类型选择资源。 不能在同一资源选择器中作为resourceWithoutLocation使用。resourceType:此属性用于根据资源类型选择资源。resourceWithoutLocation:此属性用于选择没有位置的订阅级资源。 当前仅支持subscriptionLevelResources。 不能在同一资源选择器中作为resourceLocation使用。
in:特定kind的允许值列表。 无法与notIn一起使用。 最多可包含 50 个值。notIn:不允许的特定kind值列表。 无法与in一起使用。 最多可包含 50 个值。
资源选择器可以包含多个 selectors。 若要适用于资源选择器,资源必须满足其所有选择器指定的要求。 此外,最多可在一个分配中指定 10 个 resourceSelectors。 当范围内的资源满足其中任一资源选择器时,将对其进行评估。
覆盖
可选的 overrides 属性可以更改策略定义的效果,而无需修改基础策略定义或在策略定义中使用参数化效果。
效果替代的最常见用例是具有大量关联策略定义的策略计划。 在这种情况下,管理多个策略效果可能耗费大量管理精力,尤其是在需要不时更新效果的情况下。 替代可用于同时更新计划内多个策略定义的效果。
我们分析一个示例。 假设你有一个名为 CostManagement 的策略计划,其中包含 policyDefinitionReferenceIdcorpVMSizePolicy 的自定义策略定义和一个 audit 效果。 假设你想要分配 CostManagement 项目,但还不希望看到针对该策略的合规报告。 此策略的“audit”效果可通过计划分配上的替代替换为“disabled”,如以下示例所示:
{
"properties": {
"policyDefinitionId": "/subscriptions/{subId}/providers/Microsoft.Authorization/policySetDefinitions/CostManagement",
"overrides": [
{
"kind": "policyEffect",
"value": "disabled",
"selectors": [
{
"kind": "policyDefinitionReferenceId",
"in": [
"corpVMSizePolicy"
]
}
]
}
]
},
"systemData": { ...
},
"id": "/subscriptions/{subId}/providers/Microsoft.Authorization/policyAssignments/CostManagement",
"type": "Microsoft.Authorization/policyAssignments",
"name": "CostManagement"
}
替代的另一个常见用例是推出新版本的定义。 有关安全更新分配版本的建议步骤,请参阅“策略安全部署”。
替代值具有以下属性:
kind:分配替代的属性。 支持的种类是policyEffect和policyVersion。value:替代现有值的新值。 对于kind: policyEffect,支持的值为效果。 对于kind: policyVersion,支持的版本号必须大于或等于分配中指定的definitionVersion。selectors: (可选)用于确定替代适用的策略分配范围的属性。kind:选择器的属性,用于描述哪些特征将缩小替代的范围。kind: policyEffect允许的值:policyDefinitionReferenceId:该属性指定计划分配中的哪些策略定义适用于效果替代。resourceLocation:此属性用于根据资源类型选择资源。 不能在同一资源选择器中作为resourceWithoutLocation使用。
kind: policyVersion允许的值:-
resourceLocation:此属性用于根据资源类型选择资源。 不能在同一资源选择器中作为resourceWithoutLocation使用。
in:特定kind的允许值列表。 无法与notIn一起使用。 最多可包含 50 个值。notIn:不允许的特定kind值列表。 无法与in一起使用。 最多可包含 50 个值。
通过在 policyDefinitionReferenceId 数组中指定多个值,一个替代可以替换多个策略的效果。 一个替代可用于最多 50 个 policyDefinitionReferenceId,一次策略分配最多可以包含 10 个替代,它们按指定顺序进行评估。 创建分配之前,将根据策略规则和参数允许值列表验证替代中选择的效果(如果效果已参数化)。
强制模式
该enforcementMode属性使客户能够控制策略对现有资源的结果,而无需触发策略效应或触发 Azure 活动日志中的条目。
此属性具有以下值:
| 模式 | JSON 值 | 类型 | 手动修正 | 活动日志条目 | 说明 |
|---|---|---|---|---|---|
| 已启用 | 默认 | 字符串 | 是 | 是 | 在创建或更新资源期间强制实施策略效果。 |
| 已禁用 | DoNotEnforce | 字符串 | 是 | 否 | 在创建或更新资源期间不强制实施策略效果。 |
| Enroll | Enroll | 字符串 | 是 | 注册资源是的 | 策略效果仅在资源创建或更新时对已注册的资源执行。 |
如果未在策略或计划定义中指定 enforcementMode,则使用值 Default。 即使将 策略设置为 DoNotEnforce,也可以启动 enforcementMode。 有关 Enroll 模式的更多信息,请参见 Azure Policy 注册结构。
用于 Default 标准策略分配,策略效果应适用于所有范围内的资源。
当你想在执行前评估保单分配时使用 DoNotEnforce 。 该模式适合测试新赋值、审查合规影响,或在政策效果执行前验证策略逻辑。
选择强制模式
使用与你希望分配如何影响资源的执行模式相匹配。
| 情景 | 强制模式 |
|---|---|
| 在资源创建或更新过程中,对所有范围内的资源执行策略效应。 | Default |
| 在不强制执行策略效果或将拒绝条目写入 Azure 活动日志的情况下评估合规性。 | DoNotEnforce |
| 通过保单注册,让分配可供分阶段执行。 | Enroll |
用于 Default 标准策略分配,策略效果应适用于所有范围内的资源。
当你想在执行前评估保单分配时使用 DoNotEnforce 。 该模式适合测试新赋值、审查合规影响,或在政策效果执行前验证策略逻辑。
当你想通过保单注册将转让分阶段执行时使用 Enroll 。 在此模式下,范围所有者可以创建注册资源,指示应对特定范围执行。 当没有注册资源时,策略评估与默认使用 DoNotEnforce 分配相同,但该行为可配置。 当你想慢慢批量处理并添加子望远镜到任务时,这个模式非常有用。
排除的范围
分配的范围涵盖所有子资源容器和子资源。 如果子资源容器或子资源不应应用定义,则可以通过设置 将每个项从计算中排除notScopes。 此属性是一个数组,用于从计算中排除一个或多个资源容器或资源。
notScopes 可以在创建初始分配后添加或更新。
注意
排除的资源与免除的资源不同。 有关详细信息,请参阅 Azure Policy 中的
不合规信息
若要设置描述资源为何不符合策略或计划定义的自定义消息,请在分配定义中设置 nonComplianceMessages。 此节点是一个 message 条目的数组。 此自定义消息是对不符合性默认错误消息的补充,并且是可选的。
重要
对于具有 资源管理器 模式定义的定义或计划,仅支持不合规的自定义消息。
"nonComplianceMessages": [
{
"message": "Default message"
}
]
如果分配是针对某个计划的,则可以为该计划中的每个策略定义配置不同的消息。 消息使用在计划定义中配置的 policyDefinitionReferenceId 值。 有关详细信息,请参阅策略定义属性。
"nonComplianceMessages": [
{
"message": "Default message"
},
{
"message": "Message for just this policy definition by reference ID",
"policyDefinitionReferenceId": "10420126870854049575"
}
]
参数
此策略分配段为策略定义或计划定义中定义的参数提供值。 通过这种设计,可对不同的资源重复使用某个策略或计划定义,但需要检查不同的业务价值或成果。
"parameters": {
"prefix": {
"value": "DeptA"
},
"suffix": {
"value": "-LC"
}
}
在此示例中,事先在策略定义中定义的参数为 prefix 和 suffix。 此特定策略分配将 prefix 设置为 DeptA,将 suffix 设置为 -LC。 可对不同部门的一组不同参数重复使用同一个策略定义,以降低策略定义的重复性和复杂性,同时提供灵活性。
身份
效果设置为 deployIfNotExists 或 modify 的策略分配必须具有标识属性才能对不合规的资源进行修正。 单个策略分配只能与一个由系统分配或由用户分配的托管标识相关联。 但是,如有必要,可为该标识分配多个角色。
使用系统分配的托管标识的分配还必须指定顶级 location 属性来确定其部署位置。 无法将位置设置为 global,并且位置无法更改。
location 属性仅在 Rest API 版本 2018-05-01 及更高版本中指定。 如果在未使用标识的分配中指定位置,将忽略该位置。
# System-assigned identity
"identity": {
"principalId": "<PrincipalId>",
"tenantId": "<TenantId>",
"identityType": "SystemAssigned",
"userAssignedIdentities": null
},
"location": "chinaeast2",
...
# User-assigned identity
"identity": {
"identityType": "UserAssigned",
"userAssignedIdentities": {
"/subscriptions/SubscriptionID/resourceGroups/{rgName}/providers/Microsoft.ManagedIdentity/userAssignedIdentities/test-identity": {}
}
},
注意
对于deployIfNotExists策略,在 ARM 模板部署中始终使用分配标识。 但是,创建或更新目标资源时,请求者的标识用于评估。
例如,假设策略在 Microsoft.Insights/diagnosticSettings 上部署 Microsoft.KeyVault/vaults。 创建密钥保管库时,调用方标识将用于获取Microsoft.Insights/diagnosticSettings资源来评估策略定义的存在条件。 如果满足条件,则策略分配的标识将用于在密钥保管库上部署诊断设置。 这意味着调用方需要 Microsoft.Insights/diagnosticSettings/read permissions,分配需要 Microsoft.Insights/diagnosticSettings/write permissions。
后续步骤
- 了解策略定义结构。
- 了解如何以编程方式创建策略。
- 了解如何获取符合性数据。
- 了解如何修正不符合的资源。
- 查看管理组与 使用Azure管理组来组织资源。