Sneak Peak of Azure Blueprints

Azure Blueprints have been announced and made available for public preview last month at Microsoft Ignite 2018. I have been on the private preview for few months now, and I’m really excited that it’s finally gone public and we can start talking about it.

If you haven’t heard of Blueprints, according to the Blueprints PM Alex Frankel, Blueprints is designed for:

deploy and update cloud environments in a repeatable manner using composable artifacts.

I have heard an analogy before – An Azure subscription is just like an empty canvas, and your developers are like painters. But we all know that we can’t just allow our users to deploy anything they like in their Azure subscriptions. You, as the cloud engineer will need to lay down some foundation work and set some rules (i.e. vnets, NSG and firewalls, policies and role assignments, etc.). This is where you would utilize Blueprints. So think about Azure Blueprints as your cookie cutters. You develop blueprints so you can quickly provision consistent environments for your users to consume Azure resources.

You may find the following resources useful if you wish to learn more about Azure Blueprints:

Microsoft Docs: https://aka.ms/whatareblueprints

Ignite session recordings:

• BRK3062 - Architecting Security and Governance Across your Azure Subscriptions
• BRK3085 - Deep dive into Implementing governance at scale through Azure Policy

Alex Frankel’s GitHub Repo: https://github.com/ajf214/personal-arm-templates

I’ve spent some time over the last few days testing it’s capabilities, I’ll share my experience in this post.

Note: Please keep in mind Azure Blueprints is still in preview, its capability is still limited at this stage. Currently, you can add the following types of artifacts in a blueprint:

• Policy Assignment
• Role Assignment
• Azure Subscription Level ARM template
• Azure resource group
• Azure resource group level ARM template

In my lab, I have created a blueprint with the following artifacts:

• A subscription level ARM template that deploys custom policy and initiative definitions, as well as a subscription level policy assignment
• Role assignment – assigning an AAD group to subscription owner role
• A subscription level ARM template that deploys custom role definitions
• A resource group called “rg-network”
• A resource group level ARM template that deploys:
  • A hub and spoke vnet pattern that hub (management) vnet contains various subnets and a VPN gateway. A spoke (workload) vnet that is peered to the hub vnet.
  • A NSG that is associated to all applicable subnets in both vnets.

When creating the blueprint, I have the options to either specify (hardcode) some of the values, or choose the option to enter the value during assignment. In this case, I have hardcoded the resource group name for the networking pattern to “rg-network”, but information such as resource group location, and local (on-prem) gateway IP address will need to be entered when the blueprint is assigned.

Once assigned, depending on your artifacts, it may take a while for blueprint to be deployed. You can check the status in Assigned Blueprints blade:

You may noticed that there is a “Lock” option when you are configuring the assignment. The lock prevents people from modifying / deleting resources deployed by the blueprint. This is different than the Azure resource lock that we are all familiar with. The blueprint team implemented this feature without leveraging the resource lock because resource locks can be deleted by people who have access to (i.e. subscription owners). In order to prevent users from modifying and deleting this resources regardless what roles they have within the subscription, the Blueprint product team implemented the locking using Azure RBAC. According to the Blueprints resource locking doc:

An RBAC role denyAssignments is applied to artifact resources during assignment of a blueprint if the assignment selected the Lock option. The role is added by the managed identity of the blueprint assignment and can only be removed from the artifact resources by the same managed identity.

At the time of writing this article, some capabilities are only available via Blueprints REST API, they have yet been exposed to the Azure portal since Blueprints is still in preview. i.e. When authoring a blueprint in the Azure portal, you do not have the ability to define deployment sequence (dependencies between artifacts), but it is possible using the REST API. Alex has demonstrated this in details in his Ignite talk BRK3085 - Deep dive into Implementing governance at scale through Azure Policy.

Lastly, you can submit your ideas and feedback via Uservoice: https://feedback.azure.com/forums/915958-azure-governance

20 November 2018 Update: The export of the my sample blueprint used in this post is stored in Alex’s GitHub repo: https://github.com/ajf214/personal-arm-templates/tree/master/Example%20Blueprints/managementSubConfig