- Use Azure Bastion as a jump host for RDP and SSH - Tue, Apr 18 2023
- Azure Virtual Desktop: Getting started - Fri, Apr 14 2023
- Understanding Azure service accounts - Fri, Mar 31 2023
The industry analyst Gartner defines IT governance (ITG) as the processes that ensure the effective and efficient use of IT in enabling an organization to achieve its goals.
With respect to Microsoft Azure, you may have issues getting your team on the same page with ensuring:
- Resources are created only in authorized regions
- Virtual machines (VMs) use only approved instance sizes
- Resources are always linked to proper taxonomic tags
The good news is that Azure Policy allows you to create and enforce this type of operational compliance. The bad news was that before management groups, Azure administrators needed to redefine and reapply Azure Policy to each subscription individually. Not cool!
I will cover Azure Policy in a separate 4sysops blog post; today I want to teach you how to create and control Azure management groups. Let's get right to work!
Understanding management groups
Management groups are container objects that encompass one or more Azure subscriptions; that's literally all there is to them. All subscriptions within a management group receive any Azure Policy or role-based access control (RBAC) entries by simple inheritance.
Note that management groups apply not only to the Pay-As-You-Go (PAYG) offer, but also to enterprise agreement (EA) customers. This is good news because if you are an EA customer, you almost certainly juggle multiple Azure subscriptions in your business.
As you see in the following Visio diagram I made for you, you can nest management groups (the "keep it simple" rule applies here as it does to any inheritance-based administration scheme) to suit your organizational requirements.
A representative Azure management group hierarchy
The Tenant Root Group is a predefined management group; you can modify but not delete it. By default, any RBAC or Azure Policy you define at this level cascades by inheritance to administrator-defined management groups.
As you can do with, say, NTFS permissions, you can override inheritance by setting explicit Azure or RBAC policy at the child management group.
Security-related prerequisite
Presumably for security reasons, you must elevate your user account access to modify the root management group. Log into the Azure portal with your Azure Active Directory (AD) global administrator account. Then navigate to the Properties blade and set the Global admin can manage Azure Subscriptions and Management Groups field to Yes. Be careful with this ultra-powerful setting! You may want to enable this option only while you work with the root management group.
Elevating your Azure AD permissions
You can then use the Access control (IAM) blade to assign RBAC roles to distribute management group administrative authority to child management groups. The two built-in RBAC roles are:
- Management Group Contributor
- Management Group Reader
Creating management groups
In the Azure portal, visit the Management groups blade and click Add management group to get started. Next, fill in the Add management group section, specifying the following metadata:
- Management group ID: This is the Azure AD-wide unique identifier for your management group—you provide the name
- Management group display name: Self-explanatory 😉
Creating a new management group
You should now see your new management group show up in the list. Let me call out a few salient points:
- The My Role column shows your account as an RBAC Owner of the resource, which should make sense because you created the management group
- The Tenant Root Group Settings blade is hidden behind the small (details) hyperlink
In fact, you need to click that small (details) link to manage your new management group's settings as well. That seems like an odd user interface design choice, but nobody at Microsoft asked me for my opinion on that.
Management group Properties blade
Adding subscriptions to a management group
As you can observe in my previous screenshot, click Add subscription to populate your new management group with an Azure subscription.
Likewise, you can add a new or preexisting management group as a child of the current one by clicking Add management group from the toolbar. I need to stress you should be careful as you make these assignments because any subscriptions or child management groups you add to the current one will potentially change Azure Policy and RBAC role assignments.
In the next screenshot, you see that I added a child management group and three subscriptions to my management group.
A populated Azure management group
Apply governance to a management group
You can apply both RBAC permissions as well as Azure Policy definitions to your management group from its Settings blade. Please understand that RBAC permissions authorize Azure users to perform operations on Azure resources. For instance, membership in the Virtual Machine Contributors role gives users the ability to deploy and manage VMs.
RBAC permissions at the management group level
By contrast, Azure Policy manages the options those authorized users can reach on those resources. For example, the built-in policy Audit VMs that do not use managed disks flags any such VMs as non-compliant and notifies your designated administrative staff of the issue.
Other built-in policies, like Allowed locations, actually block deployment for resources assigned to non-compliant Azure regions.
Subscribe to 4sysops newsletter!
Defining an Azure Policy using a built in definition
Wrap-up
Many of my Azure consulting clients were overjoyed when Microsoft released management groups. For businesses that have more than one subscription, management groups can greatly simplify how you govern your cloud infrastructure.
