Getting Started - Azure Policy

In today world cloud adoption getting bigger and bigger every day, amount of used services and resources is really huge. Simple static website can use up to 10 different services in single region it can be services like: compute, database, vault, identity, storage, content delivery network, load balancing, serverless, message bus. It is a lot of them.

We need to start monitor them and standardise resource naming or track consumption by various company division.

Azure Policy to the rescue

Azure Policy is a service with allow us to create various policies or use already build in into Azure cloud.

The build in policies can be various type from simple like requirement of resource tagging or more complicated like some compliance policy required by law. Simply policies are a business rules which can be grouped in next concept initiatives. Initiatives are concept which simplify management of large set of policies.

Resources are evaluated on daily basis or when any modification of policy occurs, after that time configured effect are reported into Management window.

Policies can be also proactive and contains some remediation actions but we can have also exemptions as well to remove some resources from validation rules.

Finally policies and initiatives needs to be assign on some levels of Azure resources management. It can be Management Group level, Subscription level or event specific Resource Group level using Inclusion and Exclusion.

Policy construction

Lets start with a small example of policy which audit resource group naming conventions

{
  "mode": "All",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "not": {
            "field": "name",
            "like": "rg-*"
          }
        },
        {
          "field": "type",
          "equals": "Microsoft.Resources/subscriptions/resourcegroups"
        }
      ]
    },
    "then": {
      "effect": "audit"
    }
  },
  "parameters": {}
}

What we have here?

Each policy contains few key elements:

  • policyRule
  • logical evalutation
  • effect

Rest of elements are some metadata and parameters which can be used as arguments in definition. I think the policy shown above needs no description.

Another example of policy deny resources creation in another location than specified by policy owner.

{
  "mode": "All",
  "policyRule": {
    "if": {
      "not": {
        "field": "location",
        "in": "[parameters('allowedLocations')]"
      }
    },
    "then": {
      "effect": "deny"
    }
  },
  "parameters": {
    "allowedLocations": {
      "type": "Array",
      "metadata": {
        "displayName": "Allowed locations",
        "description": "The list of allowed locations for resources.",
        "strongType": "location"
      }
    }
  }
}

In this example I use parameters as input to policy and I evaluate values in policy rule. Finally this policy deny creation of resources as effect.

Summary

This is only a quick introduction to Azure Policy service but the policy and initiative mechanism is a powerful tool in the arsenal of cloud resource managers. In next blog post I go deeper into topic of initiatives and remediation of policies.