Edit

Azure Policy exemption structure

  • Article
  • 5 minutes to read

The Azure Policy exemptions feature is used to exempt a resource hierarchy or an individual resource from evaluation of initiatives or definitions. Resources that are exempt count toward overall compliance, but can't be evaluated or have a temporary waiver. For more information, see Understand scope in Azure Policy. Azure Policy exemptions only work with Resource Manager modes and don't work with Resource Provider modes.

Note

By design, Azure Policy exempts all resources under the Microsoft.Resources resource provider (RP) from policy evaluation with the exception of subscriptions and resource groups, which can be evaluated.

You use JavaScript Object Notation (JSON) to create a policy exemption. The policy exemption contains elements for:

Note

A policy exemption is created as a child object on the resource hierarchy or the individual resource granted the exemption, so the target isn't included in the exemption definition. If the parent resource to which the exemption applies is removed, then the exemption is removed as well.

For example, the following JSON shows a policy exemption in the waiver category of a resource to an initiative assignment named resourceShouldBeCompliantInit. The resource is exempt from only two of the policy definitions in the initiative, the customOrgPolicy custom policy definition (reference requiredTags) and the Allowed locations built-in policy definition (ID: e56962a6-4747-49cd-b67b-bf8b01975c4c, reference allowedLocations):

{
    "id": "/subscriptions/{subId}/resourceGroups/ExemptRG/providers/Microsoft.Authorization/policyExemptions/resourceIsNotApplicable",
    "apiVersion": "2020-07-01-preview",
    "name": "resourceIsNotApplicable",
    "type": "Microsoft.Authorization/policyExemptions",
    "properties": {
        "displayName": "This resource is scheduled for deletion",
        "description": "This resources is planned to be deleted by end of quarter and has been granted a waiver to the policy.",
        "metadata": {
            "requestedBy": "Storage team",
            "approvedBy": "IA",
            "approvedOn": "2020-07-26T08:02:32.0000000Z",
            "ticketRef": "4baf214c-8d54-4646-be3f-eb6ec7b9bc4f"
        },
        "policyAssignmentId": "/subscriptions/{mySubscriptionID}/providers/Microsoft.Authorization/policyAssignments/resourceShouldBeCompliantInit",
        "policyDefinitionReferenceIds": [
            "requiredTags",
            "allowedLocations"
        ],
        "exemptionCategory": "waiver",
        "expiresOn": "2020-12-31T23:59:00.0000000Z",
        "assignmentScopeValidation": "Default"
    }
}

Snippet of the related initiative with the matching policyDefinitionReferenceIds used by the policy exemption:

"policyDefinitions": [
    {
        "policyDefinitionId": "/subscriptions/{mySubscriptionID}/providers/Microsoft.Authorization/policyDefinitions/customOrgPolicy",
        "policyDefinitionReferenceId": "requiredTags",
        "parameters": {
            "reqTags": {
                "value": "[parameters('init_reqTags')]"
            }
        }
    },
    {
        "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4c",
        "policyDefinitionReferenceId": "allowedLocations",
        "parameters": {
            "listOfAllowedLocations": {
                "value": "[parameters('init_listOfAllowedLocations')]"
            }
        }
    }
]

Display name and description

You use displayName and description to identify the policy exemption and provide context for its use with the specific resource. displayName has a maximum length of 128 characters and description a maximum length of 512 characters.

Metadata

The metadata property allows creating any child property needed for storing relevant information. In the example above, properties requestedBy, approvedBy, approvedOn, and ticketRef contains customer values to provide information on who requested the exemption, who approved it and when, and an internal tracking ticket for the request. These metadata properties are examples, but they aren't required and metadata isn't limited to these child properties.

Policy assignment ID

This field must be the full path name of either a policy assignment or an initiative assignment. policyAssignmentId is a string and not an array. This property defines which assignment the parent resource hierarchy or individual resource is exempt from.

Policy definition IDs

If the policyAssignmentId is for an initiative assignment, the policyDefinitionReferenceIds property may be used to specify which policy definition(s) in the initiative the subject resource has an exemption to. As the resource may be exempted from one or more included policy definitions, this property is an array. The values must match the values in the initiative definition in the policyDefinitions.policyDefinitionReferenceId fields.

