Management Groups

Architect your Cloud with Azure Blueprints

by

Today as a part of the Azure Governance and management announcements at Microsoft Ignite 2018 Azure Blueprints Public Preview was announced. Azure Blueprints are a core part of the cloud governance and management story. They go hand and hand with Management Groups and will take the enterprise management story of Azure up a level. In this blog post I will take a deep dive into Azure Blueprints explaining what they are and give an example of how they can be used.

NOTE: This is a long blog post so I have also published this content as a whitepaper. The whitepaper PDF can be downloaded here.

BLUEPRINTS OVERVIEW

At a high-level Azure Blueprints help you meet organizational cloud standards, patterns, and requirements through governed subscriptions enabled and enforced by the grouping of artifacts like ARM templates, Azure policies, RBAC role assignments, and resource groups within a Blueprint.

Blueprints can be used to lay a cloud foundation, as cloud patterns, and group cloud governance frameworks. Blueprints are a one-click solution for deploying a cloud foundation, pattern, or governance framework to an Azure subscription. Think of an Azure Blueprint as re-usable design parameters for cloud that can be shared and used across an enterprise.

Azure architects typically map out and plan the many aspects of a cloud foundation for an organization such as access management, networking, storage, policy, security/compliance, naming conventions, tagging, monitoring, backup, locations, and more. Now Azure architects can step this designing a step further build these designs as Azure Blueprints and then apply them to subscriptions. The Blueprints give architects a way to orchestrate the deployment of grouped components to speed up the development and provisioning of new Azure environments ensuring they are meeting organizational compliance.

BLUEPRINTS ARE NOT AZURE POLICY

Azure policy is a service targeted to resource properties that exists or when being deployed with allow or explicit deny policies. It is used to ensure resources in an Azure subscription adhere to requirements and standards of an organization.

Azure policies can exist on their own or be a part of an Azure Blueprint. Blueprints do not replace Policy they are one of the Artifact types that make up a Blueprint.

THE MAKEUP OF A BLUEPRINT

Definition

A Blueprint consists of a Definition. The Definition is the design of what should be deployed it consists of the name of the Blueprint, the description and the Definition location. The Definition Location is the place in the Management Group hierarchy where this Blueprint Definition will be stored and determines the level assignment is allowed at. Currently you must have Contributor access to a Management Group to be able to save a Blueprint Definition to it. A Blueprint can be assigned at or below the Management Group it has set in its Definition Location. Here is a diagram to visualize Blueprint Assignment in relation to Management Group hierarchy:

Azure Blueprint Assignment

Artifacts

The Definition is where Blueprint Artifacts are added. As of right now the following is a list of the Artifact types:

  • Policy Assignments – Lets you add an Azure Policy. This can be a built-in or custom policy.
  • Role Assignments – Lets you add a user, app, or group and set the role. Only built-in roles are currently supported.
  • Azure Resource Manager templates – Lets you add an ARM Template. This does not let you import a parameters file. It does let you pre-set the parameters or set the parameters during assignment of the Blueprint.
  • Resource Groups – Lets you add a Resource Group to be created as a part of this Blueprint.

In my opinion the ARM Template artifact is the most impactful of the Blueprint artifact types because you can define such a variety of resources here. It opens the Blueprint to the power of ARM in general. Hopefully in the future we will see more scripting capability or the ability to load PowerShell scripts, runbooks, and or Functions.

There are two levels in the Artifacts. The first level is Subscription. The second level is Resource Group. Resource Group artifacts cannot be added to a Resource Group artifact. A Resource Group artifact can be created in a Subscription. An ARM Template artifact can only be created in a Resource Group artifact. A Policy Assignments or Role Assignments can be created at either the Subscription or Resource Group level.

Assignment

After a Blueprint has been built it needs to be applied. Applying a Blueprint is known as Blueprint assignment. The assignment is essentially the “what was deployed” for a Blueprint. This is how the artifacts are pushed out to Azure and used to track and audit deployments in Azure.

