Azure out of the box comes with a number of controls that allow users to shape permission on Azure through roles and role assignments. These roles control what actions a user can perform, but it does not limit what these actions can do within their given scope. For instance, RBAC can be used to configure who has the ability to create or administer virtual machines, however, RBAC cannot control which VM SKU’s are permissible or what regions are permissible for those VM’s. It’s in scenarios like the latter where Azure Policy comes in.

Azure Policy is an optional service on Azure baked into the fabric of Azure Resource Manager. It allows users to create rules that can restrict the kinds of behaviors that users can do as well as enforce certain behaviors (like tagging) that are needed for organizing and managing costs on Azure.

Policy Use Cases

Fundamentally, Azure Policies can be used in two different ways:

  • Enforcement – Enforcing Azure prevents users from performing certain tasks on Azure according to the policy definition. When a policy is applied to existing resources, the enforcement will not undo what has already been done, however, it will prevent new behaviors. In the example above, a policy that allows for only specific VM SKU’s will not remove a VM, not in the SKU list, but it will prevent new VM’s from using anything outside that SKU list.
  • Audit – Auditing with Azure policy will show when settings on Azure resources are out of alignment with the desired configurations that are prescribed by Azure Policy. Audits themselves, however, do not do any sort of policy enforcement. It is only used for showing what is and is not in alignment according to the policies that have been created. Audits are useful for when an Azure Environment has already been configured. In the example above, the audit would show any VM’s using a SKU, not in the policies allowed list.

Azure Policy Definitions

A policy definition consists of two basic components – a condition (“if”) used to match a rule and then an action (“then”) that determines the effect the policy will have on specific outcomes. The following sample is a simple policy that will ensure that VM NIC will have an NSG attached to it. It works by looking to see if the networkSecurityGroup.id the field exists, and if it does not, it will deny the creation of the NIC, and thus the VM deployment will fail.

{
"mode": "All",
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Network/networkInterfaces"
},
{
"field": "Microsoft.Network/networkInterfaces/networkSecurityGroup.id",
"exists": false
}
]
},
"then": {
"effect": "deny"
}
}
}

The condition matches the policy rules against fields in the Azure Resource Manager engine. It has a robust selector scheme that allows for complex matching against many different kinds of elements and data types within ARM. Azure Policy also allows for policies to be parameterized so that they can be used in multiple contexts.

Authoring policies can be a complicated task, as it requires a basic understanding of how Boolean logic works, some understanding of the selector tags that Policy uses for building policies, and a deep understanding of Azure Resource Manager and how it is organized. Fortunately, Microsoft has provided decent documentation on how to make policies as well as a rich library of samples and built-in policies that help make authoring custom policies simple.

The built-in policies can do many things on Policy right out of the box without having to create custom policies. These policies have grown over the years since the introduction of Azure Policy to do many things that customers had frequently asked for, such as limiting the SKU’s for VM’s or limiting what regions are available for Azure resources. It’s always best then to first check the built-in policies to see if one exists. Second, one should check out the samples in the sample repository that can be useful as well. Third, one can search for a policy that may have already been created for a specific purpose. If none of these turns up a policy that will be useful, then authoring a policy will be the way forward.

Azure Policy Initiatives

Azure Policies can be grouped together to create initiatives. Initiatives can be applied in much the same way that a single policy can be applied, therefore alleviate having to apply many single policies one at a time. Initiatives can be useful for managing large scale deployments with a large set of policies.

Microsoft also supplies many built-in initiatives for compliance and security checking, such as the CIS Microsoft Azure Foundations Benchmark Regulatory Compliance or NIST SP 800-53 among many others. This help simplifies regulatory compliance checking by providing a baseline to help accelerate cloud adoption using standards maintained by Microsoft. If a user is deploying apps in a regulated industry to Azure, then using one of the built-in initiatives will help save time and money for ensuring that Azure is compliant and secure.

Initiative assignments, too, can have parameters as well as each of the policies within the initiative. This allows Initiatives to be applied in a different context.

Azure Policy Scope

The scope of a policy or initiative determines how broadly a policy applies for both enforcement and auditing purposes. Azure policies can be assigned at three levels:

  • Management Groups allow enterprises to create an arbitrary hierarchy that matches an organization’s structure without being prescriptive. This allows groups of groups to be created, and those groups can then contain Subscriptions. A policy applied at a higher group implies that resources under that group will be under that policy’s audit or enforcement rules.
  • Subscriptions are the next level, so any policy applied at this level means that all resource groups in the subscription will be subject to the policy.
  • Resource Groups are the lowest level for policies, so only the resources in that resource group are under policy enforcement.

The best practice here is to prefer the highest level needed for the policy to simplify policy management.

It is possible within Azure Policy to create exceptions within a given scope too. This allows for special cases to exist without having to create complicated policy rules to manage these exemptions. Exceptions, though, should be used judiciously to prevent creating a management nightmare.

Conclusion

Azure Policy is a robust tool for maintaining compliance on Azure. This tool, along with RBAC and other security measures helps ensure that Azure will be both compliant and secure for all apps deployed to the Azure infrastructure.