The impact of conflicting Azure Policies

This article is contributed. See the original author and article here.

Azure Policy lets you assess resources against certain criteria at different levels in your environment – from the top level management groups containing multiple subscriptions down to resource groups. So what happens if the policies at one level are different from the policies at another level in your environment hierarchy? Sonia explores some scenarios!

How Azure Policy assignments work

When you apply an Azure Policy at a certain level (known as assigning it to a scope), that assignment will be inherited by all the child resources under that scope. If I add a policy at the subscription level for example, all of the resources groups under that subscription will also be impacted by that policy. However, existing resources will not be modified by a Deny policy – they will be marked as non-compliant.

Azure Policy is an “explicit deny” system. This means that if any policy assignment in the hierarchy would deny a resource configuration, then it will be denied. To manage exceptions (say you want one resource group to be allowed resources of a larger size that aren’t allowed anywhere else in the subscription), you can exclude the resource group from the policy that is denying those resource sizes (known as SKUs), and you can assign a different allowed sizes policy to that resource group.

Scenarios with the Allowed virtual machine SKUs policy

My test environment started with the following:

Subscription level: No policy assignments

Resource group level: Allowed virtual machine SKUs set to standard_dc2s, standard_dc2s_v2, standard_dc4s, standard_dc4s_v2, standard_dc8_v2

VM in the resource group: Size Standard_DS1_v2

How can there be a VM in that resource group with a size that’s not listed in the allowed VM SKUs policy?

The policy is set to Deny, so that tells me that the policy was assigned to the resource group AFTER the VM had been created. Azure Policy is showing that there are some non-compliant resources in this resource group. Assigning a deny policy won’t modify existing resources, but it will show them as non-compliant. It will prevent existing resources from being resized to a SKU that’s not listed, and it will prevent new resources from being created with a SKU that’s not explicitly allowed.

So, what happens if I go and add an Azure Policy at the subscription level to allow the Standard_DS1_v2 SKU being used by that VM?

Once assigned and assessed, my VM is showing as compliant with the subscription-level policy but still non-compliant with the resource group level policy assignment.

Policy compliance and non-compliance at different assignment scopes

What happens if I now add a completely new resource group?

The new resource group will inherit the subscription level policy, which allows Standard_DS1_v2.

But if I then go and add an allow SKU policy at the resource group level, list Standard_D4s_v3 and try to create a new VM in that resource group with the D4s_v3 SKU – the creation of the VM will fail as it does not meet the more restrictive subscription-level policy.

Adding exclusions

If I really want to enable a resource group to allow a SKU that’s not listed in the subscription level policy assignment, I can add the resource group to the exclusions at that subscription level. Then I can set a more permissive list of SKUs when I assign the policy at the resource group level. This will allow the creation of new resources that match the SKUS listed at the resource group level.

Exclude a resource group from an Azure Policy assignment

If I have existing resources in a resource group that I want keep at that size, but I don’t want any new resources to be created (or existing resources to be resized) to that SKU, I can exempt single resources from a policy assignment, at any level. This will prevent the resource from being evaluated against that policy. Exclusions are also useful if the resource is in a temporary state of non-compliance, or the policy condition is mitigated by some other method (for example, another vendor’s security product).

Scenario with the Allowed locations

My test environment is configured with:

Subscription level: Allowed location Australia East

Resource group level: Allowed location East US 2

If I try to add a VM to the resource group and set its location to East US 2, the creation will fail due to that location not being listed in the subscription level’s policy assignment. Again, I’d need to add this resource group to the exclusion at the subscription level.

VM creation warning on location not meeting Azure Policy assignment

Triggering an Azure Policy compliance scan

Did you know that right in the Azure Portal you can trigger a compliance scan, using Cloud Shell (the first icon)?

Azure portal – CloudShell

There’s a PowerShell command for this, but it can take a little while to run on larger environments. So we don’t have to wait for it to finish before we get our CloudShell prompt back, we can run it as a job:

$job = Start-AzPolicyComplianceScan -AsJob

And to check the progress, we run $job

AZPolicyComplianceScan job status

Custom non-compliance messages

One of my favorite Azure Policy enhancements is the ability to add a custom message to be displayed when a resource change or creation is denied due to non-compliance against a policy assignment. You can use this to give more clarity to exactly which policy assignment is saying no (such as “Allowed SKUs in SVM-RG-09 are D series only”) or to direct people to who to contact for more information or an exemption (such as “Email SKUPolicyOwner@yourcompany.com for more info”)

Do you have any other scenarios?

These are just two little examples – do you have any other suggestions for scenarios where you may have a conflict with your Azure Policy assignments? Let us know if there’s anything you’d like to model through or discuss.