Sequencing

When the assignment of a Blueprint is processed the default order of resource creation is:

  • Role assignment artifacts at the Subscription level
  • Policy assignment artifacts at the Subscription level
  • Azure Resource Manager template artifacts at the Subscription level
  • Resource group artifacts and its child artifacts (role assignment, policy assignment, ARM Templates) at the Resource Group level

When a blueprint includes multiple Azure Resource Manager templates there may be a need to customize the sequencing order in which the Blueprint will deploy artifacts during assignment. You customize the artifact deployment sequence by deploying a Blueprint from an ARM Template declaring a dependency within it or declaring a dependency within an ARM Template artifact in the Blueprint. You declare a dependency using the dependsOn property in JSON. This essentially is a string array of artifact names.

Resource Locking

In cloud environments consistency is key. Naturally Azure Blueprints can also leverage resource locking in Azure. Blueprints have a Locking Mode. This Locking Mode can be applied to None or All Resources and is determined during the assignment of the Blueprint. The decision on cannot be changed later. If a locking state needs to be removed, then you must first remove the Blueprint assignment.

Some Blueprint artifacts create resources during assignment. These resources can have the following state:

  • Not Locked – Can be changed. Can be deleted.
  • Read Only – Can’t be changed and can’t be deleted.
  • Cannot Edit / Delete – Create, update, and delete within the resource group.

Artifacts that become Resource groups get the state of Cannot Edit / Delete automatically but you can create, update, and delete resources within them.

The high-level stages of an Azure Blueprint are Create it, assign it to a scope, and track it.

Anatomy of a Blueprint:

Azure Blueprint Anatomy

 

Blueprint does have a REST API. I am not covering the REST API in this blog post as I have not had the opportunity to spend much time working with it yet.

Now let’s look at building and assigning an Azure Blueprint.

BUILD A BLUEPRINT

Now I am going to give an example of building and using an Azure Blueprint in a cloud foundation mock scenario. In my mock scenario I have 3 Azure subscriptions. Each subscription should have a Core services Resource Group consisting of a core VNet with 3 subnets, an NSG for each subnet, and the web subnet should be ready for DMZ traffic. For the core VNet and any additional VNet added to the Core Services Resource Group I need network watcher deployed to it.

Each subscription also should have a core storage account and a blob storage that is ready for general storage needs. I want a tag applied to any Blueprint assignment labeling it with the assignment name, so it is easy to track. The last requirement I have is that I need the CloudOps team to automatically be owner of all core services resources. To accomplish all of this I created the following Blueprint:

Now let’s walk through the parts of creating and assigning the Blueprint. The first step is to create the Blueprint Definition.

In the basics step I give it a meaningful name and meaningful description. I set the Definition Location to the root of my Management groups. Doing this will allow me to assign this Blueprint to all 3 subscriptions in turn creating the core services RG in each subscription.

Next the Artifacts need to be added. Note that when adding an Artifact at the Subscription level you have these options as types:

The Resource Group Artifact type is only available at the subscription level and the ARM template Artifact type is only available at the Resource Group level. I added the Resource Group that the core networking and core storage will be deployed into.

Read more

Native Cloud Management in Azure

by

For those that know me know that I have been a System Center expert for some time focused on helping organizations manage their IT along with their ITSM needs. I have been working with Azure since it was released off and on but started to get serious about Azure after Microsoft’s move to resource manager. And even more recently I have re-focused completely to Azure and DevOps along with ITSM in the context of the cloud. I consider this combination CloudOps.

CloudOps is important when it comes to cloud and supporting DevOps. A part of CloudOps is cloud management. More specifically the tooling name for cloud management is often referred to as Cloud Management Platform (CMP).  CMP’s can be a CloudOps architect and engineers best friend or worst nightmare. There are many CMP solutions out there in the market that can be used to manage Azure and other clouds as well. Microsoft has done a nice job building and bringing in native solutions that can be used to manage Azure. The following image depicts the areas of cloud management that are in focus for Microsoft.

