If your organization has many Azure subscriptions, you may need a way to efficiently manage access, policies, and compliance for those subscriptions. Management groups provide a governance scope above subscriptions. You organize subscriptions into management groups, and you apply the governance conditions cascade by inheritance to all associated subscriptions.
Management groups give you enterprise-grade management at scale, no matter what type of subscriptions you might have. However, all subscriptions within a single management group must trust the same Azure Active Directory (Azure AD) tenant.
Hierarchy of management groups and subscriptions
You can build a flexible structure of management groups and subscriptions to organize your resources into a hierarchy for unified policy and access management. The following diagram shows an example of creating a hierarchy for governance using management groups.
Diagram of a root management group holding both management groups and subscriptions. Some child management groups hold management groups, some hold subscriptions, and some hold both. One of the examples in the sample hierarchy is four levels of management groups, with the child level being all subscriptions.
You can create a hierarchy that applies a policy, for example, limiting VM locations to the West US region in the management group called "Production." This policy will inherit all the Enterprise Agreement (EA) subscriptions that are descendants of that management group and will apply to all VMs under those subscriptions. This security policy cannot be altered by the resource or subscription owner, allowing for improved governance.
Important facts about management Groups
10,000 management groups can be supported in a single directory.
A management group tree can support up to six levels of depth.
o This limit doesn't include the Root level or the subscription level.
Each management group and subscription can only support one parent.
Each management group can have many children.
All subscriptions and management groups are within a single hierarchy in each directory.
Root Management Group for each directory
Each directory is given a single top-level management group called the root management group. The root management group is built into the hierarchy to have all management groups and subscriptions fold up to it. This root management group allows for global policies and Azure role assignments to be applied at the directory level. The Azure AD Global Administrator needs to initially elevate themselves to this root group's User Access Administrator role. After elevating access, the administrator can assign Azure roles to other directory users or groups to manage the hierarchy. As an administrator, you can assign your own account as the owner of the root management group.
Important facts about the root management Group
By default, the root management group's display name is Tenant root group and operates itself as a management group. The ID is the same value as the Azure Active Directory (Azure AD) tenant ID.
To change the display name, your account must be assigned the Owner or Contributor role on the root management group.
The root management group can't be moved or deleted, unlike other management groups.
All subscriptions and management groups fold up into one root management group within the directory.
o All resources in the directory fold up to the root management group for global management.
New subscriptions automatically default to the root management group when created.
All Azure customers can see the root management group, but not all customers have access to manage that root management group.
o Everyone who has access to a subscription can see the context of where that subscription is in the hierarchy.
o No one is given default access to the root management group. Azure AD Global Administrators are the only users who can elevate themselves to gain access. Once they have access to the root management group, the global administrators can assign any Azure role to other users to manage it.
Setup of Azure Management Groups
Each user who begins using management groups must complete an initial setup process. First, they need to create the root management group in the directory. After that, all existing subscriptions in the directory become subordinates of the root management group.
This process ensures that there is only one management group hierarchy within a directory. Having a single hierarchy enables administrative customers to enforce global access and policies that other customers in the directory cannot circumvent.
Any assignments made at the root level apply to the entire hierarchy, including all management groups, subscriptions, resource groups, and resources within that Microsoft Azure tenant.
Management Group Access
Management groups in Azure support Azure RBAC for all resource access and role definitions. Child resources inherit permissions in the hierarchy. All resources below the management group inherit these permissions. Any Azure role can be assigned to a management group and will be inherited down the hierarchy to the resources.
For instance, you have the option to assign the Azure role of VM Contributor to a management group. While this role doesn't have any actions on the management group itself, it will be inherited by all VMs under that management group.
Azure custom role definition and assignment
A management group can be defined as an assignable scope within an Azure custom role definition. This means that the Azure custom role can be assigned to that management group and any management group, subscription, resource group, or resource beneath it. Like any built-in role, the custom role will be inherited down the hierarchy. For details regarding the constraints associated with custom roles and management groups, refer to the "Limitations" section later in this article.
Issues with breaking the role definition and assignment hierarchy path
The scopes for role definitions can be assigned to any level within the management group hierarchy. A role definition may exist for a parent management group, while the actual role assignment exists for the child subscription. Attempting to separate the assignment from its definition will result in an error due to the relationship between the two items.
For example, if a custom role is defined on the sandbox management group and then assigned to two sandbox subscriptions, moving one of those subscriptions to be a child of the Corp management group will disrupt the path from subscription role assignment to the role definition for the sandbox management group. This action will trigger an error that indicates the move is not permitted because it will break this relationship.
To resolve this situation, you have several options available:
- Remove the role assignment from the subscription before moving the subscription to a new parent management group.
- Add the subscription to the assignable scope of the role definition.
- Modify the assignable scope within the role definition. For instance, you could update the assignable scopes from the sandbox management group to the root management group, enabling both branches of the hierarchy to access the definition.
- Create another custom role in the other branch. However, this will also require you to change the role on the subscription.
Limitations
There are limitations when using custom roles in management groups.
You can only define one management group in the assignable scopes of a new role. This limitation reduces the number of situations where role definitions and role assignments are disconnected. This happens when a subscription or management group with a role assignment moves to a different parent that doesn't have the role definition.
Resource provider data plane actions aren't defined in management group custom roles. This restriction is in place as there's a latency issue with updating the data plane resource providers. This latency issue is being worked on, and these actions will be disabled from the role definition to reduce any risks.
The Azure Resource Manager doesn't validate the management group's existence in the role definition's assignable scope. If a typo or an incorrect management group ID is listed, the role definition is still created.
Role assignment of a role with dataActions isn't supported. Create the role assignment at the subscription scope instead.
Moving management groups and subscriptions
Three rules need to be evaluated as true to move a management group or subscription to be a child of another management group.
If you're doing the move action, you need:
Management group write and role assignment writes permissions on the child subscription or management group.
o Built-in role example: Owner
Management group writes access to the target parent management group.
o Built-in role example: Owner, Contributor, Management Group Contributor
Management group writes access to the existing parent management group.
o Built-in role example: Owner, Contributor, Management Group Contributor
Auditing Management Groups by using activity logs
Azure Monitor activity logs support management groups. All events related to a management group can be queried in one central location along with other Azure resources. For instance, all changes made to role assignments or policy assignments for a specific management group can be viewed.
When querying on management groups outside the Azure portal, the target scope for management groups has the following appearance: "/providers/Microsoft.Management/managementGroups/{management-group-id}".
Comments