Azure Policy for Governance Enforcement

Microsoft recently made Azure Policy generally available. This post will explain the role of Azure Policy and how you can use it to audit for or enforce governance.
 

 

Azure Policy

If you have a need to enforce restrictions or to assess for company, industry, or regional compliance, then you can use Azure Policy to deploy policies. Typically this type of solution is used in combination with delegated administration for governance. For example:

• Large company: A company with a large collection of subscriptions and an even larger set of resource groups has a dispersed set of administrators around the country, continent, or globe. Azure Policy allows the organization to unify policy across the catalog of subscriptions.
• Developers: Developers are often given administrative rights via role-based access control (RBAC) and they often do things without human supervision. Azure Policy can bring some control back on behalf of the organization.

Policies

Control and auditing are obtained using policies, written using JSON, and are created from one of two kinds of definition:

• Built-in: A set of policies that are supplied automatically by Microsoft
• Custom: Policies that you can write and store in Azure

 
There are some interesting examples in the selection of built-in policies:

• Enforce tag and its value: Enforce a tag that might be used for cross-charging consumption of a single Azure subscription.
• Require SQL Server version 12.0: Prevent deployments of older versions of SQL Server.
• Not allowed resource types: Restrict access to certain kinds of Azure resources.
• Allowed virtual machine SKUs: Limit the series and size of virtual machines that delegated administrators can deploy.

You can assign one of these policy definitions by itself but Microsoft recommends that you deploy initiatives instead. You can think of an initiative as being like an Active Directory group policy object (GPO). You can add one or more policy definitions to an initiative and assign the initiative to a required scope or target.
Note that policies can be created to audit or deny. A denial will create something new from being created (and alert you of deployments previous to assignment). An audit policy will just be used for non-compliance reporting.

Assignments

There are three ways that you can assign a policy or, preferably, an initiative:

• A resource group
• A subscription
• A management group

Management groups are a new preview feature for organizing many subscriptions from a single tenant into a hierarchy with up to 6 layers. This structure can then be used for RBAC and Azure Policy.
When you assign a policy or initiative, it is immediately inherited by all contained resources. For example, if I was to deploy a policy that prevents the creation of network resources (virtual networks, public IP addresses, gateways, and so on) to a subscription, it would affect all resource groups in that subscription.

 
It is possible to create exclusions for a policy. For example, I could create a resource group called networking and grant network administrators contributor rights to this resource group (and its contents by inheritance). All networking resources would be created in this resource group. The previous example which prevents the creating of networking resources would be assigned at the subscription level but an exception would be created for the networking resource group.

Compliance

What good are policies if you cannot see how they are working? Compliance lets you view how successful your assigned policies and initiatives have been. It’s up to you to figure out how to deal with non-compliance instances, such as virtual machine sizes that are not allowed but were deployed before a policy was assigned (as below):

 
Armed with this information, you can access automatically generated reports to assess your environment, find rogue developers/operators, and offer them remedial guidance to become compliant with organizational or legal requirements.