Microsoft Azure Resource Tagging Best Practices

16 October 2022 by Martin Dahlborg

Checking how tags have been applied is one of the two fastest ways to get an indication of what the current state of an environment is. The second is checking whether a naming convention has been followed. In this article I’ll provide recommendations on how to lay a foundation for a tag management process. We also provide access to a detailed “Resource Tagging Guideline” for newsletter subscribers.

Introduction to Using Tags and Tagging in Microsoft Azure

Tags are key-value pair metadata that are applied to cloud resources. They are used primarily to organize your assets, to make it easier to organize resources, or with cost allocation based on resource usage. Tags are added directly to individual resources, to a resource group, or to a subscription. As an example, a tag with the name “environment” and the value “prod” is a tag that is usually assigned to show that an asset belongs to the production environment. Tags provide important context for specific resources and assets in this way, such as how mission critical a solution is, who is responsible for it, who has access to the resources, etc. If you manage resources in Azure, then it can become quite difficult if this information isn’t readily available to you.

In short, add tags to resources for billing or management purposes in Azure. If the tags in your Azure environment aren’t being added in a consistent way, then you likely are facing other issues as well. Everyone should be using tags to organize your assets since you need to organize resources for security purposes at least.

Reviewing Tagging in Azure Based On Best Practices

As a cloud security architect, I analyze the state of not only Azure, but AWS and GCP environments as well. While the primary concerns of a security architect are IT security related, many of the prerequisites of achieving a certain IT security baseline are related to governance processes being in place. Such governance processes are related to having control over changes, having quality assured configurations, issuing approvals in formal way etc. Having such governance controls in place will reduce the risk of security incidents from occurring as there are formal toll gates where quality assurance is done.

The main benefit from my perspective of adding tags is that it makes it easier to see if responsibility has been assigned, to find indicators of governance activities being performed, and to check that the supporting platform services (backup, monitoring, logging) are in place. Reviewing existing tags is a major part for me in reaching a conclusion on whether the organization has established control of the environment and the resources therein.

Adding Resource Tags with PowerShell, Azure CLI and IaC

Tags can be added to new resources in different ways. Tags can be specified during deployments using the Azure portal, using the Azure CLI, in PowerShell scripts or Infrastructure-as-Code templates. Adding tags to existing assets using the portal afterwards, by adding them directly to the resource once they have been created. Even though tags can be managed on each resource in the portal. This however is usually only done if a tag was “forgotten” during deployment, and if automation isn’t fully used by the organization to deploy resources through Azure API’s, scripts, or 3rd party tools.

In Azure, PowerShell or the Azure CLI can also be used to add tags after deployments. Even if you can add the tags manually, it should be automated whenever possible. Another way of working with tags is to enable automation using Azure Automation Accounts, since specific tags can be used as triggers for what should be done if a specific tag is set and what the value of that is.

Working with Azure Resource Manager templates, Terraform, or Biceps, makes it possible to be sure that the correct tags are applied to a resource during deployment. It can also be used as a way to ensure that the tags that are included in the resource group are also added to the resources in it.

Introduction to Azure Tagging Strategies

The main principle is that each tag that you add to a subscription, resource group, or resource show provide a clear value to at least one stakeholder. One purpose can be to logically group related resources together that are in different resource groups.

The purpose of using a tag can be said to tie into one of four contexts. The term “context” describes which type of processes in the organization benefit from the tag being assigned. Tags can be used in the following contexts:

  • Business: Specifying which department, or project, is accountable and/or responsible for the resources and related costs.
  • Service: Identifying specific workloads, services applications, or grouping resources that stretch across different Azure subscriptions and/or resource groups. These tags are also used to provide insight into solution architecture, design, and documentation.
  • Security: Providing visibility into how security non-functional requirements (NFR’s) have been implemented to secure access, limit exposure and reduce risk.
  • Governance: Describing who is responsible for performing governance activities. These tags also providing insights which governance controls have been implemented to perform monitoring, updates, and to ensure availability.

Azure Tags to Organize Your Azure Resources

