In the presence of environments with a high number of Azure subscriptions it is necessary to have a different level of abstraction in order to effectively manage the accesses, policies and compliance. To this end, Azure Management Groups have been introduced, that allow to organize different subscriptions into logical containers, on which define, implement and verify government policies needed. This article examines in detail the concepts and shows directions to better organize the Azure resources in order to facilitate the process of governance.
To effectively organize Azure resources is fundamental to define a hierarchy of management groups and subscriptions to which you can apply Azure Policy, the service that allows you to create, assign and manage audit policy. The use of the Management Group is also helpful to effectively manage the assignment of permissions via role-based access control (RBAC), for administrative delegation.
Each resource Azure is contained within a specific Azure Subscription, which it is associated to a single Azure Active Directory tenant, and inherits the permissions set at that level.
At the moment, a constraint to consider, is that a Management Group can contain multiple subscriptions as long as the same form part of the same Azure Active Directory tenant . In other words,, the Management Groups reside within a tenant and cannot contain subscriptions of different tenants. The security principal that can be used on management group can come only by the tenant for the management group.
Azure resources belonging to a subscription are contained in Resource Groups. The resource groups are containers of resources that, for administrative purposes, allow to obtain the following benefits:
- They facilitate administrative delegation because resources contained inherit permissions to the resource group level.
- On the resource group you can set tags, although these are not automatically inherited by the resources, but it is necessary to foresee specific mechanisms if they are deemed necessary.
The Azure Policy can be assigned to a subscription or Management Group level and can be defined exceptions for Resource Group. In this regard it is recommended whenever possible, to organize policies in "initiative" and assign them to Management Group level.
The root Management Group is the top level and contains all configured Management Groups and various Azure subscriptions. Root Management Group cannot be removed or moved. The structure can be created with up to six levels deep, without considering the Root level and the level of subscription. Each Management Group can have more children, but supports only one parent for each Management Group and for each subscription.
In the absence of specific requirements, Microsoft recommends that you split production environments than those "DevTest", creating two tiers of management groups. The management group root by default will have fundamental policies, such as those relating to security. On the remaining Management Groups are associated specific policies. The hierarchy of Management Groups provide a model for which the policies that are defined at higher levels in the hierarchy cannot be overwritten by lower levels.
This approach enables you to manage complex Azure environments, who see the presence of more subscriptions. in a more simple and flexible way, for the following reasons:
- The concept of inheritance allows with a single association to apply the desired controls and the assignment of roles on different subscriptions.
- It has a centralized management.
- You may include additional subscription in the hierarchy, with the knowledge that will adhere to established policies and who will have the assignment of desired roles.
The goverance processes by which an organization can ensure an effective and efficient use of IT resources, in order to achieve their goals, cannot refrain from adopting a model that allows to organize effectively the Azure resources. The use of Management Groups, in environments with a significant number of subscriptions, is essential to meet the common need of standardize, and in some cases impose, how you configure the different resources in the cloud.