Azure policies are a great way to provide governance for your Azure subscription to ensure that you are compliant to the standards that you have set up for your organisation. The reason why I titled the post as "Think before using deny in your azure policy" is that it is very important understand the evaluation process Azure policies uses. The order of the evaluation is as following; (Extract from Microsoft)
- Disabled is checked first to determine if the policy rule should be evaluated.
- Append and Modify are then evaluated. Since either could alter the request, a change made may prevent an audit or deny effect from triggering.
- Deny is then evaluated. By evaluating deny before audit, double logging of an undesired resource is prevented.
- Audit is then evaluated before the request going to the Resource Provider.
You can see that "Deny" is above "Audit" so if you was retrospectively apply policies on your subscription then you will need to ensure you are in compliant before using Deny.
Example,
You have deployed a IaaS virtual machine and you have a policy in place which restricts where you can deploy a resource i.e. only allowed to deploy to UK South and North Europe and for any other location you set them to deny. If you try to deploy a "new" resource then the policy will kick in and deny you from deploying. Any existing deployed resources will just report as non-compliant to the policy as it will not explicitly deny any deployed resource before the policy was applied otherwise it will break a lot of workload deployed.
The problem arises when you wish to make a change to an existing resource that was deployed before you enforced your policy. For example, you had already deployed a VM in West Europe region so based on the policy above this would be non-compliant but the policy will not stop the resource from running. If you was to stop, start or restart the VM then policy will not kick in as we are just changing the state of the VM and not changing (updating) any settings. If we now attempt to change the VM size then the policy will be triggered as we are making a change/updating to the resource.
As you can see the "deny" policy could end up preventing you from making changes to your existing resources so remember to put your policy in audit mode first to ensure that all your resources are compliant before starting using "deny". You never know it could be the policies that stops your scripts, continuous deployment from working overnight !!!.
Reference:
