An Azure Policy journey

Content

This article shares Azure Policies and series of implementation tips.

All the policies I use are located in the following GitHub Repository : JamesDLD/azure-policies, deployed via the script launch.ps1 and tested through the following GitHub workflow : manage-azure-policy-mvp.

The approach is to use built-in Azure policies whenever they exist, otherwise we use custom policies with the trigram “MVP”.

These are the guidelines used for the remediation activities (effect “DeployIfNotExists”):

• Use of ARM template whenever the remediation action creates a new resource. It is actually pretty rare, it’s the case for few resources like enabling Diagnostic Settings on a specific resource.
• Use of deployment scripts in ARM templates whenever the remediation action need to modify a resource that already exist.

I do recommend these guidelines to prevent some change to be pushed by ARM template on parameters you don’t want to touch. You can consult this article ARM template deployment what-if operation for more information.

Tips number 1: Naming Convention

Respect the naming convention proposed here “Design Azure Policy as Code workflows”, it’s a real benefit for maintenance, collaboration and deployment automation (for exemple : launch.ps1).

Policies

The following “Overview” screenshot gives a summary of our Policy Initiatives.

Overview

Tips number 2: Location and Assignment Scopes

Respect two guidelines :

1. A list of policies and policies initiatives definitions are created in a master management group.

2. Role assignment are done at the subscription level per policy initiative definition.

High Level View

Tips number 3: Built-In and custom policies

Use built-in Azure policies whenever they exist, otherwise use custom policies and prefix them with a specific word in order to view them easier.

Built-In or Custom

Tips number 4: Role assignment

1. When using policies for remediation activities (effect “DeployIfNotExists”) make sure to declare the roleDefinitionIds under the details property of your policy. Make sure those roles Ids have the least privileges needed for their remediation action.
2. Perform the role assignment with a script (launch.ps1) to give a friendly name to the role assignment identity object.

Role assignment

Tips number 5: An option to exclude some resource

You can exclude some scope at the policy assignment level but it might be too much to exclude all the resources of a scope, for all policies of you have inside your policy definition ; remember tips 2 : we assign policy initiatives, not policies directly.

My recommendation here is to include a tag in all your policies, if the target resources contains this tag, then it will exclude the resource from the policy audit. This is not perfect because it won’t be displayed in the Azure Policy dashboard but it’s really use-full.

Exclude

I’m used to have as tag key the “policyDefinitionReferenceId” and as tag value “exclude”. To make it more convenient I ouptut the “policyDefinitionReferenceId” in each remediation arm template “output”, it’s then easier to find it and apply it to one resource.

As shown in the following screenshot the policy “[MVP] Latest TLS version should be used in your Storage Accounts” won’t be applied to the Storage Account “saofrnat40dvpoc01”.

Exclude Storage Account

Tips number 6: An option to include only some resources

You might want to enable a policy only on specific resources, for exemple the policy that enables Diagnostic Settings on all the storage account (SA) might not be relevant for every SA, it could also have a real cost impact if you enable it every where.

The tips here is to add a specific tag on your resource to declare this resource as a candidate of your policy.

In the following screenshot the policy [MVP] Deploy Diagnostic Settings for Storage Accounts with a given tag to Log Analytics workspace will be applied on the Storage Account because it contains the tags “<policyIdName> : include”.

Include

Conclusion

Azure policy is a real efficient way to view and comply with a lot of Infrastructure requirements, it deserves to be well known as it could be complex to manage especially if you don’t use Policy Initiative definition to group your policies.

I really recommend to use policy through code instead of managing them directly from the portal but its my opinion, it’s actually my method to better understand how thinks work.

We saw a series of tips, I’m thinking about detailing some policies for the next articles, especially the ones who use the perfect combo : Azure Policy Remediation with ARM Template deployment scripts.

See you in the Cloud

Jamesdld