Azure Blueprints were announced during Microsoft Ignite 2018. I had the privilege to already get access some months earlier and played with the new feature/service to gain some experience. In this blog post I want to give you a quick overview and kickstart what Azure Blueprints are and how they can be used to govern Azure environments.

Azure Blueprint allows you govern your Azure environment. With very little effort, Blueprints can be used to deploy and setup environments for Azure consumers. They consist of definitions and assignments where definitions contain the settings that are then assigned to a management group or subscription using an assignments.

 

Blueprint Definition

The first step when using Blueprints is to create a new Blueprint definition.

Give the Blueprint a name, add a meaningful description and select the Management Group (scope) where the Blueprint can be used later. The Blueprint Definition can only be assigned to the selected Management Group or below (Sub-Management Groups or Subscriptions).

Now add the needed Artifacts to the Blueprint configuration.

Depending on the level you are configuring, the available artifact options are a little bit different.

Subscription Level

• • Resource Group
  • Role Assignment
  • Policy Assignment
  • Azure Resource Manager Template (Subscription Level Deployments)

Resource Group Level

• • Role Assignment
  • Policy Assignment
  • Azure Resource Manager Template (Resource Group Level Deployments)

Resource Groups

Resource Group Artifacts can be used to pre-create a Resource Group-structure within a subscription. In the Blueprint Definition configuration you can choose to either hardcode values – in this case the Resource Group Name and the Region – or to specify a value when the blueprint is assigned later. Specifying values during assignment time gives you additional flexibility if this is needed. This behavior is the same for all types of artifacts.

Role Assignments

Role Assignments allow you to assign permissions to a Subscription or Resource Group. Roles as well as users, groups and applications from Azure AD can be used.

Policy Assignments

Policy Assignments are Azure Policy Definitions or Initiatives that you can assign. This allows you to set clear guidelines how resources should be deployed and managed. You can read more about Azure Policy in this blog post.

Azure Resource Manager Template (Subscription or Resource Group Level)

Using this artifact type gives you the option to deploy specific resources automatically as needed. Just paste your ARM template code directly into the Artifact definition. In this example I will provision a simple Storage Account in a Resource Group.

Here is a sample you can use in case you are not very familiar with creating ARM templates:

{
“$schema”: “https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#”,
“contentVersion”: “1.0.0.0”,
“parameters”: {
},
“variables”: {
“storageAccountName”: “[concat(‘psto’, uniqueString(resourceGroup().id))]”
},
“resources”: [
{
“type”: “Microsoft.Storage/storageAccounts”,
“apiVersion”: “2018-02-01”,
“name”: “[variables(‘storageAccountName’)]”,
“location”: “West Europe”,
“sku”: {
“name”: “Standard_LRS”
},
“dependsOn”: [],
“tags”: {},
“kind”: “StorageV2”,
“properties”: {
“accessTier”: “Cool”
}
}
],
“outputs”: {}

}

You can also use the “parameters” section of the ARM template to populate values during assignment time. This again gives you additional flexibility when Blueprints are assigned.

Blueprint Definition Overview

Once everything is configured, you get a nice overview of what’s defined in your Blueprint definition. This is now saved as a draft.

Before a Blueprint can be used, it needs to be published. Because Blueprint configurations might change over time, there can be multiple versions of the same Blueprint definition. For this initial Publish, I assign it Version 1.0.

A published Blueprint Definition cannot be modified. But in case the configuration needs to be updated, you can publish the Blueprint Definition under a new Version number and use that one.

All Blueprint Definition Versions are stored as individual objects that can be used in assignments later. The different versions are visible on the “Published Versions” tab of the Blueprint Definition. From here, versions that are not used anymore can be deleted.

Remember: Until now, we only created a Blueprint Definition. For now, it has no effect on anything because it has not been assigned yet. But we take care about that in the next section of this post.

 

Blueprint Assignment

Now let’s assign a Blueprint to a subscription to setup our environment.

Depending on the initial Management Group assignment of the Blueprint Definition, your Blueprint can be assigned to the Subscription (or multiple Subscriptions) below the initially selected Management Group.

Depending on the configuration of the Blueprint definition, you need to specify values for parameters. If you hardcoded some values in the definition, they will be shown but are grayed out.

Now let’s hit “Assign” to assign the Blueprint. You can now see the configured assignment and its status. Depending on the complexity of the Blueprint Definition, it can take a while until the status changes from “Waiting” to “Deploying” and (hopefully) “Succeeded”. By clicking on “View Assignment Details” you get some more insights of what happened in the background.

You can also lock a Blueprint Assignment. This is useful if you want to persist the consistency you get by using Blueprints. Imagine someone has “Owner” permissions on a Resource Group or Subscription. This would allow him to manage all resources and configurations and remove any configured restrictions and guidelines set by the Blueprint Assignment. To make sure this does not happen, locks can be applied to all resources of a Blueprint definition (there is only all or nothing for now). Locks can have 3 states:

• Not locked
• Read only (non-Resource Groups) > Resource CANNOT be changed and CANNOT be deleted
• Cannot Edit/Delete (Resource Groups) > Resource Group CANNOT be changed nor deleted, but Resources in the Resource Group CAN be created, edited and deleted

Once set by a Blueprint Assignment, these locks are mandatory and cannot be removed by anyone, not even by an “Owner”. The Resources can only be removed after the Blueprint Assignment has been removed.

 

Blueprint Assignment Updates

In case you create new versions of a Blueprint definition, you can update an already existing assignment and change parameters as needed.

It’s important to understand, how an assignment update works behind the scenes to make sure there are no unwanted modifications to the subscription.

• Role Assignment
  • If something changes, a new role assignment is created. The existing role assignments are not modified and would need to be deleted manually.
  • If a role assignment is removed, nothing gets changed on subscription or resource group level.
• Policy Assignment
  • If only parameter values are changed, the existing policy assignment is updated
  • If the policy definition is changed, a new policy assignment is created. The existing policy assignment is not modified and would need to be deleted manually.
  • If a policy assignment is removed completely, the existing policy assignment is not modified and needs to be deleted manually.
• Azure Resource Manager Template
  • Every resource provider might handle this differently, so this needs detailed testing before re-assignment.

That’s it for a first overview. Azure Blueprints support you governing your Azure environment with minimal effort and allow you to make your cloud setups much faster. In a future post I will cover how Blueprint can be managed through the Azure REST API. Until then: happy blueprinting!

Cheers
Marcel