Exemption category

Two exemption categories exist and are used to group exemptions:

  • Mitigated: The exemption is granted because the policy intent is met through another method.
  • Waiver: The exemption is granted because the non-compliance state of the resource is temporarily accepted. Another reason to use this category is for a resource or resource hierarchy that should be excluded from one or more definitions in an initiative, but shouldn't be excluded from the entire initiative.

Expiration

To set when a resource hierarchy or an individual resource is no longer exempt from an assignment, set the expiresOn property. This optional property must be in the Universal ISO 8601 DateTime format yyyy-MM-ddTHH:mm:ss.fffffffZ.

Note

The policy exemptions isn't deleted when the expiresOn date is reached. The object is preserved for record-keeping, but the exemption is no longer honored.

Resource selectors (preview)

Exemptions support an optional property resourceSelectors. This property works the same way in exemptions as it does in assignments, allowing for gradual rollout or rollback of an exemption to certain subsets of resources in a controlled manner based on resource type, resource location, or whether the resource has a location. More details about how to use resource selectors can be found in the assignment structure. Below is an example exemption JSON which leverages resource selectors. In this example, only resources in westcentralus will be exempt from the policy assignment:

{
    "properties": {
        "policyAssignmentId": "/subscriptions/{subId}/providers/Microsoft.Authorization/policyAssignments/CostManagement",
        "policyDefinitionReferenceIds": [
            "limitSku", "limitType"
        ],
        "exemptionCategory": "Waiver",
        "resourceSelectors": [
            {
                "name": "TemporaryMitigation",
                "selectors": [
                    {
                        "kind": "resourceLocation",
                        "in": [ "westcentralus" ]
                    }
                ]
            }
        ]
    },
    "systemData": { ... },
    "id": "/subscriptions/{subId}/resourceGroups/demoCluster/providers/Microsoft.Authorization/policyExemptions/DemoExpensiveVM",
    "type": "Microsoft.Authorization/policyExemptions",
    "name": "DemoExpensiveVM"
}

Regions can be added or removed from the resourceLocation list in the example above. Resource selectors allow for greater flexibility of where and how exemptions can be created and managed.

Assignment scope validation (preview)

In most scenarios, the exemption scope is validated to ensure it is at or under the policy assignment scope. The optional assignmentScopeValidation property can allow an exemption to bypass this validation and be created outside of the assignment scope. This is intended for situations where a subscription needs to be moved from one management group (MG) to another, but the move would be blocked by policy due to properties of resources within the subscription. In this scenario, an exemption could be created for the subscription in its current MG to exempt its resources from a policy assignment on the destination MG. That way, when the subscription is moved into the destination MG, the operation is not blocked because resources are already exempt from the policy assignment in question. The use of this property is illustrated below:

{
    "properties": {
        "policyAssignmentId": "/providers/Microsoft.Management/managementGroups/{mgB}/providers/Microsoft.Authorization/policyAssignments/CostManagement",
        "policyDefinitionReferenceIds": [
            "limitSku", "limitType"
        ],
        "exemptionCategory": "Waiver",
        "assignmentScopeValidation": "DoNotValidate",
    },
    "systemData": { ... },
    "id": "/subscriptions/{subIdA}/providers/Microsoft.Authorization/policyExemptions/DemoExpensiveVM",
    "type": "Microsoft.Authorization/policyExemptions",
    "name": "DemoExpensiveVM"
}

Allowed values for assignmentScopeValidation are Defaultand DoNotValidate. If not specified, the default validation process will occur.

Required permissions

The Azure RBAC permissions needed to manage Policy exemption objects are in the Microsoft.Authorization/policyExemptions operation group. The built-in roles Resource Policy Contributor and Security Admin both have the read and write permissions and Policy Insights Data Writer (Preview) has the read permission.

Exemptions have extra security measures because of the impact of granting an exemption. Beyond requiring the Microsoft.Authorization/policyExemptions/write operation on the resource hierarchy or individual resource, the creator of an exemption must have the exempt/Action verb on the target assignment.

Next steps