Examples of tags to use in a tagging convention:

  • environment: Specify the type of environment i.e., sandbox, development, testing, production.
  • businessUnit: Specify the name of the department own the subscription or workload.purpose: Reason why the resource was created and what it’s being used for.
  • costCenter: This tag is used to organize resources for billing. Costs are allocated/distributed using chargeback within the organization.
  • owner: Manager or team accountable for ensuring that governance is performed for the workload, application, or service.
  • technicalLead: Person responsible for performing governance of the workload, application, or service.
  • createdBy: Specify contact information of the person, or name of the CI/CD pipeline, that created the resource.
  • operationsTeam: Specify the name of the team that is responsible for day-to-day operations, for example “central_it”, “dev_ops_team_1”, “project_1”.
  • application: User-friendly name for the application which may or may not be part of a workload.
  • confidentiality: Specify the confidentiality classification level as a foundation for analysis of risk exposure, mitigating security controls, residual risks and risk acceptance.
  • businessCriticality: Specify the availability classification level as decided on by the business in the Business Impact Analysis.
  • disasterRecovery: Specify how the resource and data is protected, and will be made available, in the event of such disaster scenarios as described in the service’s Disaster Recovery Plan
  • project: Specify the name of the project that is using the resources for development and testing.
  • decomissionBy: Date and time when the resource will be decommissioned.

Here is a screenshot of how tags can be described in a “Resource Tagging guideline”:

ResourceTags


Use Azure to get an Overview of Tags

Checking tags on each specific resource isn’t a viable approach. One way to get an overview of which tags are currently being used in your environment is to use the Azure Tags service in the Azure portal.  You can see the tags which have been added to assets, but it’s also possible to see all assets that have been assigned a specific tag. Going through this might take some time but it’s one way to address tag related issues when it comes to Azure governance.  Implementing Azure Tagging Best Practices

The guideline document mentioned in this article is a real-life example based on how I’ve defined tagging requirements in the past working as a consultant. It contains a long list of tags which cover the most common use cases. This article will hopefully help you improve the maturity of the tag management process within your organization.

In my experience, things don’t improve unless there are a few things that come together. For example, there’s almost never an improvement in security if there are policies in place but no one adheres to them, if responsibility is assigned but no additional resources are allocated, if someone excels at performing a task manually but there’s no consistency as everyone else does it differently. To succeed you need to ensure people have the necessary knowledge, that they have access to appropriate tools, a clear understanding of what is required and why, and to automate whenever possible as time is always a limitation.

My recommendation is to base your approach on a light-weight version of best practices that heavily regulated organizations are using. The basic steps would be to:

  1. Define the requirements based on tagging best practices
  2. Assign responsibility
  3. Implement a technical solution (automated analysis)
  4. Measure improvements over time

Below is an example of how requirement can be specified in a Resource Tagging guideline:

ResourceTaggingGuideline


Subscribe to our newsletter here and you’ll receive your copy of the guideline.


Requirements Based on Azure Tagging Best Practices

The requirements should be clearly stated in a policy, guideline, or standard i.e., a document that is part of the organizations Information Security Management System (ISMS). This is necessary to make sure everyone apply tags consistently across your environment.

Since tags are case sensitive in the Azure Tags service, it’s necessary to specify the exact format and casing tag keys should use. As an example, the cost center tag key might be written as “costcenter”, “cost-center”, “CostCenter” (upper camel case), “costCenter” (lower camel case). However, all comparisons (in scripts or likewise) need to be case insensitive just in case. One reason to avoid using dash characters in tag names is that it becomes easier to make mistakes if so. Getting the casing wrong when adding a tag is easier to compensate for, than dealing with missing characters.

A tag could also have pre-defined set of allowed values. Such tags and their values should be evaluated to see if the value corresponds to an allowed value or not. By specifying these detailed requirements for both tag keys and tag values it will make it easier to filter and sort output from scripts or other forms of automated analysis. It will also make it possible to detect mistakes and to see to it that those are corrected.

If you also have a Cost Management Guideline in place, then you might also need to specify which tags are mandatory for resources that must be deallocated according to a schedule (using automation scripts or similar). The purpose of this is to reduce cost when resources are not in use.

