There are many scenarios in which users encountered some policy unexpected behaviors because they do not understand policy workflow and designed the incorrect custom policy definition.
This blog will introduce the following three parts in detail.
When the policy will be triggered and evaluate the target resources
There are multiple scenarios that the policy can be triggered and the documentation concludes all the scenarios. The following content illustrates part of scenarios and mainly introduces that the policy will evaluate the resources in two distinct but interrelated parts.
The essence of checking request payload
The Azure policy will check the request payload and compare it with the policy definition and then decide the next action. The following part will explain how the policy with different effects evaluates resources by the simplified workflow sample.
Resource Types and Segments in policy definition
For the Azure Policy with most effects (except the AINE and DINE), the policyRule part only can check the properties that returned from the same request payload. But for the AINE /DINE policies, since the policy can send another separate request when it checks the existenceCondition part, these kinds of policies can check the resource with different resource types or hierarchies.
If users put the properties belonging to different requests’ payload inside the “if” part together, the policy may not be able to scan any target resources and may also show other unexpected behaviors. The following example will help to explain in detail.
If users want to check whether a function app is configured the TLS with version 1.2, according to the function application exported template, we understand that the following 3 conditions need to be checked.
But these three conditions cannot be checked inside the policy rule part together, since the “functionapp” kind is included in the following request payload.
Web Apps - Get - REST API (Azure App Service) | Microsoft Docs
But the “Microsoft.Web/sites/config/web.minTlsVersion” is included in the following request payload.
Web Apps - Get Configuration - REST API (Azure App Service) | Microsoft Docs
Since the existenceCondition used for the DeployIfNotExist/AuditIfNotExist effect can send another GET request and get the payload to further check, then the above 3 conditions can be checked in the same policy definition. Users can set the minTlsVersion condition in the existenceCondition part in the DeployIfNotExist/AuditIfNotExist effect policy as following policy definition.
azure-policy/AppService_FunctionApp_Audit_Tls_Ver.json at f2706e05bccaac0a7410f8613107a6ee3bd88afd ·...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.