Creating a Tagging Strategy for Azure

Azure has many controls out of the box that helps tailor the experience to an organization on Azure. Such controls include Azure Management Groups for organizing subscriptions, Azure AD with Role-Based Access Control (RBAC) to manage access to Azure resources, Subscriptions and Resource Groups for organizing resources, and Azure Policy to enforce compliance and augment security on Azure. Beyond these controls though, there may be a need to help organize and manage resources on Azure that don’t fit into any of these more prescriptive models as one begins to plan and implement a governance and security strategy on Azure. This is where tagging comes into play. Because tags are more arbitrary, the tags can be applied across subscriptions, resource groups, and resources according to the patterns that are employed by the users.

Choosing a Set of Tags

There is no one-size-fits-all approach to creating a tagging strategy. Rather, the conversation starts with trying to understand how resources are going to be organized on Azure from a management and security perspective first. Once this is done, tagging can then be applied.  It’s best to think about tagging on Azure before getting too far into one’s Azure journey because it is much easier to implement and enforce tagging on Azure before a deployment gets too large. Because tagging is arbitrary though, all sorts of different approaches and uses for tagging can be employed ranging from technically oriented tags that apply to how resources operate to business-oriented tags useful for helping shape business needs.

Here are five broad categories of tags to think about when employing tagging on Azure. Think of these as being signposts on a gradient ranging from technical to business:

• Functional – Functional tags are useful for organizing resources according to the roles they play within a given system or application. Example: Users may have a tiered application with a frontend, backend, and database. Users can create a tag called “tier” that denotes the tier the resource on Azure is supporting. Example: If users have multiple apps, users could tag a resource with an “app” tag, then its value becomes whatever app the resource is serving.
• Classification – This type is useful from an operational perspective.Example: Many organizations organize their applications into various tiers for disaster recovery purposes, with some tiers being mission-critical and other applications being less mission-critical. Creating a tag called “SLA” is useful for this purpose. Example: Commonly, users with employ a tag to denote an environment as well, such as “dev” for development or “prod” for production.
• Accounting – The first two types deal primarily with the IT unit, but Accounting is where tags begin to have an impact beyond the technical. Tags here are useful for various things when it comes to cost and resource management on Azure. Example: Many organizations use a bill back model, and having tags associated with resources allow organizations to produce reports that can be useful for showing where Azure spend is happening and bill the other units within an organization. A tag, in this case, might be “Department” to denote the business unit financially responsible for the resources on Azure.
• Partnership – For some organizations, the organization will have business relationships with other organizations or individuals. Example: Some organizations provide Software as a Service (SaaS). The organization may choose to implement a tag if a resource is part of a SaaS offering on a per-customer basis. Example: An organization may assign a resource “owner” to a tag. Tagging a resource with an “owner” tag then denotes who is managing the resource within the context of a larger, often complex IT Organization.
• Purpose – The final tag type may be useful for organizations that have a complex array of applications, services, and resources supporting a goal.Example: Some organizations organize projects or resources into high-level programs, initiatives, or business processes that stripe across different apps, units, or partnerships. Organizing resources using a “program” or “initiative” tag can help show what these are supporting.

Assessing the landscape of one’s organization often will help precipitate the tagging strategy to be employed with Azure.

Enforcing Tagging on Azure with Polices

Beyond the tagging strategy itself, there also comes a need for tagging enforcement as part of compliance. Because tagging is arbitrary, and therefore organizationally specific, which tags and the values for those tags are not something that Azure provides or enforces. However, it is possible with Azure Policy to enforce a tagging strategy.

Here are three ways to approach this:

1. Use several built-in policies and deploy them as an initiative. This approach allows users to leverage many of the built-in policies on Azure. The built-in policies allow users to require a specific tag or a specific tag with a value. Users can create multiple instances of the built-in policy as part of an initiative, then apply that initiative to the management group, subscription, or resource group. The principal advantage of this approach is that it uses built-in policies to enforce tagging on Azure. The drawback however is that it can require numerous policies to create a full-fledged tagging initiative on Azure.
2. Use built-in policies to inherit tags and values from a resource group. This approach allows users to assign tags to a resource group, then implement a policy that will assign tags to resources in the resource group from the resource group’s tags. This approach works well if resource groups contain a set of resources all intended for the same purposes that the tags are used for. It can also simplify tagging as well. The primary drawback is that it doesn’t allow a resource group to contain resources that might be outside the scope of the tags.
3. Use custom policies. Custom policies offer a great deal of flexibility in enforcing tag compliance. A single policy can enforce a full set of required tags and be used to set default values for resources in a group. The primary advantage of this approach is customizability, but the drawback is that custom policies require time and effort to develop. The following policy is an example policy that will ensure that specific tags exist on resources when they are created, and if not, add the tags to the resource with default values.

   {
       "mode": "Indexed",
       "policyRule": {
           "if": {
               "allOf": [
                   {
                       "field": "tags[environment]",
                       "exists": "false"
                   },
                   {
                       "field": "tags[unit]",
                       "exists": "false"
                   },
                   {
                       "field": "tags[shutdown]",
                       "exists": "false"
                   }
               ]
           },
           "then": {
               "effect": "append",
               "details": [
                   {
                       "field": "tags[environment]",
                       "value": "dev"
                   },
                   {
                       "field": "tags[unit]",
                       "value": "it"
                   },
                   {
                       "field": "tags[shutdown]",
                       "value": "never"
                   }
               ]
           }
       }
   }
   

   Additionally, a similar policy can enforce specific values for tags on a resource. The following policy ensures that tag values fall into a predefined set of values, and denies a resource creation if the tags are not in the range.

   {
       "mode": "Indexed",
       "policyRule": {
           "if": {
               "anyOf": [
                   {
                       "field": "tags[unit]",
                       "notIn": ["it","acct","hr","man"]
                   },
                   {
                       "field": "tags[environment]",
                       "notIn": ["dev","test","uat","prod"]
                   }
               ]
           },
           "then": {
      "effect": "deny"
           }
       }
   }
   

The bottom line with policy enforced tagging is that there is more than one way to accomplish the strategy.

Conclusion

Creating a tagging strategy is a fundamental part of a comprehensive governance and security practice on Azure. It, therefore, requires thought and planning from the IT organization to both plan and implement. Adopting a strategy to set up and enforce tagging though can have profound implications on how well your organization uses and manages Azure for all things compute.

To learn more about Azure Tagging, join me for my upcoming live webinar on January 14th, 2021:

Azure Tagging and Policy: A Match Made in the Cloud