Implementing Azure Policy – Compliance and Cloud Governance

Implementing an Azure policy comprises three main parts. We will start with the policy definition, policy assignment and scoping, and policy evaluation.

Policy Definition

There are many built-in policies, and users can write custom policies. You can see built-in policies by navigating to Azure Portal ➢ Policy ➢ Definitions. You need to add a filter to see the built-in policies, as shown in Figure 2.10.

FIGURE 2.10 Listing built-in policy definitions

The definition is a JSON manifest that describes what action will be taken by the policy if it’s assigned. The policy contains the condition and effect. The condition is what you evaluate to verify whether the effect needs to be applied or not. If the condition matches the declaration you made, the effect action will be taken. The following is a sample policy definition:

{

  “properties”: {
    “displayName”: “Allowed locations”,
    “policyType”: “BuiltIn”,
    “mode”: “Indexed”,
    “description”: “This policy enables you to restrict the locations your organization can specify when deploying resources. Use to enforce your geo-compliance requirements. Excludes resource groups, Microsoft.AzureActiveDirectory/b2cDirectories, and resources that use the ‘global’ region.”,
    “metadata”: {
      “version”: “1.0.0”,
      “category”: “General”
    },
    “parameters”: {
      “listOfAllowedLocations”: {
        “type”: “Array”,
        “metadata”: {
          “description”: “The list of locations that can be specified when deploying resources.”,
          “strongType”: “location”,
          “displayName”: “Allowed locations”
        }
      }
    },
    “policyRule”: {
      “if”: {
        “allOf”: [
          {
            “field”: “location”,
            “notIn”: “[parameters(‘listOfAllowedLocations’)]”
          },
          {
            “field”: “location”,
            “notEquals”: “global”
          },
          {
            “field”: “type”,
            “notEquals”: “Microsoft.AzureActiveDirectory/b2cDirectories”
          }
        ]
      },
      “then”: {
        “effect”: “deny”
      }
    }
  },
  “id”: “/providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4c”,
  “type”: “Microsoft.Authorization/policyDefinitions”,
  “name”: “e56962a6-4747-49cd-b67b-bf8b01975c4c”
}

This policy is used to restrict the locations where your organization users can deploy resources. In the condition we have mentioned that if the location selected is not part of the list of allowed locations or global, then the effect action should be taken. You can see the effect as “deny,” which means if the selected location is not part of the list of allowed locations, then the deployment will be denied. Having these built-in policies helps the administrators to apply these policies without the need to invest time in writing new policies.

These are examples of policy definitions:

• Allowed Locations specifies the locations allowed for deployments and restricts deployment to other regions.
• Allowed Locations for Resource Groups specifies the locations allowed for resource groups.
• Allowed Virtual Machines SKUs allows you to select a set of VM SKUs that your organization users can deploy.

Now that we found the policy that we need to apply, we will discuss policy scope.