Azure Policy and Scoping parameters for the New-AzureRmPolicyAssignment cmdlet

Andrew Kelleher
Azure Architects
Published in
3 min readNov 12, 2018

I recently had the need to work with Azure Policy for a client. As you’d expect from the name, Azure Policy is a service within Azure that allows you to create, manage and apply policies.

With policies you can enforce certain configurations i.e. resources are only allowed to be created in a specific region. Alternatively, you can simply audit for specific misconfigurations i.e. auditing is not enabled on Azure SQL servers across your subscription.

Azure Policy is different from role-based access control (RBAC). RBAC focuses on the actions that a user can complete against an Azure resource based on their assigned role i.e. Contributor, Reader etc. Azure Policy is concerned with the properties of resources during deployment or existing resources.

Once setup you get a nice overview of which policies are not in compliance -

You can then drill down into each policy and see which specific resources are non-compliant -

You can define your own policies using JSON, but there are also a significant number of built-in policies available.

With Azure Policy you can apply configurations via the Azure Portal. This is fine for testing but really you want to be using the CLI or PowerShell commands for repeatability.

New-AzureRMPolicyAssignment cmdlet scoping parameters

In my scenario I was using the New-AzureRmPolicyAssignment cmdlet as part of a PowerShell script deployed via Azure DevOps.

The majority of our policies were applied at the subscription level. However, we also had a need to exclude some resource groups from some policies.

Policy assignments are scoped using two parameters; -scope and -notscope. At first glance this looks straightforward, simply pass the name of the subscription and resource groups -

However, as with many Azure cmdlets, when referencing resources it’s actually the resource ID that’s required. The following script grabs these, puts them into the expected format and finally, passes them to New-AzureRmPolicyAssignment -

Summary

Azure Policy is hugely powerful and useful in helping ensure that your Azure subscriptions and resources are compliant with your corporate and technical policies.

However, given the large number of pre-defined policies, careful thought needs to be given to which ones are relevant.

Some of the key lessons learned I’ve seen with Azure Policy include -

  • Ensure the business has input into the policies from a governance and compliance perspective
  • Engage all of the technical teams that will be impacted by any policy settings
  • Assess which pre-defined policies are applicable to your business and Azure resources
  • Create custom policies only as needed — these all need to be maintained
  • Apply policies as early on as possible — this helps mitigate breaking any existing CI/CD release pipelines
  • Assign policies using PowerShell and ensure these scripts reside in source control i.e. an Azure DevOps Git repository
  • The pre-defined policies are constantly added to by Microsoft — regularly review and assess if any are applicable to your organisation

Further reading

Video: Channel 9 on MSDN — Azure Policy with Corey

Tutorial: Microsoft — Create and manage policies to enforce compliance

Tutorial: 4sysops — Enforce Cloud Governance with Azure Policy

--

--

Andrew Kelleher
Azure Architects

Freelance Azure Architect | Helping organizations design and build cloud stuff | CarbonLogiQ.io