I am sure the plan for native cloud management will change and expand over time as Azure and its management needs continue to grow. The native set of cloud management tools in Azure can be viewed as a CMP. I am going to put together a group of blogs that at a high level cover the native solutions that exist for managing and securing Azure. There are so many areas in this topic that it has to be broken out into a blog series. This is the first time I am doing a blog series. It will cover the following:

Check back on this post soon. As I create more blog posts in this series they will be linked on the list above.

Read more

Azure Management Groups

by

If your company is like most organizations that are using the cloud, then you have many subscriptions floating around. This is often due to “shadow IT”. However, sometimes organizations simply use many subscriptions as a way to put boundaries around cloud services for departments, teams or other reasons.

Microsoft has built a new service in Azure to help with the governance of your cloud. This new service is called Management Groups. Management Groups is still in preview but it is something I highly recommend you start trying out or using now as it is going to be as big for cloud as group policy was for on-premises AD based environments.

Management Groups sit above subscriptions. This allows Management Groups to be at the highest level in the chain so they can be used to effectively manage access, policies, and compliance for any subscriptions that belong to your organization. Within Management Groups you can set access controls (RBAC) and Azure policy to be applied to subscriptions. Subscriptions are organized in logical containers and the containers are the “management groups”. Your governance conditions are then applied to the management groups. This is the much-needed enterprise level type of management that has been needed in Azure for a while.

Management Groups will eventually become the starting point of governance when organizations embark on the cloud. Management Groups also can be used for organizations that are already in the cloud. I am going to dive into Management Groups giving you a high-level tour but first I need to give some more background on the components of Management Groups.

Each directory has a “root management group”. This root management group is at the top level of the management group hierarchy. All other management groups and subscriptions fold up to the root management group. Access and policies can be applied at the directory level via this root management group.

A couple of other things to note about management groups are that you can only have up to 10,000 management groups in a single directory, a management group tree can go six levels deep not including the root management group, and each management group can have multiple children management groups but only one parent management group.

Now let’s explore how I have structured my management groups to give some examples of how this works. Note that all the examples I show in this blog post are for my Azure environments but yours will be different based on many factors such as your organizational structure of departments, teams, etc.

You can find management groups under All Services>>Management Groups.

When you first access Management Groups you will need to create a root MG. Note that the root MG cant deleted or moved. You can rename the root MG. In the following screenshot, I am showing the creation of a sub MG in my root MG. Also, notice on the left-hand side you can set Access controls (RBAC) on this MG.

In order to configure Azure Policies and apply it to a management group, you do that within the Azure Policy itself. You can see in the following screenshot that I have an Azure policy and I am scoping it to the Prod01 MG. Whatever subscription/s and resources in those subscriptions will inherit the policy unless an exclusion is set in the policy or I am breaking inheritance at the resource group level.

In the following screenshot, I am showing the addition of an existing resource. The resources you can add are other MG’s or subscriptions.

In the following screenshot, you can see that I am going to add one of my subscriptions to my Dev01 management group. After doing this I can configure development related access and development related policies to this subscription. I also can do the same thing with my production environments/subscriptions.

Here is what my Management Groups hierarchy looks like:

In my hierarchy I have 3 subscriptions I split into two for production and 1 for development. I have created a root management group and placed all other management groups in it. I created a parent management group for my prod subscriptions and 1 for my development subscriptions in case I add more in the future. I then created a prod01 and prod02 pulling a subscription into each one. Doing this allows me to have separate access and policies per subscription. One thing you could do is pull multiple subscriptions into a single management group.

Note that I also could apply access and policies at the root level or at one of my environment management groups i.e. Prod_Env/Dev_Env and the sub-management groups would inherit the access and policies that are set at the environment management group level.

Also if you need to you can move management groups to a new parent management groups.

Thanks for reading this post. As I mentioned at the beginning of this post Azure Management Groups are currently in preview but they are worth checking out and potentially using now as these are going to become a critical part of the Azure governance story.

Read more