Azure Resource Manager (ARM) policies are a powerful governance capability that allows administrators to accomplish many things, such as:
- Define a ‘service catalog’ (which services may be created)
- Control the Azure regions in which resources may be deployed
- Enforce the use of ARM tags on resources
The use cases for ARM policies is limited only (well, almost only) by your imagination. However I had a question about the possibility of overriding policies. You see, an ARM policy defined at the subscription scope will be ‘inherited’ by all resource groups and resources within the subscription. Could someone with the ‘Owner’ role on a resource group remove the policy association from their resource group? Or could they put in place a policy on their resource group that overrode something defined by the policy at the subscription scope? Let’s try it and find out.
On my subscription I define and associate a policy that limits the resource providers which can be created to compute, network, storage, and resources (for resource groups). My ServiceCatalog.json file looks like this:
Now we switch the context to the resource group owner. This user has the ‘owner’ role on a resource group called ‘MyRG’. Here is how the application of the subscription-scoped policy looks from this user’s perspective:
You can see that the policy applies to the scope of the user’s resource group. SO can they un-associate it? It certainly appears so:
However, the association is not truly removed…subsequent runs of ‘Get-AzureRmPolicyAssignment with a scope of MyRG shows it is still in place. This answers the question of whether a resource group owner can remove a policy ‘inherited’ from the subscription. What about overwriting a setting put in place by the subscription-scoped policy? Let’s try that too.
While signed on as the resource group owner within PowerShell, I attempt to define and associate another policy called ServiceCatalogUpdate. You can see below that this JSON file adds another resource provider:
Notice what happens when this user tries to define the policy (a prerequisite to applying it):
The error calls out that the user is trying to ‘write over scope’ of the subscription policy. So even though the user has the ‘Owner’ role on the resource group, they cannot overwrite a policy defined at the subscription level.
One more question seems appropriate. What if the resource group administrator is attempting to define and assign a policy which does not override any settings from a subscription-scoped policy? Here is another policy definition JSON file that requires tags on resources. This policy should not contradict anything in the subscription-scoped policy:
Here are the results when the resource group owner tries to define and apply this policy:
The results are the same. So it appears that a resource group owner cannot apply an ARM policy on their resource group if a policy is defined at the subscription level. The takeaway seems to be, when designing solutions using ARM policies, apply your policies at the lowest level possible to achieve your goals.
For more information on Azure Resource Manager policies, visit the Azure documentation page for this powerful feature: https://azure.microsoft.com/en-us/documentation/articles/resource-manager-policy/