Enforcing Speed and Control With Management Groups and Azure Blueprints
In my previous post, Enforcing Speed and Control Using Azure Policy, I described Azure Policy as a control service in Azure that enables you to create, assign, and manage polices. It also keeps resources compliant with corporate standards, industry/government regulations, and service level agreements.
In this blog post, I will introduce you to Management Groups and Azure Blueprints, with regards to enforcing speed and control in Azure.
Effectively implementing these steps would provide a suitable platform to enable you to proactively review governance effectiveness and identify areas or segments to improve upon.
Steps to Achieve Speed and Control in Azure
Management Groups
The role of Management Groups
Management groups are needed for unified policy, access management, and subscriptions.
How do they achieve this?
- Management groups act as containers for subscriptions.
- Policies and access management can be scoped around management groups.
- Policies applied to management groups are inherited by all subscriptions, resource groups, and resources within that management group.
- Azure RBAC roles have no action on the management group, but are inherited by all child resources.
Example of a Management Group Hierarchy Tree
It’s important to know that the Root Management Group is built into the hierarchy, and all management groups and subscriptions fold up into it. It cannot be moved or deleted, unlike other management groups.
Creating Management Groups
Before creating Management Groups, you need to understand the difference between managing resource access through Azure Active Directory and Azure Role Based Access Control.
Azure Active Directory(AAD) is Microsoft’s cloud-based identity access management service or identity-as-a-service. It helps your employees sign-in to:
- External resources, such as Microsoft Office 365, the Azure Portal, and other SaaS applications.
- Internal resources, such as apps in your corporate network and intranet, along with any cloud apps developed by your own organization.
AAD does not grant access to Azure Resources (VMs, Storage Accounts, Management Groups, etc). Azure AD resources and Azure resources are secured independently from one another.
Conversely, Azure RBAC Assignments are used to secure Azure resources, but do not grant access to AAD resources.
The only way you can use your user identity in AAD to gain access to Azure resources is by:
- Upgrading your role to Global Administrator in AAD.
- When you elevate your role, you are eligible to be assigned the User Access Administrator role in Azure at the root scope (/). This allows you to -
- view all resources
- assign access in any subscription or management group in the directory
Follow these steps to elevate access for the Global Administrator role to the User Access Administrator role using the Azure Portal:
When you set the toggle to Yes, you are assigned the User Access Administrator role in Azure RBAC at the root scope (/). This grants you permission to assign roles in all Azure subscriptions and management groups associated with this Azure AD directory.
Note: This toggle is only available to users who are assigned the Global Administrator role in Azure AD.
In this example, the user "Chris" isn't assigned the Global Administrator role in AAD. Therefore, he cannot be upgraded to a User Access Administrator role.
Once you sign-out and sign-in again, your dashboard should look similar to this:
Once you are done, it is recommended that you turn the toggle off.
You can create the Management Group by using:
- Azure Portal
- PowerShell
- Azure CLI
Note: Currently, you can not use Resource Manager templates to create Management Groups.
For example:
1.) Create a Management Group Calle "FinanceGroup" with a display name of "Finance" using the Azure portal.
Creating a Management Group
2.) Move all your existing subscriptions into the Finance management group.
Moving subscriptions into a Management Group
3.) Apply an initiative that includes a number of policies that control and deploy specific VM extensions to support audit requirements.
Applying policies to a Management Group's subscriptions
Using Azure PowerShell, here's how I define a similar Management Group:
The GroupName is a unique identifier being created. This ID is used by other commands to reference this group and it cannot be changed later.
If you want the Management Group to show a different name within the Azure portal, add the DisplayName parameter.
The new Management Group is created under the root management group.
To specify a different Management Group as the parent, use the Parentld parameter. To get the parent ID, I query all Management Groups using the Get command.
The next step is to create a parent ID variable that will store the parent ID of the higher level Management Group.
Lastly, I create the new sub-Management Group and, using the parent ID, assign it as a sub-group to the Finance Management Group.
Azure BluePrints
Azure Blueprints is intended to assist with environment setup. Such environments often include:
- Azure Resource Groups
- Role Assignments
- Different Policies
- Resource Manager Template Deployments
Creating Azure BluePrints
Most resources in Azure have a natural lifecycle. Blueprints in Azure BluePrints are no different, as they are created and then deployed. When they are no longer needed, they are deleted. As such, Azure BluePrints supports typical lifecycle operations and even builds upon them. Azure BluePrints provides support for continuous integration and continuous deployment pipelines for companies that manage infrastructure as code.
The typical Azure BluePrint lifecycle consists of:
- Creation of a blueprint
- Publishing of the blueprint
- Creating or editing a new version of the blueprint
- Publishing a new version of the blueprint
- Deletion of a specific version of the blueprint
- Deleting the blueprint altogether
Azure BluePrints are made up of artifacts. Resources supported as artifacts include -
- policy assignments
- role assignments
- Azure Resource Manager templates
- Resource Groups
Policy Assignments provide a means for applying policy to a subscription to which a blueprint is assigned. The policy must be within the scope of the blueprint containing the policy.
Azure BluePrints can pass parameters to policies, initiatives, or Resource Manager templates. The author must decide on a value to define the blueprint parameter when creating the assignment, or allow the value of the parameter to be specified when the blueprint is being assigned to a subscription.
Role Assignments provide a means for adding existing users or groups to a built-in role. This is done to ensure the correct people have the proper access to Azure resources.
Azure Resource Group Templates are useful when designing complex environments, such as those managed with Azure Automation State Configuration. Leveraging templates makes standardization of such environments far easier than building them individually.
Resource Groups allow an administrator to organize resources and to structure them as needed. They also serve as scope limiters for policy assignment artifacts, role assignment artifacts, and Azure Resource Manager templates.
To get you started with deploying Azure BluePrints, Microsoft provides you with 5 sample blueprints you can customize to suit your cloud environment. My favorite is the ISO 27001: Shared Services blueprint. It deploys and configures Azure Infrastructure and Policies mapped to specific ISO controls.
The image below provides an overview of the breadth and depth of the ISO 27001 accreditation process.
The Shared Services sample consists of more than 50 Policy Assignments and Resource Manager Templates you can configure to meet ISO 27001 requirements.
With the Shared Services template, you could easily verify compliance in less than one hour!
In my next post, I'll give you step-by-step advice on how to utilize Resource Graph and Azure Monitor, as well as how to Autoscale.
Learn more about Microsoft Azure with your All Access Pass
{{cta('4aa9cc41-e2e5-422e-a6d6-e2b6c35751a6')}}
