Azure Blueprints made its debut last September, promising better management by making it easy to deploy and update Azure environments in a repeatable manner.
Following the recent preview release of the ISO27001 Shared Services to assist in the scaling Azure governance, Evros Principal Azure Solutions Architect Joe Carlyle explores how to set Azure Blueprints, and why your environment might need Azure Blueprints.
What are Azure Blueprints?
Azure Blueprints is a collection of governance and resource services, defined in such a way to allow you to repeat deployments to a set standard with a couple of clicks.
The service is designed to help with environment setup, which often consists of a set of resource groups, policies, role assignments, and Resource Manager template deployments.
The collection of governance and resource services within a Blueprint are referred to as Artifacts. Within each Blueprint, you can make use of any combination of the following:
-Azure Policy assignment
-Azure Resource Manager Template
A blueprint is a package to bring each of these artifact types together and allow you to compose and version that package, assigned to a subscription in a single operation that can be audited and tracked.
Similar to several other new services in Azure, the functionality is great and could help progress a lot of environments, but that doesn’t mean they help, or are even useful in a lot of other environments.
But never feel forced into using a new service because there is a ‘buzz’ about it during launch. Assess the service, understand it, assess its usability versus your requirements, then test often!
How to Set Up Azure Blueprint
|Resource Groups||Subscription||Create a new resource group for use by other artifacts within the blueprint. This enables you to organize resources and provides a scope for other artifacts.|
|Azure Resource Manager template||Subscription, Resource Group||Templates are used to create resources. This could range from individual deployments to entire environments.|
|Policy Assignment||Subscription, Resource Group||Allows assignment of a policy or initiative to the subscription and/or resource group the blueprint is assigned to. Any|
parameters are assigned at creation of the blueprint or during blueprint assignment.
|Role Assignment||Subscription, Resource Group||Role assignments can be defined for the entire subscription or nested to a specific resource group included in the blueprint.|
As you can see above, artifacts can be deployed/assigned at different levels. However, the Blueprint itself must be located in either a subscription you have at least Contributor access to, or a Management Group. If located within a Management Group, the Blueprint is available to any of the child subscriptions of that group.
When defining your Blueprint, several artifact options allow you to choose parameters that are passed from Blueprint to artifact. For example, when defining a Resource Group, you can choose to specify the name and location. You don’t have to specify these parameters within the Blueprint, you can also allow these to be passed when the Blueprint is assigned.
Once you have your Blueprint defined, your next step is to publish it. When publishing, you must indicate a version. I found it odd that this isn’t restricted in some way, you can literally name one version ‘1.0’ and the next ‘B’ so I’d recommend adding notes with each version and try to stick to a pattern. However, it makes sense if you’re going to use different versions for different assignments, choose relative to your requirements.
Assigning Your Azure Blueprint
When your Blueprint is published, you can then assign it. A nice feature is the ability to assign different versions of a Blueprint to different subscriptions. For example you could have two versions of a Blueprint, that have different artifact definitions (think test version and production version) assigned to different subscriptions. They can be independently updated too.
At assignment, there are some options to choose as well as subscription. They are Resource Locking and Managed Identity.
Choose System Assigned as the Blueprints service will then manage the security lifecycle. More on Managed Identities to help you understand and choose what’s right for your environment.
This features allows you to maintain control of your governed deployment. If you’re not familiar with Resource Locks, check out this post. The familiar status applies to resources deployed by a Blueprint assignment:
Managing Your Published Azure Blueprints
However, once a status is applied, not even a user/object with the Owner role can modify it. This is due to how these statuses are applied. An RBAC (role-based access control) deny assignment is applied to artifact resources during assignment of a blueprint if the assignment selected the ‘Read Only’ or ‘Do Not Delete’ option. The deny action is added by the Managed Identity of the blueprint assignment and can only be removed from the artifact resources by the same managed identity.
So, how do you edit or delete your resources? Update your Blueprint to ‘Not locked’ and push the update to the relevant assignment. This method prevents unwanted and unexpected changes occurring outside of the scope of the Blueprint.
There is quite a learning curve for Blueprints I think as they combine several other services you must be familiar with, so for me, you have to start there. Understand each of the artifacts fully so you can see how they may work well if defined in your environment.
NOTE: Blueprints are still in Preview. So be as cautious as always with your production environments. I look forward to seeing what changes come with GA, which shouldn’t be much longer considering Blueprints were announced back at Microsoft Ignite last year.