Notes on implementing Azure management groups

Notes on implementing Azure management groups

Using Azure management groups can bestow a ton on benefits in terms of consistent setup, securing and managing Azure subscriptions. However, setting up Azure management groups and using those management groups appropriately is more involved. Below are some notes from our experience that we hope could be of benefit.

Azure Management Groups – Visual

Retrofitting management groups:

Unless you are starting with Azure afresh, you do not have the luxury of designing your management group hierarchy from scratch. You have to set up your management groups so that it supports your Subscription usage pattern and does not break existing functionality. You could ask the Cloud Architecture team in your enterprise to explain the design philosophy behind the creation of new subscriptions in your enterprise tenant. But chances are that there might be more exceptions to the rule. So a few questions can be posed of your subscriptions, answering them might help you arrive at a usable Management group hierarchy:

  1. What kinds of workloads are being set up in a given subscription?
  2. What environments (Dev, QA, Prod etc..) do these workloads belong to?
  3. Which subsidiaries/departments/teams own these workloads?
  4. Is there a recognizable pattern of Azure region usage?
  5. Is there a consistent naming convention that is being employed? Can you glean this from the data?
  6. What security rules are being applied at these workloads?
  7. What are the various inbuilt / custom RBAC roles that are being used?
  8. Finally and importantly, is there a good resource group/resource tagging strategy that has been employed? If yes, this can help with categorization immensely.

Now put the answers to these questions together and attempt to cluster similar ones together. If you can find these clusters and super-clusters of these clusters, you have a management group hierarchy that is self-evident.

ARM Policies at management groups:

Management groups are a convenient place for defining Azure ARM policies. Except in a few situations, this is also the place where those ARM policies should be applied. This is very convenient and allows your organization to set up Azure environments with consistent security policies. When permissioned with Security Reader role at the Management group scope, concerned parties can view security control violations at that level of the hierarchy.

As an example, there could be separate individuals concerned with the security of your Finance and HR departments. If there were separate Management groups for each of these two units, assigning those responsible individuals Security Reader role at the respective management groups will let them see security information that concerns them alone.

The ARM policy violations can be seen either in Azure Policy blade or in Azure Security Center.

RBAC at management groups:

Another advantage to using Azure management groups is that you can centralize your RBAC strategy. You could apply your RBAC roles at the Management group scope so that you have one central place that you could go to instead of fiddling around with every subscription. However, there is a complication if you are using custom RBAC roles. As of this day, it is not possible to define a custom RBAC roles at a Management group. It has to be defined at a subscription. You can then use that role definition ID to assign that role at other Management groups/subscriptions. However, this is likely to change in the future and you would be able to store custom RBAC role definitions at the Management group.

It is, however, unlikely that 100% of your RBAC needs will be met here. All your centrally controlled and required roles should take the Management group route. However, you will still need individual teams/users to be given access much more granularly. Here is where you will have to resort to some automation.

Use Azure Blueprints:

Azure management groups provide a great way to centralize the application of your RBAC roles and ARM policies. However, if you have a requirement to apply policies and roles at a specific subscription, employ Azure Blueprints.

Azure Blueprints lets you centralize governance needs (ARM Policies, RBAC Roles, Default Resources etc…). You could define them in one place so that they can then be consistently applied across your subscriptions.

As an example, you might create a Blueprint that defines Policies / RBAC that have to be applied against any Production resources. You will then run that Blueprint against a newly minted/existing Production subscription and bring it to under your management group hierarchy and ensure ongoing compliance with enterprise standards for resources that might be created/exist under that subscription.

Adopt DevOps practices:

Yet another reason to use Azure Blueprints is that it ushers in the DevOps discipline to maintaining and managing your Azure environments. Typically you should maintain a git repository where Blueprints shall be stored. DEV / UAT environments must be created. Each environment must mirror your management group hierarchy. Every change to the Azure Blueprint must undergo testing in these environments against test subscriptions before its deployed and used in Production where your actual enterprise subscriptions reside.

This is super important because any mistakes made at the Management group hierarchy will have cascading effects that might affect the workloads ultimately that reside in that hierarchy.

Permissioning Automation Accounts:

Management groups also simplify identity needs for your automation accounts. Ideally, Azure automation must be performed using a service that supports Azure Managed Service Identity (MSI). This MSI must be given required privileges to perform the automation tasks at the relevant Management group. This makes it easier for the automation service to work across multiple subscriptions to accomplish the objective. However, if you cannot use an MSI, you could use an SPN instead and use additional guardrails to ensure that the secret does not leak out. This can be accomplished by storing the secret in the Key Vault and permissioning the service to retrieve the secret securely.

As you can see there is a lot that goes into using Management groups appropriately in your enterprise than it meets the eye. AzCop is a solution offering that we have created to help navigate tricky waters such as this. Reach out to us and let us begin the conversation towards ensuring a secure and well governed Azure.

Share this post

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.