【问题标题】:How do I combine multiple statements in an Azure policy definition?如何在 Azure 策略定义中组合多个语句?
【发布时间】:2020-04-16 17:22:50
【问题描述】:

我想创建一个自定义 Azure Policy JSON,它可以读取 Azure 资源并确保它遵循我们的标准化命名约定。例如,我正在尝试为虚拟机、云服务和 Redis 缓存进行设置。

{
"if": {
    "allof": [
        {
            "field": "type",
            "equals": "Microsoft.Compute/virtualMachines"
        },
        {
            "not": {
                "anyOf": [
                    {
                        "field": "name",
                        "match": "gz?????????#?##"
                    }
                ]
            }
        }
    ]
},
"then": {
    "effect": "[parameters('effect')]"
}

"if": {
    "allof": [
        {
            "field": "type",
            "equals": "Microsoft.ClassicCompute/domainNames"
        },
        {
            "not": {
                "anyOf": [
                    {
                        "field": "name",
                        "match": "GZ?-??????-??#-???-??????-###"
                    }
                ]
            }
        }
    ]
},
"then": {
    "effect": "[parameters('effect')]"
}

"if": {
    "allof": [
        {
            "field": "type",
            "equals": "Microsoft.Cache/Redis"
        },
        {
            "not": {
                "anyOf": [
                    {
                        "field": "name",
                        "match": "gz?????????#???###"
                    }
                ]
            }
        }
    ]
},
"then": {
    "effect": "[parameters('effect')]"
}

}

我认为 Azure 不允许有多个 IF,就像我尝试设置它的方式一样。我想要它做的是:

如果资源是虚拟机并且不符合该约定,则进行审核。 如果资源是云服务并且不符合该约定,则进行审核。 如果资源是 Redis 缓存并且不符合该约定,则进行审核。

Updated JSON

【问题讨论】:

    标签: azure azure-policy


    【解决方案1】:

    您应该使用initiative(策略集定义)来组织多个这样的相关策略。这比使用每种资源类型的条件的单一策略定义更易于维护,并且允许您查看整个命名约定策略集和每个单独策略的合规性结果。

    例如:

      "properties": {
        "displayName": "Naming conventions",
        "policyType": "Custom",
        "parameters": {
          "effect": {
            "type": "String",
            "defaultValue": "Audit"
          }
        },
        "policyDefinitions": [
          {
            "policyDefinitionId": "/subscriptions/<SUBSCRIPTION ID>/providers/Microsoft.Authorization/policyDefinitions/<YOUR VIRTUAL MACHINE NAMING CONVENTION POLICY ID>",
            "parameters": {
              "effect": {
                "value": "[parameters('effect')]"
              }
            }
          },
          {
            "policyDefinitionId": "/subscriptions/<SUBSCRIPTION ID>/providers/Microsoft.Authorization/policyDefinitions/<YOUR DOMAIN NAME NAMING CONVENTION POLICY ID>",
            "parameters": {
              "effect": {
                "value": "[parameters('effect')]"
              }
            }
          }
        ]
      }
    }
    

    我不推荐,但是如果你必须在一个定义中组合多个类型,那么你可以使用anyOf,例如:

    {
      "if": {
        "anyOf": [
          {
            "allOf": [
              {
                "field": "type",
                "equals": "Microsoft.Compute/virtualMachines"
              },
              {
                "not": {
                    "field": "name",
                    "match": "gz?????????#?##"
                }
              }
            ]
          },
          {
            "allOf": [
              {
                "field": "type",
                "equals": "Microsoft.ClassicCompute/domainNames"
              },
              {
                "not": {
                  "field": "name",
                  "match": "GZ?-??????-??#-???-??????-###"
                }
              }
            ]
          }
        ]
      },
      "then" : {
        "effect" : "audit"
      }
    }
    

    【讨论】:

    • 谢谢 Sapphiremirage,请问您为什么不推荐这个?这会导致什么问题?
    • 我不建议在一个定义中组合多种类型,因为它可能难以维护。添加新类型或更改类型的命名约定时,您必须 (1) 在更新策略定义时注意不要破坏策略定义 (2) 在测试时筛选合规性结果中的所有其他类型它。如果每种类型都有单独的 policyDefinition,您可以独立地创作/测试/部署。您仍然可以通过将它们全部放在 policySetDefinition(倡议)中来获得方案的总体合规性百分比。
    • 嘿 Sapphiremirage,目前,我现在可以为 APM 做事的唯一方法是在定义中包含多种类型。这是正确的吗?
    猜你喜欢
    • 2021-12-27
    • 2021-03-06
    • 1970-01-01
    • 2021-10-27
    • 1970-01-01
    • 1970-01-01
    • 2016-06-07
    • 1970-01-01
    • 2014-07-27
    相关资源
    最近更新 更多