DenyAction effect for Azure Policy

Microsoft recently released in preview new effect for Azure policies which is called DenyAction. Which is really interesting and has great potential. Basically idea is that you can use Azure Policy to prevent certain actions to be performed on resources disregard of your permissions.

Sounds like resource lock?

Yes and no.

Resource lock is more difficult to manage, since you have to assign lock to all required resources individually, so assigning them is a huge pain (management overhead, speaking corporate).

Instead, with DenyAction, you can use standard Azure Policy selectors like resource types or even tags.

Let’s imagine that you create tag tag.action – DONOTDELETE and assign it to key vaults which you don’t want to be deleted accidentally at all. Tag is deployed as a part of IaC deployment pipeline.

Now, you just need to create policy with following definition which is going to prevent deletion of any key vault with this tag.

{
   "if": {
      "allOf": [
         {
            "field": "type",
            "equals": "Microsoft.keyvault/vaults"
         },
         {
            "field": "tags.action",
            "equals": "DONOTDELETE"
         }
      ]
   },
   "then": {
      "effect": "DenyAction",
      "details": {
         "actionNames": [ "delete" ],
         "cascadeBehaviors": { "resourceGroup": "deny" }
      }
   }
}

Now, you can deploy any number of key vaults with required tag and all of them will be protected by Azure policy.

Well, almost. There are few caveats.

If someone wants to delete subscription, you will not be able to stop it by having policy for underlying resource. That would work only for resource group level (noticed “cascadeBehavior”), but that would only work for indexed resources.

Other ways to do the same.

As i mentioned before, this feature sounds like more flexible Resource Lock, so you can achieve almost the same with resource lock, which is required to be managed for every single resource.

However, if you want to prevent people from doing specific actions in your environment, you might consider working on fine tuning Custom Azure roles with specific NotActions in role definitions. Problem here is that it is freaking hard to create custom role with just enough permissions for big teams and even harder to maintain it (you will have to update role every time new product needs to be used or Microsoft changes something). But overall, Custom Role can help you in more use cases.

Should you start using DenyAction?

I would say that it would not do any harm to try, just don’t forget that feature is in Preview state and there are possible issues.

Also, i personally, hope that list of “effects” will not stop on resource deletion block.

Just in case, link to Microsoft docs – https://learn.microsoft.com/en-us/azure/governance/policy/concepts/effects#denyaction-preview