In our previous post, we discussed how we can access compliance data for the Azure Resources. Compliance data can be accessed using various channels such as Azure Portal, Azure CLI, Azure REST APIs and Azure PowerShell. Once the compliance data is available, one should check which resources are non-compliant in accordance to the Azure Policy or Initiative, why they are flagged as non-compliant and what actions could be taken to remediate the same. In this blog post, we are going to discuss the same.
Understanding cause for Non-Compliance
When a resource is non-compliant, the compliance details for that resource are available from the Policy Compliance page. The compliance details pane includes the following information:
- Resource details such as name, type, location, and resource ID
- Compliance state and timestamp of the last evaluation for the current policy assignment
- A list of reasons for the resource non-compliance
To view this, open Azure Portal -> All Services -> search and select Policy. On the Overview or Compliance page, select a policy in a compliance state that is Non-compliant. Under the Resource compliance tab of the Policy compliance page, right-click or select the ellipsis of a resource in a compliance state that is Non-compliant. Then select View compliance details.
The Compliance details pane displays information from the latest evaluation of the resource to the current policy assignment:
In this case, we see that our resource group is located in the CentralUS location, which is not in the list of allowed values. If the resource is non-compliant for multiple reasons, each is listed on this pane. Equally important is the lastevaluated field to see when was the last time the resource was analyzed for compliance.
If the resource is compliant, the ‘Compliance Details’ pane will not be available:
Do note that as the compliance details for a Non-compliant resource shows the current value of properties on that resource, the user must have read operation to the type of resource.
Viewing Change history
As part of a new public preview, the last 14 days of change history are available for all Azure resources that support complete mode deletion. Change history provides details about when a change was detected and a visual diff for each change. A change detection is triggered when the Resource Manager properties are added, removed, or altered.
Remediate Non-Compliant Resources
There are multiple reasons for a resource to be flagged as non-compliant with the Azure Policy. It is possible that if the resources are non-compliant, you can not only flag them, but also design an Azure Policy to remediate the resources to bring them into compliance. However sometimes it may not be possible to directly remediate the azure resources.
For example, an Azure Policy has determined that one of your storage accounts is located in the CentralUs but allowed locations are only EastUs and EastUS2. However, once the storage account is created, you cannot change the location unless you delete it and re-create it.
In another example, an Azure Policy has determined that all of your resources belonging to a particular resource group must have a tag with name and value pair as ApplicationId and 1693. If one of the resources does not have this tag created during deployment, you can trigger Azure Policy to create the same for the said resource.
Resources that are non-compliant to a deployIfNotExists or modify policy can be put into a compliant state through Remediation. Remediation is accomplished by instructing Azure Policy to run the deployIfNotExists effect or the tag operations of the assigned policy on your existing resources.
One of the alternative remediation methods is to bring the resource into compliance by performing manual operations. Considering previous example of where one of the resource group does not have a tag specified in the Azure Policy, you can go ahead and create the tag itself. After this, you can manually trigger the policy or initiative assignment for a on-demand scan or you can let it happen at the next scheduled interval.
Another alternative used for remediation is to define exclusion for the resources which are flagged as non-compliance. Consider the example where one of the storage accounts used in the production environment is flagged as non-compliant because it is in a different location than allowed list. In this case, since a direct remediation is not possible either by performing manual operations or by using Azure Policy, one can define an exclusions and apply the policy or initiatives again.
Exempt a non-compliant or denied resource using Exclusion
Go to the definition of Azure Policy Assignment for which you need to create exemption and define exclusions by clicking ellipsis:
Another popular way is to create a separate resource group, say policy-exempted-rg, and then apply exclusion for this resource group. After this, move the said resource to the resource group.
Working with false positives
If the applied Azure Policy does not have correct set of rules defined in the proper order, the resources will be flagged as non-compliant, even though they are compliant. For example, consider below case of storage account where it is located in the correct location but it is still flagged:
In such a scenario, evaluate the policy rules carefully and correct the same. Once the rules are fixed, after the next scan, the resource will move to compliance state:
Summary and Notes
In this post, we have discussed how we can determine the reasons why an Azure Resource has been flagged for non-compliance and how to take the remediation actions. The remediation actions can vary a lot from using another Azure Policies to modify assignments to define exclusions to resolving false positives to manual operations.
Further Reading:
Create and Manage Policies – https://docs.microsoft.com/en-us/azure/governance/policy/tutorials/create-and-manage
Remediate non-compliant resources: https://docs.microsoft.com/en-us/azure/governance/policy/how-to/remediate-resources
Determining non-compliance reasons – https://docs.microsoft.com/en-us/azure/governance/policy/how-to/determine-non-compliance
[…] our previous blog post, we discussed how we can leverage Azure Policy to bring Azure Resources to into […]
LikeLike