Azure Management Group

What are Azure Management Groups?

Azure Management Groups are logical containers that help you organize and manage your Azure resources at scale. These groups enable the application of policies and access controls to multiple subscriptions simultaneously, ensuring uniform governance and compliance across your organization.

Azure Management Groups simplifies administration tasks and enhances overall efficiency. The key features of Azure Management Groups are:

• Hierarchical Organization:
  Establishes a structured hierarchy for managing Azure resources, allowing for streamlined administration.
• Policy Enforcement:
  Enables the consistent application of policies and access controls across multiple subscriptions, ensuring compliance with organizational standards.
• Role-Based Access Control (RBAC):
  Facilitates precise control over who can perform specific actions within the management group, enhancing security and minimizing unauthorized changes.
• Scalable and Adaptable:
  Adapts to the evolving needs of an organization, allowing for easy addition or movement of subscriptions and resources within the hierarchy.
• Centralized Visibility:
  Provides a unified view of resources across multiple subscriptions, simplifying monitoring, tracking, and troubleshooting.
• Customizable Roles:
  Allows the creation of custom roles to align access permissions with specific organizational roles and responsibilities.
• Audit Trail and Activity Logs:
  Records detailed activity logs for auditing purposes, ensuring transparency, compliance, and security.
• Resource Group Inheritance:
  Allows resources within a subscription to inherit policies and access controls from the management group, reducing the need for manual configuration.
• Cost Management and Reporting:
  Facilitates effective cost allocation and reporting by providing a consolidated view of spending across subscriptions within a management group.

Hierarchy of Management Groups and Subscriptions

Azure Management Groups use a hierarchical structure to organize and manage resources efficiently.

1. At the top lies the Root Management Group, which serves as the parent for all subsequent management groups and subscriptions.
2. At the next levels, you can establish child management groups, each capable of inheriting policies and access controls from its parent.
3. Subscriptions are then assigned to these management groups, allowing for a structured and organized approach to resource management.

Example:

Consider a multinational corporation, Corporation, with a global presence.

1. At the root level, this Corporation establishes the Global Management Group as the Root Management Group. This serves as the foundation for the entire Azure environment.
2. Under this, regional management groups are created - North America, Europe, and Asia-Pacific. Each of these regional groups can have its specific policies and access controls that are inherited from the global level.
3. Subscriptions are then associated with these regional management groups based on the projects or teams operating in those regions. For instance, the North American management group may have subscriptions for the Sales, Marketing, and Development teams operating in that region.

We can also provide access for multiple subscriptions to a user using Azure Management Groups.

Root Management Group for Each Directory

Within an Azure directory, a Root Management Group acts as the highest level of the hierarchy. It is used for the organization of resources and the establishment of policies and access controls that will be applied to child management groups and subscriptions. The User Access Administrator role is needed to assign Azure roles to other directory users or groups.

Here are some key points to note about the root management group:

• By default, the root management group is referred to as the Tenant root group and functions as a management group, sharing the same ID as the Azure Active Directory tenant ID.
• Altering the display name requires an account with Owner or Contributor role privileges on the root management group.
• Unlike other management groups, the root management group is immovable and cannot be deleted.
• All subscriptions and management groups ultimately converge into this singular root management group within the directory.
  • This includes all resources in the directory, establishing a framework for global management.
  • Any new subscriptions automatically default to the root management group upon creation.
• While all Azure customers can view the root management group, not all have the authorization to manage it.
• Any individual with access to a subscription can see their place within the hierarchy. - Only Azure AD Global Administrators can allocate any Azure role to other users for management purposes.

Initial Setup of Management Groups

Here are the steps to create management groups:

1. Sign In to Azure Portal.
2. On the left-hand side, locate and click on Management Groups in the Azure portal menu.
3. In the Management Groups page, click on the Add management group button.

This will prompt you to enter a name and optional description for the new management group.

If you want the new management group to be a child of an existing group, use the Add existing button and select the parent group from the drop-down menu. Otherwise, it will default to the root management group.

Begin by creating a Root Management Group within your Azure directory. From there, you can establish child management groups, if needed, and assign subscriptions accordingly.

Management Group Access

Azure offers robust role-based access control (RBAC) mechanisms, allowing you to grant specific permissions to users or groups at various levels within the management group hierarchy. This ensures that only authorized personnel can make changes or alterations to resources within the designated groups.

Here is a table summarizing Azure role permissions for management group access along with a brief description of the use case for each role:

*MG Contributor and MG Reader roles are management group-specific and provide access and permissions limited to management groups.

Let us explore the use cases for each Azure role in the context of management group access:

Owner:

