Managing Azure Tags via Policy

Azure Tags are a great way to add useful metadata to Azure resources, but without a plan or automated hygiene controls, these can quickly get out of hand. Add to that the fact that tags are case sensitive, and suddenly “costcenter”, “Costcenter”, “Cost Center” and “cost center” are four different tags depicting the same thing. I’ve seen what can happen if this isn’t managed properly, and it’s just ugly.

I wanted to see if I could manage Azure Tags through Policy, and I found that it’s actually absurdly easy. Let’s take a look…

In this post I’m going to do the following:
1. Require a specific tag for all Resource Groups
2. Leverage Policy to enable tag inheritance from Resource Groups
3. Delete all non-Policy tags through code

We start with requiring specific tag for Resource Groups. Resource Groups are one possible boundary that can be used for security and budgeting purposes (with subscriptions being the other if your organization has leveraged the Landing Zone concept detailed in the Cloud Adoption Framework). So for this example, I’m going to require a costcenter tag for all Resource Groups within my subscription. To accomplish this, I leverage a builtin Policy called Require a tag on resource groups.

Taking this policy definition, I click to create an assignment. In my example, I’m assigning this policy to the entire subscription, and I’m requiring costcenter as a tag. If you want to require multiple tags, you’d probably want to create an assignment of this policy for each tag required (alternatively, you could copy the Policy definition and rework it to allow multiple inputs for Tag Name — I’m going the easy route).

With that policy created, I test it by creating a Resource Group.

Sure enough, I can’t proceed until I give it the costcenter tag.

To show the next step, I create a basic Key Vault in the Resource Group. You can see that by default there are no tags associated with this:

So now what we need is a policy that takes our Resource Group tags and pushes them down to the resources. Lucky for us, Azure has one built in called Inherit a tag from the resource group

Again, I take this policy and create an assignment, scope it to the entire subscription, and set costcenter as the tag I want inherited from the resource group. And just like before, if we have multiple tags that we want inherited that’ll require multiple policies (or a copy / modification to the definition).

In the Remediation tab of the policy assignment we see where the real magic happens:

By clicking to create a remediation task, it’s going to go through the subscription and push the costcenter tag down from each resource group to each resource underneath.

This remediation task can take a while if your scope and resource count is large (in my case the remediation task took about 20 minutes to fully complete).

The Managed Identity section sets up the process which will apply the tag to newly created objects. By setting these both up, we should be able to ensure that existing resources get the costcenter tag, and new resources get the costcenter tag.

Back to my Key Vault created earlier, we see that it does indeed have the costcenter tag! Really easy.

To do the next test, I created a VNET and immediately after the VNET was created and available it had the tag inherited:

So the last thing I wanted to do was normalize tags. I started by adding some random tags to the VNET:

Note: I attempted to edit the costcenter tag to a different value but it would not stick. Policy prevented me from editing the value of this tag since it’s being inherited from Policy. In addition, I can’t add a second tag named costcenter.

In a typical Battle Faction style, I wrote some scribble in PowerShell that runs through all the resources in all my resource groups and deletes all the tags

What was I left with? Precisely what I’d hoped for:

So leveraging Azure Policy to manage these tags is really the smart way to go. And if you can build automated ways to build Resource Groups that ensures the data going into the initial tags is useful, valid and up-to-date then you’ll be able to build reports against that data rather easily.