Naming conventions isn’t the sexiest topic to be blogging about, but that doesn’t mean it isn’t important. If you’ve worked in IT for any length of time then you will likely understand the importance of naming conventions. Resources named in a consistent and meaningful way can make life a lot easier. This is just as important in Azure. And if you are anything like me, you will understand the rage induced when someone creates ‘Daves WebApp’ in a production environment!

Azure Policies are here to save us. Policies enable us to define rules about what resources are created and the configuration. This includes the names we give them. In this post, we are going to look at how we go about creating policies to define the naming conventions. Then we enforce them.

Creating our First Naming Policy

First off, let’s create an example policy to manage the names allowed for Virtual Networks. There aren’t any builtin policies in Azure for naming conventions (at time of writing). So we are going to need to create a Custom Policy.

Go to the portal - ‘All Services’ - ‘Policy’, and click ‘+Policy Definition’.

Fill in the wizard, giving it a Subscription, Policy Name and Description

In the Category field, I’d suggest you create a new category for ‘Naming’. There could be many of these policies so it makes sense to have a category for them. You can call it anything you like.

Before we scroll to the bottom and click ‘Save’, take a look at the ‘Policy Rule’ section. Paste in the following code between the brackets. We will go over the details of this in a moment.

{
  "mode": "All",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Network/virtualNetworks"
        },
        {
          "not": {
            "anyOf": [
              {
                "field": "name",
                "like": "AZ-VN-*"
              },
              {
                "field": "name",
                "match": "AZ-VN???"
              }
            ]
          }
        }
      ]
    },
    "then": {
      "effect": "deny"
    }
  },
  "parameters": {}
}

Go and click on ‘Save’ and you will have a new policy for naming Virtual Networks.

Assigning the Policy

Now that you have the policy you will need to ‘Assign’ it to your subscription. This defines what it applies to. ie which Subscription or Management Group. That way it’s possible to have different naming conventions for different areas.

To assign it, find the policy in the list, click on the three dots to the right of it and select ‘Assign’.

You will see a wizard. Select the subscription to assign it to (or management group if you are using them). You can also select exclusions if you have special resource groups that are outside of your policies. Then click through to Assign the policy.

Testing the Policy

Now if we create a new VNet and call it something that is outside of the policy, then we get a failure message and the VNet won’t be created!

This error message isn’t very descriptive, and it’s difficult to tell why your VNet creation is rejected. There are some clues though. If you go to the failure message and click on the red banner at the top. From there if you look in the ‘Raw Error’ section, the Target value gives some idea of what it is looking for. From there you can tell how you need to name your VNets. It’s not great but you have some good documentation for your naming convention that you can give the user ;)

So, now you have your first policy in place and any new VNets will are named exactly as you define in your policies.

Creating More Naming Policies

Now let’s revisit the code in the policy and look at the three main sections of the code. (ie the rules that are defined).

1. Resource Type

This section defines the resource types that the policy is controlling. In this example, we are looking at Virtual Networks, so it is defined as “Microsoft.Network/virtualNetworks”. That’s great if you know the provider and type off the top of your head, but it’s not too difficult to find. If you go to one of the resources you are trying to look for and click on ‘export template’ then you will get the ARM template for the resource. In the template (normally at the top) you will find a ‘resources’ section that has a ‘type’ for the resource. This is what you are after. This example is for an Azure App Service…

2. Naming Rules

This defines the rules we are creating for our naming convention. ie How things are named. The rule has an ‘anyOf’ section and then a couple of rules. This means that it needs to conform to at least one of these to be permitted.

  "anyOf": [
    {
      "field": "name",
      "like": "AZ-VN-*"
    },
    {
      "field": "name",
      "match": "AZ-VN???"
    }
  ]

The ‘anyOf’, could also be replaced with ‘not’ or ‘allOf’ depending on how you want the logic of your rules.

In this example, we have used the conditions “like” and “match”. This could be a several different conditions like “equals”, “notEquals”, “notMatch”, “contains”, “notContains” etc. For the full list of Conditions see the Microsoft Docs

The ‘like’ condition takes a single wildcard character. In this case, we are looking for anything that starts with ‘AZ-VN-’ with any number of characters after if. This works well if your naming convention always starts with a particular string.

The ‘match’ condition uses the ‘?’ to signify a single letter. In this example, we are looking for anything starting with ‘AZ-VN’ with 3 letters after it. If we wanted to signify 3 numbers we could use the ‘#’ character. ie ‘AZ-VN###’ would signify the same as above but with three numbers at the end. If you don’t care if it’s a number or a letter then you can use ‘.’ to signify any alphanumeric.

3. Rule Effect

The final section is what defines the effect of our policy.

  "then": {
    "effect": "deny"
  }

In this example, we are denying anything that doesn’t meet the rule conditions. If you try and create a VNet with the name formatted incorrectly, then it will stop you from creating it.

This doesn’t have to be the case though. We could use ‘audit’ to report on what is compliant and what isn’t. This is a good starting point. It’s good to use this while the official naming policy is being communicated. It’s even possible to set this to ‘disabled’ so that we can create the rule before we turn it on.

For a full list of Azure Policy effects, see the Microsoft Docs

Summary

Now we have all we need to create policies to fit our naming convention. Which we can apply to our Subscription or Management Groups. All we need to do is create one for each of the resource types and assign them. There is a bit of work to do here but you will only have to do it once for each resource type.

These policies won’t rename all your resources. You will need to recreate anything that needs correcting. Then you will have a consistent and well controlled environment.