Quickstart: DenyAction Effect in Azure Policy

Background

Azure policy introduced a new policy effect named 'DenyAction' recently, which enables the user to block requests on intended action to resources in case the critical resources are changed. This article introduces the 'DenyAction' effect and the expected behaviors with a demo.

Please note that the DenyAction effect is now in public preview.

We will cover two sections in this article:

1. Policy definition.
2. The expected behavior of the effect.

Policy Definition

The DenyAction effect is designed to block the operation of intended action to modify specific resources. Currently, only the DELETE action is supported. When a request is made to delete a resource, which is in the scope of a DenyAction Policy assignment, the request will be blocked. To introduce more details about this effect, let's start by creating a policy definition as an example.

Suppose we are creating a DenyAction policy to protect resources from accidental deletion with the following business requirement:

1. The resource type to be protected is virtual machine.
2. Only the resources with "environment: prod" tags are not allowed for deletion.
3. Both virtual machine and its resource group should be protected from deletion.

To meet the requirement above, we can write policy rules as shown below and assign the policy to the specific scope:

Hints:

The section of cascadeBehaviors is optional. This is to define what behaviour will be followed when the resource is implicitly deleted by the removal of a resource group. Only the indexed resources are supported for this section. Once the section is added, the policy mode should be set to 'Indexed' as well.

An index resource refers to the resource that supports tags and locations. For more details about the index resource, please refers to the document: https://learn.microsoft.com/en-us/azure/governance/policy/concepts/definition-structure#resource-manager-modes. 

In this case, we will set the cascadeBehaviors as 'deny' because we do not want to remove the protected VM resources when deleting the resource group where they reside. Therefore, the policy will follow the 'deny' behaviour when proceeding with the resource group deletion request.

Expected Behavior

Now that the custom policy with the DenyAction effect has been assigned and taking effect, let’s explore some scenarios of entity deletion and the expected behaviors.

Scenario 1. Resource Deletion

If the VM resource is deleted directly, it would fail with 403(Forbidden) and the following notification can be found in the activity log.

Scenario 2 Resource Group Deletion

If a user tries to delete the resource group that contains the VM resource, the request will fail. This is because I set the cascadeBehaviors is set to 'deny' in the above policy. Therefore, the policy would deny the request of resource group deletion. As a result, nothing will be deleted. The message below can be found in the activity log:

However, if the cascadeBehaviors is set as 'allow', the policy will follow the 'allow' action when the resource is being implicitly deleted by the removal of a resource group. Which means, the resource group and all the resources within the same resource group will be deleted.

Scenario 3. Subscription Deletion

The policy won't block removal of resources that happens during a subscription deletion.

Scenario 4. Child resource Deletion

Child resource are the resource that exist only within the context of another resource. In this demo, a virtual machines extension resource is a child of the virtual machine, whom is the parent resource.

The policy is assigned to protect the VM resource '5plus1TestVM01' only (parent resource).  If the entity being deleted is 'AzurePolicyforWindows'(child resource), then the child resource will be deleted, and the parent resource remains.

Please read the document below if you want to learn more about the DenyAction effect: https://learn.microsoft.com/en-us/azure/governance/policy/concepts/effects#denyaction-preview