Demystifying Azure Security - Creating a Custom Policy - Part 2 - Understanding the Policy Structure

This blog post is part of the Demystifying Azure Security series. All posts in the series can be found here: Demystifying Azure Security - Series Index. Ensure that you have read earlier blogs about the basics of Azure Policies before reading this blog.

Structure of a Policy JSON Definition

Policy definitions are written in JSON. The policy definition contains elements for:

• mode
• parameters
• display name
• description
• policy rule
  • logical evaluation
  • effect

Let's understand these components with the help of an example. Earlier we saw how to find the definition of existing policies. One such policy is: "Allowed locations". This policy restricts the location in Azure where resources can be deployed. The definition for the policy looks like below:

{
  "properties": {
    "mode": "all",
    "parameters": {
      "allowedLocations": {
        "type": "array",
        "metadata": {
          "description": "The list of locations that can be specified when deploying resources",
          "strongType": "location",
          "displayName": "Allowed locations"
        }
      }
    },
    "displayName": "Allowed locations",
    "description": "This policy enables you to restrict the locations your organization can specify when deploying resources.",
    "policyRule": {
      "if": {
        "not": {
          "field": "location",
          "in": "[parameters('allowedLocations')]"
        }
      },
      "then": {
        "effect": "deny"
      }
    }
  }
}

1. Mode tells you the type of resources for which the policy will be applied. Allowed values are "All" (where all Resource Groups and Resources are evaluated) and "indexed" (where policy is evaluated only for resources which support tags and location)
2. Parameters are used for providing inputs to the policy. They can be reused at multiple locations within the policy. You can refer to a parameter as: "[parameters('allowedLocations')]"
3. Display Name is used to show the policy in the portal or programmatically.
4. A description is used to provide details for the policy.
5. Policy Rule is which defines the policies. This is the section where the restrictions are defined in a Poicy Definition. To understand a policy you need to focus most of your efforts on this section. Every Policy rule has two key sections defined under "if-then" blocks.
   1. Logical Evaluation is defined under the "if" block. It defines the condition which is evaluated to determine the policy should be applied or not.
   2. Effect is defined in the "then" block. This defines what will happen if the condition is met.

Policy Rules

Let's look at the policy rules in more details. The general syntax of the "if-then" block is as shown below:

{
  "if": {
    <condition> | <logical operator>
  },
  "then": {
    "effect": "deny | audit | append"
  }
}

Supported logical operators are:

• "not": {condition or operator}
• "allOf": [{condition or operator},{condition or operator}]
• "anyOf": [{condition or operator},{condition or operator}]

Not operator means that the opposit of the condition should be true for the policy to be applied. AllOf requires all the conditions defined to be true at the same time. AnyOf requires any one of the conditions to be true for the policy to be applied.

In the previous example, the policy rule section is as shown below:

    "policyRule": {
      "if": {
        "not": {
          "field": "location",
          "in": "[parameters('allowedLocations')]"
        }
      },
      "then": {
        "effect": "deny"
      }
    }

In simple terms, the rule above says that if the location is not in the list of allowed locations, defined by the parameter allowedLocations, then the effect will be deny i.e. the resource creation will not be allowed.

You can find the complete list of operators and conditional constructs here: Azure Policy definition structure