Blog Post

ITOps Talk Blog
3 MIN READ

Getting started with Azure Blueprints

SoniaCuff's avatar
SoniaCuff
Icon for Microsoft rankMicrosoft
Jan 22, 2019

While the Cloud allows for speed and flexibility, there are still valid reasons for controlling the configuration of Cloud resources – including regulatory compliance requirements. Azure Governance consists of several services to enforce or audit resources inside Azure and now also the configuration inside guest virtual machines:

 

Azure Policy  - Limit which kinds of resource and sizes can be created or which Azure locations are allowed, enforce Azure settings (such as enable monitoring in the Azure Security Center or enforcing tags), and audit or enforce in-guest settings (like password security settings).

 

Azure Role Based Access Control (RBAC)  - Define which level of access a user, group or resource has to resources, groups or subscriptions inside Azure.

 

Azure Resource Manager Templates   Define as JSON code the required resources and their properties to be deployed. This is useful for ensuring consistency, deploying resources at scale and building conditions and dependencies into the resource creation process.

 

Previously, these would all need to be configured and assigned to each subscription or resource group, with no easy way to duplicate them. In September 2018 at Microsoft Ignite, Florida, we announced the preview of Azure Blueprints to address this.

 

Azure Blueprints – combining your governance artifacts

An Azure Blueprint lets you define which policies (including policy initiatives), RBAC settings and Resource Manager Templates are applied to resources inside a particular subscription. We can also add specific resource groups which we want created.

 

Example of a Blueprint definition showing Policy and Role assignments.

 

Some artifacts, like resource groups and RBAC settings, can be soft-defined in the base Blueprint, with the details added when that Blueprint is assigned. This is useful for enforcing particular resource groups for example, which must be uniquely named. Instead of every Blueprint assignment trying to add “resourcegroup-12345”, you can specify what the resource group needs to be named during the process of assigning the Blueprint to a subscription.

 

Example of defining artifact specifics during the Blueprint assignment.

The Blueprint definition itself is stored at the Management Group level and can be assigned to any subscription under it. Versioning also lets us add comments on Blueprint definition changes and gives you visibility of which version is applied to a subscription.

 

You’ll find Azure Blueprints inside the Azure Portal (under All Services if it’s not appearing on your side bar by default). Start by identifying what governance artifacts (such as policies and RBAC settings) you are currently enforcing at a subscription level, and where there are similarities between subscriptions.

 

Once you've defined a new Blueprint and added all the relevant artifacts, saving it will store it as a Draft, then you'll right-click to Publish it.

 

Then with your Blueprint published, you can right-click and Assign the blueprint to the appropriate subscriptions under that Management Group.

 

Use cases

Defining and assigning a Blueprint to all the subscriptions inside a Management Group is an easy way to set configurations at scale, knowing that any resources created in those subscriptions will need to comply with those settings (or will show as non-compliant in the case of audit policies). Now we can group all of our production subscriptions together, for example and easily enforce organization-wide controls.

 

With Management Groups letting us create a hierarchy for our subscriptions, we can define more restrictive controls for some subscriptions and less restrictive controls for other subscriptions. Blueprint assignments give us clear visibility into which controls are being applied, as a set, instead of manually checking the different areas for Policy, RBAC etc.

An example Azure Management Groups structure for multiple subscriptions.

If we want to see the impact of making changes to those artifacts, we can change the Blueprint definition that’s assigned to our test subscriptions first.  

 

And finally, we can create new Blueprint definitions to meet specific organizational or compliance requirements, like ISO 27001.

 

Extending Azure Blueprints

If you’re using Azure DevOps to control the deployment of Cloud resources as code, Azure Blueprints can be incorporated into your CI/CD pipelines.

 

And later this week, I’ll share on this blog how a new PowerShell command can help you copy over Blueprints from test subscriptions to production subscriptions in different Management Groups, or even transfer Blueprints to different Microsoft Azure tenancies. More PowerShell commands are coming, too.

 

To learn more:

 

Remember, this service is currently in preview so it is subject to change. We’d love to hear your feedback on how we can make it even better.

 

For more information on Azure Blueprints, visit https://docs.microsoft.com/azure/governance/blueprints/overview?WT.mc_id=blog-ItOpsTalks-socuff

 

Or join us at a  Microsoft Ignite | The Tour city, where we’ll demonstrate Azure Blueprints during session HYB40: Governing your Azure environment. 

 

 

Updated Jan 24, 2019
Version 2.0
No CommentsBe the first to comment