It's exciting to build a ton of workloads in Azure but oftentimes management and control of such an environment get challenging. Negligence to actively monitor the resources results in an unmanageable environment in the cloud which usually takes hours to streamline the workloads in the testing development and production stage.

Azure Policy helps to enforce organizational standards and assess the compliance at-scale in real-time. It provides single-dashboard management for compliance and remediation for non-compliant resources with a single click. For example, you can define the deployment region and be sure that nobody is able to deploy any outside the allowed region.

Table of contents

1. Overview
2. Policy Types
   • Policy Definitions
   • Initiative Definitions
   • Assignments
3. Permissions
4. Policy Evaluation
5. Policy Evaluation Response
6. Remediating Non-Compliant Resource
7. Recommendation for Managing Policies
8. Maximum Count of Azure Policy Objects
9. Conclusion

Overview

Azure Policies evaluate the resources in Azure by comparing the properties of those resources against business rules (definitions) defined in JSON format. You can deploy a lot of individual policies however, policy initiative simplifies the management by grouping together a lot of definitions.

Once you define your policy definitions, they are then applied to resources using various scopes including management groups, subscriptions, resource groups, or individual resources. Policy definition applies to all the resources within the defined scope.

Policy Types

Policy Definitions

Each policy definition is a JSON object. The policy's core component is its condition which defines the effect and enforcement type on any resource that's targeted by the policy. There are quite a handful of Built-In policies that you should use. Find the list of Built-In below:

[List of built-in policy definitions - Azure Policy(https://docs.microsoft.com/en-us/azure/governance/policy/samples/built-in-policies)

Each policy definition has the following elements that define the structure of the policy.

• Mode – This determines which resource type will be evaluated for a policy. Supported modes are: –
  • all: evaluated resource groups and all resource types
  • indexed: evaluate resource types that support tags and location
• Parameters – If you are familiar with any programming language you will be familiar with parameters. These parameters can be used in the logical evaluation and in the effects. <!--kg-card-end: markdown-->

For example, below is a policy that restricts the deployment region for resources.

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

Initiative Definitions

An Initiative is a collection of policy definitions that are tailored towards a single objective. Initiative simplifies the management and evaluation of multiple policies.

Azure PowerShell and Azure CLI use properties and parameters names PolicySet to refer to initiatives.

If you wish to create a custom policy definition to use as an initiative, follow the steps on the Microsoft Docs site.

Tutorial: Build policies to enforce compliance - Azure Policy

Assignments

An assignment is a policy definition or an initiative that has been assigned to a specific scope. Assignments are inherited by the child resource when applied to top-level items such as management group and subscription.

Azure Policy is an explicit deny system. If a top-level policy on a management group or subscription is set to deny any action, you won't be able to allow it specifically using policy at a resource level(child level).

You can use any Built-in policy to create a policy assignment. Before running the assignment command, get the Policy Id for your policy using the Get-AzPolicyDefinition command as shown below:

#use PowerShell to get Policy
$Policy = Get-AzPolicyDefinition -Builtin | where {$_.Properties.DisplayName -like "PolicyName"}

#Output
Name : 0473574d-2d43-4217-aefe-941fcdf7e684
ResourceId : /providers/Microsoft.Authorization/policyDefinitions/0473574d-2d43-4217-aefe-941fcdf7e684
ResourceName : 0473574d-2d43-4217-aefe-941fcdf7e684
ResourceType : Microsoft.Authorization/policyDefinitions
SubscriptionId :
PolicyDefinitionId : /providers/Microsoft.Authorization/policyDefinitions/0473574d-2d43-4217-aefe-941fcdf7e684

Use the $Policy variable as policy reference and run the command New-AzPolicyAssignment to create policy based on Built-In definitions. Scope should be in format /subscriptions/subscriptionId

$Assignment = New-AzPolicyAssignment -Name '<name>' -Scope '<scope>' -PolicyDefinitions $Policy

Permissions

Azure Policy has several permissions, known as operations, in two Resource Providers:

• Microsoft.Authorization
• Microsoft.PolicyInsight

Make sure you have "Owner" permission on subscription to create definitions or assignments. "Contributor" role user can only trigger the resource remediation.

Make sure you enable Azure Policy Resource Provider for your subscriptions before deploying any policies using the command below:

Register-AzResourceProvider -ProviderNamespace 'Microsoft.PolicyInsights'

Policy Evaluation

Azure Policy evaluates the in-scope resources during the following times or events

• A resource is created, updated, or deleted in a scope with a policy assignment
• A policy or initiative is newly assigned to a scope
• A policy or initiative already assigned to a scope is updated
• During the standard compliance evaluation cycle, which occurs once every 24 hours.

Policy Evaluation Response

Policy definition action varies for every organization. Azure Policy uses effect as a trigger to respond to certain policy's non-compliant state. Effects are set in the policy rule within the policy definition. For example, you can limit the deployment to specific virtual machine types and sizes, or block different Azure regions from being used. You can still give developers access to the Azure environment and subscriptions but always stay in control. Below are some of the action you can perform on resources once evaluated to be non-compliant by policy definition:

• Deny the resource change
• Log the change to the resource
• Alter the resource before the change
• Alter the resource after the change
• Deploy related complaint resources

Learn more about Policy Effect here:

Understand how effects work - Azure Policy

Remediating Non-Compliant Resource

While the policy effect primarily affects the resource during the creation or any update, Azure Policy also supports dealing with existing non-compliant resources without needing to alter the resources.

When Azure Policy runs in deployIfNotExists policy effect, it does the deployment using a managed identity. Azure Policy creates a managed identity for each assignment when needed. While deploying the policy assignment using Azure Portal, the setup creates the managed identity with the necessary permission automatically for you.

Recommendation for Managing Policies

• It's always good to start with an audit effect instead of a deny effect to track the impact of your policy definition on the resources in your environment. This ensures you get enough data to collect and make decisions on enforcing policies based on business needs.
• Consider organizational hierarchies when creating definitions and assignments. It is recommended to create definitions at higher levels such as the management group or subscription level. Then, create the assignment at the next child level.
• While you can create individual policies for each task, it's more effective to use initiative definitions even for a single policy definition.

Maximum Count of Azure Policy Objects

There's a limit on how many policies you can deploy in a certain scope, either subscription or management group. Use the following chart as a reference.

Conclusion

I hope this provides you a high-level overview of Azure Policies in Azure for managing and restricting the Azure environment.