• Full control over management groups and resources.
• Can create, rename, move, delete, assign access, assign policies, and read.

Contributor:

• Can make changes and assign policies.
• Has the authority to create, rename, move, and delete resources within management groups.

MG Contributor:

• Management group-specific contributor.
• Granted permissions to create, rename, move, and delete resources within a specific management group.

Reader:

• View-only access to resources and policies.
• Cannot make changes, but can view all resources and associated policies within management groups.

MG Reader:

• View-only access within management groups.
• Limited to viewing resources and policies within a specific management group.

Resource Policy Contributor:

• Can assign policies to resources.
• Has the authority to define and apply policies to specific resources.

User Access Administrator:

• Manage access to resources and management groups.
• Can grant or revoke access permissions to users and groups for resources within management groups.

Azure Custom Role Definition and Assignment

Azure provides the flexibility to define custom roles to suit your specific organizational requirements. This feature allows for fine-grained control and these roles can be assigned at various levels in the hierarchy, including management groups, subscriptions, resource groups, and individual resources.

Example:

Consider an organization that needs a custom role to manage policy assignments at the management group level. This custom role would have permissions for actions like creating, reading, and deleting policy assignments within the management group.

To define this role, the full path of the management group needs to be specified, using the ID rather than the display name to avoid common errors. The custom role JSON might look like this:

Explanation:

• The Name field specifies the name of the custom role

• The ID is a unique identifier associated with the custom role.

• The IsCustom is a boolean value that indicates whether the role is custom or built-in.

• The Description provides a summary of the purpose or function of the custom role.

• Actions define the specific operations or tasks that the role is permitted to perform. Each action is represented as a string, typically in the format of ResourceProvider/Action, indicating the type of action and the associated resource provider.

• The AssignableScopes field specifies the scope or location where the custom role can be assigned. It typically includes the full path to the management group, subscription, resource group, or resource where the role can be applied.

• The DataActions and NotDataActions fields allow for the specification of data plane actions, which are permitted.

However, it's important to be aware of certain limitations when working with custom roles in management groups:

1. A new role can only have one management group in its assignable scopes.
2. Resource provider data plane actions cannot be defined in custom roles for management groups. This is due to a latency issue with updating data plane resource providers.
3. Azure Resource Manager doesn't validate the existence of a management group in the role definition's assignable scope. This means that typos or incorrect IDs may not be immediately flagged.

Moving Management Groups and Subscriptions

Azure facilitates seamless movement of management groups and subscriptions, allowing you to adjust the hierarchy to match shifting priorities, but requires careful consideration of permissions and roles.

To execute the move action, the initiating user should have the following privileges:

• Authorization to Write to Management Groups and Assign Roles, which includes both the role assignment write and the management group writes permissions on either the child subscription or management group.
• Authority to Write to the current or target parent management group, for which the user must have management group write access to the intended parent management group.

The only exception is for the root management group, as it serves as the default landing spot for new entities, special permissions aren't needed to move an item into it.

The limitations imposed on move targets, when the current management group is used for inheriting the Owner role for a subscription are:

• The subscription can only be moved to another management group where the user has the Owner role.
• Moving it to a management group where the user is a Contributor isn't allowed, as it would result in a loss of ownership.
• If the Owner role is directly assigned to the user for the subscription (not inherited), they can move it to any management group where they are assigned the Contributor** role.

Audit Management Groups Using Activity Logs

Maintaining a record of activities within your Azure Management Groups is essential for compliance and security purposes. Azure Activity Logs offer detailed insights into all operations performed within your environment, enabling you to track changes, diagnose issues, and ensure adherence to policies and regulations.

Challenges and Solutions

Complex Hierarchy Management

In large organizations, managing a complex hierarchy of management groups can become challenging, leading to potential misconfigurations or resource mismanagement.

Solution:

Implement a clear naming convention and organizational structure. Regularly audit and refine the hierarchy to ensure it aligns with the evolving needs of the organization.

Role Assignment Conflicts

Assigning roles within a nested hierarchy can lead to conflicts or overlapping permissions, potentially resulting in unauthorized access.

Solution:

Leverage Azure's Role-Based Access Control (RBAC) carefully. Use custom roles to fine-tune permissions and avoid over-assigning broad roles.

Security Considerations

• Implementing precise RBAC ensures that users have only the necessary permissions to perform their tasks, reducing the risk of unauthorized access or modifications.
• Restricting data plane actions is critical for safeguarding sensitive information. Unauthorized data access or modification can lead to compliance breaches or security incidents.
• Conducting periodic security audits helps identify and rectify potential vulnerabilities or misconfigurations within the Management Group hierarchy.