Assigning an Azure blueprint

When making an assignment, you will see a screen where you will have to provide the following:

• Subscription(s): This means which subscriptions this particular blueprint should be assigned to.
• Assignment name: As the same blueprint can be assigned to multiple subscriptions, you have to give the assignment a unique name to avoid confusion.
• Location: When deploying resources, a blueprint requires a Managed Identity to authenticate the operation. This field allows you to set the location where credentials will be stored.
• Blueprint definition version: If your blueprint has more than only one version, here, you can select the one you are interested in.

Besides the preceding settings, you will have to also decide whether Lock Assignment should be enabled or not. Locking artifacts created via Azure Blueprints makes much sense when you consider that they are governed by an administrator, not the resource owner. To make a long story short, the scenarios are as follows:

• When a lock is assigned, even a subscription owner cannot change/delete a resource. This ensures that it works exactly as assumed and planned.
• The lock cannot be removed without removing a blueprint assignment.

An example setup for a blueprint assignment could look like this:

Figure 1.20 - Assign blueprint form

As Azure Blueprints is quite a new service, it is constantly enhanced to provide functionality expected in the market. It is a great tool for ensuring a certain level of compliance and will be used mostly in heavily regulated environments. When adding artifacts to a blueprint definition, you have four different artifacts available:

• Policy assignment
• Role assignment 
• Azure Resource Manager template
• Resource group

By using each artifact, you can create a complex definition that will ease the process of deployment and setting up resources. Let's think about the following scenario—I would like to make sure that both Azure App Services and Azure Functions are deployed with HTTPS Only enabled. Additionally, I want to assign a specific user with a specific role to each deployment. Last but not least, I want to deploy a resource group with an ARM template, which creates a storage account. My current setup looks like this:

Figure 1.21 - Blueprint artifact parameters

Note the following:

• You do not have to enter all parameters during the process of creating a blueprint—they can be evaluated while creating a deployment.
• When using the resource group artifact type, each deployment covered by a blueprint will create additional resources defined by it. Using it makes the most sense when attaching an ARM template with extra resources (such as a custom monitoring solution, shared storage, or other similar elements).

To test an assigned blueprint, you can do the following:

1. Deploy a new function app called azureblueprint inside a resource group called blueprint-euw-rg. You should see a similar result to mine, shown in the following screenshot:

Figure 1.22 - The result of running a blueprint with an additional resource group created

2. Besides the declared resource group, Azure Blueprint created an additional group called azureadministration-euw-rg (the name is the result of the passed parameter to a definition, which creates a resource group). This extra resource group contains a storage account with a generated unique name, which I can use for any purpose:

Figure 1.23 - The storage account automatically created by a blueprint

3. Let's check other resource assignments. One of the rules of my blueprint was to assign a user with a particular role (check the role assignment artifact in Figure 1.24). A quick look at the IAM blade gives the expected result:

Figure 1.24 - Role assignment automatically created by a blueprint

4. The last thing to check is that the extra two policies were created. To do so, I go to the Policies blade in my subscription:

Figure 1.25 - Policies blade

From that, you can clearly see that I have additional policies added to the previous ones (Audit HTTPS only access for a Function / Web App):

Figure 1.26 - Azure policies with compliance status

Policies allow for a certain level of inertia—even if somebody managed to create a resource, which was forbidden, very often you do not have to act immediately. The preceding screen (Figure 1.26), however, gives you the possibility to quickly check whether the compliance level is not below the assumed level. 

With the preceding information, you should be able to enhance your current administration tasks and be able to automate many activities such as user assignments or mandatory resources provisioning. When working with Azure Blueprints, remember the following rules:

• Name the assignments uniquely to avoid collisions.
• Use the versioning feature of Azure Blueprints to introduce breaking changes without breaking current assignments.
• Use Lock Assignments to ensure that no one can mess with artifacts deployed by a blueprint. The only thing to remember is the feature inertia—Resource Manager may need up to 30 minutes to finish propagating locks for the artifacts.

Azure Blueprints is one of the best tools when it comes to managing subscriptions and resources at an enterprise level. The next topic we will cover will guide you through the process of usage and quotas management.