Background information:
Sometimes we found unexpected results of resource compliance status for some policies. To troubleshoot these kinds of problems, we first need to understand how Azure Policy evaluates resource.
Internally, there are two types of Policy evaluation(actions):
- The first kind can be referred as Policy enforcement, is triggered synchronously, while the user is sending a PUT or PATCH request (create or update a resource). Policy engine will examine the request body/payload for evaluation and take action (append, modify, deny etc.) accordingly.
- The other kind can be referred to as policy scan or compliance scan, is executed asynchronously by Azure Policy engine, based on a GET request to the ARM cache or resource provider and evaluates the existing resource based on the response payloads. Therefore, we can get the payload of resource GET calls and examine the payload with the policy rule to understand evaluation results.
And in this article, we will be discussing more about the troubleshooting steps for second type (compliance scan).
Problem scenario
A custom policy enforces Disk encryption marks virtual machine OS disk with encryption enabled as non-compliant.
Troubleshooting steps
- First step is, to check the “Compliance details” for clues for why the resource is being “non-compliant” from the Policy compliance page on the Azure portal as shown below:
- Get the target Policy definition from Policy page on Azure Portal.
"policyRule": {
"if": {
"allOf": [{
"field": "type",
"equals": "Microsoft.Compute/disks"
}, {
"field": "Microsoft.Compute/disks/encryptionSettings.enabled",
"notequals": "true"
}
]
},
"then": {
"effect": "audit"
}
- Run a REST API List/Get call and get the target resource payloads.
a. To find the right REST API, run a search with keyword as "Azure REST API list/get <resource type>"
b. Run the REST API using "Try It" feature shown as below:
c. the payload of the resource will be in the response body of the REST API call shown as below:
- Examine the resource payload with the policy definition.
In this scenario, you can see from the resource payload above, it does not contain a property named "Microsoft.Compute/disks/encryptionSettings.enabled" and has a property called "encryption.type" instead. The actual response payload doesn’t match the policy rule and that is why the policy would evaluate it as non-compliant.
- Modify policy definition accordingly to meet your business requirement.
In the scenario, if the resource payload has a value for "encryption.type" then it indicates the disk is encrypted. So, we can modify the policy rule as below to solve the issue:
{
"mode": "All",
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Compute/disks"
},
{
"field": "Microsoft.Compute/disks/encryption.type",
"equals": ""
}
]
},
"then": {
"effect": "audit"
}
}
}
**The troubleshooting approach above applies to other policy compliance issues as well.
