All architecture designs are driven by set of rules to meet regulatory and security compliances. Azure policies come into play to enforce these organizational policies at Management Group, Subscription and resource groups level. For example, your company wants to ensure that all your azure resources reside in one of the preselected location, and users are not allowed to create resources outside these locations. Azure Policy makes it possible by enforcing location setting across Management Group / Subscription/ resource groups.
The life cycle of azure policy
- A policy definition can be stored at the Management Group level or a Subscription.
- Policy definition location is mandatory before you create a custom policy.
- When you assign a policy, it will take a minimum of 30 mins to take effect..
A Policy effect can be one of below.
- Append – appends settings to an existing resource. For example, you want to allow access to storage account from an ip address , it can be achieved using append effect .
- Audit – Writes a warning event in the activity log when evaluating a non-compliant resource. In other words, it is audit if resouce exisits. For example, you want to evaluate if all your azure resources and resource groups are in the exact location , it can be achieved using audit effect .
- AuditIfNotExists - Enables auditing of resources if condition met, but don’t have the properties specified in the details of the then condition. For example, you want to check if the security center plugin is installed on Azure VMs , it can be achieved using AuditIfNotExists
- Deny – Prevents resource requests. For example, you want to allow only the predefined SKUs and deny VMS outside predefined SKU’s , it can be achieved with deny effect
- DeployIfNotExists – Deploy if the resource doesn’t exist, this is similar to Audit ifnot exists . Instead of just auditing it will deploy the resources.
- Disabled - Policy is evaluated, but settings are not applied.
- Modify - used to add, update, or remove properties of a resource..
Polices are evaluated in the below order.
You can assign more than one policy to a Management Group / Subscription / Resource Group. Like Group policies in Active Directory, the policies are inherited from the top unless you exclude them in the assignment.
Below is a simple demo for assigning an inbuilt policy to allow only Standard A0 SKU. At the end of the video, you can see that the Virtual machine creation fails if I select anything apart from Standard A0 SKU. Another important observation is that the policy “Audit resource location matches resource group location” is not stopping me from creating a VM in east US2 location as the policy effect is audit only.
Exclusions / Exemptions for a policy are applied during the policy creation as well as post-policy evolution.
Initiatives are nothing but a group of polices definitions. You can define your initiative along with version control.
One of the most significant benefits of azure policies is you can view the overall compliance status of policies and initiatives in one dashboard. Azure Policy compliance dashboard lets you view all the policies and initiatives assigned to Management Group/ subscription/ Resource Group. You can filter the compliance using Scope/policy definition type/compliance state/ custom search.
You can perform below actions from compliance dashboard .
- View definition of policy /initiative
- Delete assignment
- Edit assignment
- Duplicate the assignment
- Create exemption
When you delete a resource group, policy assignments are removed too. You can’t check what policies were previously assigned to a deleted resource group. However, the custom definitions will still be available as they are created at the subscription level or Management Group level.