Note, any tags that are generated by the cloud service itself should be disregarded as there’s no value in including them to a guideline.

Tagging Strategies Based on Resource Type

As mentioned, tags can be applied to subscriptions, resource groups, and resources. Note that inheritance applies to tags, which means that tags assigned to a resource group should always apply to all the resources in it. The exception is when a tag has already been added to the resource group, and an identical tag is also added directly to a resource, then the tag value in the resource tag supersedes the resource group’s tag value.

Tagging Subscriptions

Apply tags at the subscription level to provide information about what the subscription is used for, who is using it, and who is managing it. Most tags will likely be added to resources and resource groups.

Tagging Resource Groups

Add a tag to the resource group to make it applicable to all resources within the resource group. Use different resource group for assets since they should be decommissioned along with the main resource they contain. Resources in the group that won’t be possible to remove with the resource group need a separate resource group.

Tagging Resources

Adding tags directly to a resource is usually done when using automation as a way to ensure inheritance, or to add additional context relate to the resource that doesn’t make sense to add to the resource group. That said, tagging your resources shouldn’t be your main approach since it increases complexity. Tags associated with a resource take precedence over others, which means that if evaluation based on tags is done using automation (PowerShell, Azure CLI) then additional effort is needed to put into the development of those scripts.

Assigning Responsibility

The “Responsibility assignment matrix” model, also known as the “RACI” model, is commonly used when there’s a need to clarify responsibility. Using this model, it’s quite easy to include this information in a document, on an Intranet, in Confluence or similar. This is what I usually work with when it comes to documenting who, or which teams, have some form of responsibility for governance and security related activities.

Measuring maturity

Once requirements have been defined, responsibility has been assigned, a technical solution implemented, then there is a last step that is necessary. That last step is to verify that everyone is adhering to the requirements, is following the guidelines correctly, and that improvements are being made over time. Measuring is also beneficial to if you have to provide proof of compliance as a security architect to an internal audit department or to external auditors who have been contracted to review regulatory compliance for example. To this end, the “Capability Maturity Model” (CMM) framework for measuring maturity, or its successor the CMMI model, as a way to measure how well a process is performing.

Performing Reviews of Tags in Azure Environments

As mentioned previously, the main tool is the Azure Tags service in the portal. Querying the “Resources - List” Azure REST API is another way as the JSON data in the response includes tags for all the resources in a subscription. Correcting errors using the portal might be easy, but it can become more complicated if corrections have to be done in IaC templates and through re-deployment.

One final note on what to look for if you are performing reviews by yourself. When I perform a review of an environment these are the things that I look for. They are basically the opposites of recommendations that I have provided in this article and included in the guideline document.

Possible issues:

  • Untagged resource groups
  • Possible inconsistencies between tag values when the same tag has been applied at the resource group level and at the resource level (mutual exclusivity).
  • Missing mandatory tags
  • Misspellings
  • Wrong casing used
  • Tagging applied differently in different environments
  • Certain tags have values which deviate from what’s allowed
  • Tags contain contact information that is no longer relevant i.e., a person has left the organization, changed roles or the organization itself has changed structure

Possible conclusions:

  • Work is done ad hoc (CMM level 1)
  • The Change Management process is deficient
  • Responsibility hasn’t been clearly defined
  • Unnecessary costs are accrued due to a lack of automated deallocation of resources when they aren’t needed
  • Unacceptable residual risks exist due to insufficient security levels regarding confidentiality and availability

Final note

In this article I’ve presented an approach on how to ensure that one can be successful when implementing Resource Tags in an Azure environment. I hope that this information was of value and that it will help you get started if you haven’t done so already, or that it might help you improve certain aspects on what you already have in place.

As a reminder if you haven’t done so already, subscribe to our newsletter here and you’ll receive your copy of the Resource Tagging guideline:


Resource Tagging Guideline video on YouTube

I’ve recorded a video that is available on our YouTube channel. In it I go through the Resource Tagging Guideline document itself and provide more details regarding each tag, what the reason could be behind wanting to use it, and a few other tagging related topics.

References

Cloud Service Provider recommendations:

Implementing tagging in Azure:

Other references: