TL;DR

The new DenyAction effect in Azure Policy provides a robust mechanism to prevent accidental deletion of critical resources and enforce compliance. It offers a more granular control compared to resource locks, allowing specific actions to be blocked. This blog post explores the use of DenyAction effect and provides an example of its implementation.

Introduction

Azure Policy’s effectiveness largely depends on the type of effect applied. The newly introduced DenyAction effect fills a significant gap, enabling policy enforcement by blocking specific actions on resources. Previously, preventing the deletion of critical resources like a resource group required creating a resource lock. However, an owner could remove the lock and delete the resource group, potentially impacting critical infrastructure. The DenyAction effect mitigates this risk. By applying policies at the subscription level, it’s possible to prevent deletion of any resource groups or resources within that subscription, safeguarding your infrastructure. The DenyAction only supports delete actions.

Example

Here’s an example of a DenyAction applied to virtual networks tagged as environment=prod.

The policy rule:

"policyRule": {
    "if": {
        "allOf": [
            {
                "field": "type",
                "equals": "Microsoft.Network/virtualNetworks"
            },
            {
                "field": "tags.environment",
                "equals": "prod"
            }
        ]
    },
    "then": {
        "effect": "denyAction",
        "details": {
            "actionNames": [
                "delete"
            ],
            "cascadeBehaviors": {
                "resourceGroup": "deny"
            }
        }
    }
}

Resources that are deployed:

• Resource group
• Virtual network

The policy definition is assigned on the resource group.

When you attempt to delete a resource with a DenyAction policy, you’ll receive a denial message, and the policy will enter a Protected state in the compliance view.

The cascadeBehaviors parameter set to deny restricts any user from deleting the virtual network. Even an attempt to delete the resource group will be blocked. Changing cascadeBehaviors to allow permits the deletion of the resource group and the virtual network within it.

Use Cases

Some use cases for the deny action effect

• Preventing Accidental Deletion of Critical Resources: Use the DenyAction effect to block the DELETE action on critical resources. For instance, a DenyAction policy can protect a virtual network from accidental deletion, especially useful for resources tagged as environment=prod.
• Protecting Resource Groups: Protect entire resource groups from deletion by setting the cascadeBehaviors to deny. This policy denies the deletion of the resource group and all its resources.
• Enforcing Compliance: Enforce compliance by using the DenyAction effect to block actions violating policy rules. For example, if a policy rule requires all resources to have a specific tag, use the DenyAction effect to block the creation or update of any resource lacking this tag.

Resource Locks vs Deny Action

Azure Resource Locks and the DenyAction effect in Azure Policy both serve to prevent accidental modifications or deletions of resources. However, they differ in their scope and granularity.

Azure Resource Locks can be applied at various levels: subscription, resource group, or individual resource. There are two types of locks: CanNotDelete and ReadOnly. The CanNotDelete lock permits authorized users to read and modify a resource, but not delete it. The ReadOnly lock allows users to read a resource, but neither delete nor update it.

On the other hand, the DenyAction effect offers more granular control. It can block specific actions on resources, providing a more nuanced approach to resource management.

While both DenyAction and Resource Locks can prevent deletions, they serve different purposes. DenyAction is ideal for blocking specific actions, whereas Resource Locks apply more broadly to all actions (either all deletions or all modifications).

The choice between DenyAction and Resource Locks depends on your specific use case and the level of control required.

Further reading

• Azure Policy: Azure Policy documentation | Microsoft Learn
• Policy Effects: Understand how effects work – Azure Policy | Microsoft Learn

Summary

The DenyAction effect in Azure Policy is a powerful tool for safeguarding critical resources and enforcing compliance. It provides granular control over resource actions, offering a more nuanced approach compared to resource locks. By understanding its usage and implementation, you can significantly enhance the security and management of your Azure resources.