Bypassing policies in Azure

Azure policies allow your Azure infrastructure to stay compliant by auditing and enforcing rules over the resources those policies are evaluated against.

In some instances, however, we need to be able to bypass a particular policy or initiative. One way of doing this is by using bypass tags.

Bypass tags can be defined in custom policies so that if a particular tag is included in a resource, the policy is ignored. This approach has two main shortcomings:

1. It only applies to custom policies; if a built-in policy wants to be bypassed, a new custom policy that also includes the corresponding tag needs to be defined;

2. auditing of bypass tags requires further configuration since it is not integrated into the Azure portal out of the box.
   

{
    "if": {
        "allOf": [
            {
                "not": {
                    "field": "location",
                    "in": "[parameters('allowedLocations')]"
                }
            },
            {
                "field": "tags['bypassLocationPolicy']",
                "exists": false
            }
        ]
    },
    "then": {
        "effect": "deny"
    }
}

However, there’s a better way of bypassing policies: Azure policy exemptions.

What is a policy exemption?

Policy exemptions allow bypassing policies in a particular scope so that the policies are not evaluated for the resources under this scope.

As opposed to bypass tags, Azure automatically audits policy exemptions, so that they can be easily monitored as shown in the picture below.

Another advantage is that policy exemptions can be applied to any policy including build-in policies, without the need of defining additional policies.

One of the issues with policy exemptions, as opposed to bypass tags, is that it is involved to exempt individual resources from policies with deny effect. The reason for that is that in order to be able to apply a policy exemption, the exemption scope, the resource itself in this case, needs to exist. One way of achieving this result is by assigning the exemption to a broader scope, for example, a resource group, create the resource, then assign the exemption to the individual resource and remove it from the broader scope.

Limiting the scope of exemptions

As mentioned above, policy exemptions are applied to a particular scope. This, in principle, would allow disabling exemptions for entire management groups or subscriptions, which may defeat the purpose of applying policies in the first place.

However, there’s one way we can limit the scope to which exemptions can be applied: through a custom policy!

The idea of this custom policy would be to block the creation of policy exemptions with particular scopes. There’s one minor issue, however, the policy exemption scope doesn’t exist as an alias, and therefore, it cannot be used as a filter in the policy definition. The solution to this is to use the policy exemption ID, which happens to embed the scope. In our case, we wanted to block policy exemptions with scopes broader than the resource group level, so our policy definition looks as follows.

{
    "if": {
        "allOf": [
            {
                "field": "type",
                "equals": "Microsoft.Authorization/policyExemptions"
            },
            {
                "field": "id",
                "notContains": "resourceGroup"
            }
        ]
    },
    "then": {
        "effect": "deny"
    }
}

Follow up

At the time of writing this post, policy exemptions are still a preview feature in Azure and therefore you may face some limitations when using them. Nevertheless, I invite you to try them out if you need to work in highly regulated environments (they have proven quite handy to us!). Please, find below some links that will help you get started!

• Azure policies overview.
• Azure policy exemption structure.
• Tutorial on how to create and manage policies in Azure.