Azure policy

Azure Policies ensure proper cloud governance by controlling resource deployment and usage

Azure Policy is a service in Azure that you use to create, assign, and manage policies. These policies enforce different rules and effects over your resources, so those resources stay compliant with your corporate standards and service level agreements. Azure Policy meets this need by evaluating your resources for non-compliance with assigned policies.

1. can have a policy to allow only a certain SKU size of virtual machines in your environment. Once this policy is implemented, new and existing resources are evaluated for compliance. With the right type of policy, existing resources can be brought into compliance
2. Allowed Location Only
3. Allowed types resource only 

See the Image VM SKU Ds1V2 not allowed

How is it different from RBAC?

There are a few key differences between Azure Policy and role-based access control (RBAC). RBAC focuses on user actions at different scopes. You might be added to the contributor role for a resource group, allowing you to make changes to that resource group. Azure Policy focuses on resource properties during deployment and for already existing resources. Azure Policy controls properties such as the types or locations of resources. Unlike RBAC, Azure Policy is a default allow and explicit deny system.

see how to create Azure Policy 

Azure Policies start off with you defining a policy within Azure which could be something as simple as implementing a naming convention for lets say a Virtual Machine.

The following policy definition states that when creating an Azure VM it must match the naming convention we specify

---

An example of how to do this would be as below (in JSON):-

---

So what we are saying here is that if any user tries to create a Virtual Machine within a Resource Group within Azure then it must be named something like VM-P-ABC-GS01.

To get started with trying this out within the Azure Portal search for Policy at the top of the Azure Portal and you’ll see a screen something like the below: –

Here I have loaded the Policy area of the portal for an existing project and you can see the level of detail and see that I have on overall compliance of 95% on my resources and listed are the Non-compliant state Resources (if I were to expand).

By clicking on any of the non-compliant areas I will be shown all of the non-conforming resources which is awesome.

With Azure policies in place we can enforce naming conventions for a Resource Group, if we want to go further we could use Azure Management Groups – which I will cover in a separate blog post.

But what if I already have resources in place and I want to start using naming conventions with Azure policies?

In that case we need to talk about the contents of a policy definition which you can read up on.

Lets review another Azure policy (in JSON)

In the screen shot above the import part here is the EFFECT part.

Effect

Policy supports the following types of effect:

• Deny: generates an event in the activity log and fails the request
• Audit: generates a warning event in activity log but doesn’t fail the request
• Append: adds the defined set of fields to the request
• AuditIfNotExists: enables auditing if a resource doesn’t exist
• DeployIfNotExists: deploys a resource if it doesn’t already exist
• Disabled: doesn’t evaluate resources for compliance to the policy rule

So if we have resource which we might want to change the name of going forward and we are able to then perhaps use Audit to start off with and then change them to Deny.

Note if you make use of Azure policies and use Azure Devops to create Infrastructure as Code (IaC) then the easiest place to find issues with failing releases is in the build summary log.

Summary

In summary, there is a lot more to Azure policies, here I just wanted to give you some idea of what you can use Azure policies for.