Native Cloud Management in Azure

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

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