Azure Subscription Governance – Controlling resources with Tags, Policies, and Locks

  • Article

Greetings readers!

Following up on my last post, today I will talk about how you can take control of resources in your subscription by utilizing resources offered by Azure. Why is that important? Consider the following scenarios:

  • Unplanned deployment of resources to subscriptions preventing identification, tracking, and effective automation/billing
  • Deployment of resources that violate policies and regulations
  • Accidental deletion of modification of critical resources that have the potential to cause widespread outages or loss of data

Whether you are a DevOps engineer, Cybersecurity analyst, CIO or CISO, you certainly do not want to stand out for the wrong reasons. Read on to find out how you can leverage Azure features to control resources in your subscriptions.

1 – Tags

A tag is an arbitrary key/value pair that can be assigned to a resource group or a particular resource. Tags are very powerful and play a key role in automation, management, and billing of Azure resources.

From an automation/management perspective, once tags have been assigned, resources can be collectively targeted.

Scenario: A group of DEV servers needs to be shut down every day at 6:00 PM.

  • Add a tag with a key called "shutdown" and give it the value of "1800":
  • Use automation to target the VMs based on tags:

Here are some other common use cases for tags:

  • Cost Center
  • Environment: Dev/UAT/Prod
  • Project
  • Owner: Person/Group
  • Application: SCCM/Exchange/AD
  • Importance: Low/Medium/Critical

From a billing perspective, it is important to know that tag is one of the fields listed by the Azure Billing API. Enterprise customers often use tags as criteria to build insightful billing reports using tools such as PowerBI and Azure Cost Management.

Scenario: A customer wants to find out how much a specific application/workload costs.

By tagging all resources (storage account, VM's, Web Apps, etc.) that belong to that particular app/workload with application information, this customer could leverage the billing report options mentioned above to effectively calculate the cost of a workload.

Read more about tags here.

2 – Azure Policies

Azure policies give customers the ability to define how resources are deployed to a subscription and can help ensure compliance requirements are met. Policies work hand in hand with RBAC, but they perform different functions, while RBAC focuses on who can manage resources, policies focus on how resources should be deployed/configured. Policies are inherited by child resources and can be assigned at the following levels: management groups, subscription, and resource group.

Scenario: A customer must abide by regulations that demand that data must reside in their country.

  • Create a policy that defines allowed locations and assign it to the subscription:
  • Once assigned, policies will be enforced and will prevent anyone (including subscription admins) from creating/modifying resources that would cause violations. Notice what happens when I try to create a resource in a location that violates the resource policy:

Here are some other common use cases for policies:

  • Allowed virtual machine SKUs – Helps control cost by restricting VM sizes
  • Enforce tag and its value – Ensures resources are always deployed with the appropriate tag for consistency/compliance purposes
  • Allowed/Not allowed resource types – Allows or prevents the creation of specific resource types. Example: Define a policy that prevents the creation of network gateways to prevent administrators from potentially exposing the environment by inadvertently creating a rogue VPN connection

Some policies can be created for audit purposes only and would not enforce settings or prevent resources from being created/modified. Example: Audit VMs that do not have managed disks. Those policies can then be audited using policy compliance. For a detailed list of policy templates, check out Templates for Azure Policy.

Read more about resource policies here.

3 – Resource Locks

Resource locks is a feature that prevents resources from being deleted or modified inadvertently. Locks are inherited by child resources and can be applied at the following levels: subscription, resource group or resource. There are two types of locks:

Delete – Prevents any user from deleting resources, but still allows modifications by authorized users

ReadOnly – Prevents any user from deleting or modifying resources, but still allows authorized users to read the resource

Scenario: A customer wants to protect their domain controllers from accidental deletion.

  • Place a "Delete" lock on the domain controller VM:
  • Once the lock has been applied, even subscription administrators will be prevented from deleting those resources. Notice what happens when I try to delete a VM protected by a lock:

 

In order to modify such resources, the administrator needs to remove the lock first.

Locks should be in place to protect any critical workload, however, core infrastructure components such as domain controllers, DNS servers, network appliances, VPN gateways, etc., should definitely have locks, since the accidental deletion or modification of those resources could have a massive impact. A common practice I have seen with customers out there is the creation of a dedicated subscription for infrastructure resources with resource groups containing the critical infra components and locks applied at the RG level.

Read more about locks here.

4 – Managed Groups

This feature is currently in preview, therefore, I will only briefly mention it here as it is shaping up to be yet another important tool to have under your belt when it comes to Azure resource management.

The premise of management groups is to provide a scope level that is above subscriptions. Consider the scenario above where we created a policy to restrict the deployment of resources to a specific location. This is an easy task if you have one or few subscriptions, however, if you need to apply the same policy to dozens of subscriptions, this is where management groups come in handy. The same policy could be applied to a management group that, in turn, is inherited by multiple subscriptions, the same applies to RBACs and this will greatly simplify the management of resources across multiple subscriptions.

Read more about management groups here.

Summary

Among all the features discussed above, customers have the tools they need to make sure they have full control of the resources deployed to their subscriptions. It is important to highlight that there is not a one size fits all or best practices strategy when it comes to the use of these features, however, I consider all of them equally important in subscriptions of any size. Hopefully, the examples given here will help you make an informed decision.