Blueprints scopes and assignments

Welcome back for part three of four in our Blueprint technical series. Today we’re covering the governance and lifecycle controls of Blueprints within an Azure tenant.

There is a lot of power in what Blueprints provide, and this tooling needs to be managed across multiple subscriptions or organization units. This is where Blueprint scopes come into place.

The best-case scenario is if the same Policy could be applied everywhere, but that typically isn't the case. Generally, there may be exclusions for production versus non-production environments. For example, the size or types of resources allowed may be different. Premium SQL with High Availability enabled makes a lot of sense in production, but it's pretty costly for most development environments. Or if Dev teams are located in other countries, maybe Dev workloads are in regions closer to them, which may differ from Production regions.

Generally, Production and Non-Production Blueprints are defined as a standard, and there may be a significant amount of overlap between them. This is where Policy initiatives come in.

Initiative are aligned to the security-based Policies that must be enforced across the environment. The production and non-production Blueprint then consume that initiative with different individual policies attached to each as appropriate.

Choosing scopes

Scope assignment is essential and drives how and where Blueprints can be assigned. I generally recommend defining a Blueprint at relatively high-level Management groups to be assigned across the enterprise as needed, even if expectations change in the future. This provides the maximum amount of flexibility.

The diagram below lays out the interplay between management groups, subscriptions, and Blueprints.

Click for full size image

Management groups

Management groups are high-level, subscription-crossing organizational units used for governance and reporting across the tenant. Administrators can create a multi-level hierarchy to manage all of the different subscriptions and organizations has within their tenant.

There are several approaches available, and there isn't a right or wrong solution. It depends on what best fits the organization and its structure. Here are some standard methods.

• Matching organization divisions (R&D, Manufacturing, Admin, etc.)
• Aligning with geographic locations (North America, ASIA PAC, Europe, etc.)
• Aligning with product life cycles (Dev, QA, Prod)
• A mix of all three

The current limit is six levels of hierarchy, providing many options for structure. It’s good to spend some quality time on the hierarchy since it becomes a keystone of the security and governance model.

Subscriptions

Defining subscriptions only performs that action within the specific subscription. Suppose the same Policy should be assigned to a new subscription in the future. In that case, the Blueprint must be recreated from scratch or use PowerShell to export and reimport the existing Policy and assign it to the new subscription. The upside to this is that if there are very restrictive or specific requirements in the Blueprint, they cannot be assigned elsewhere, accidentally causing issues. The downside is creating a new Blueprint if there is a need to add the same requirement to a new subscription in the future and adds additional complexity and limited centralized Blueprint control as small variations could start to appear across the different subscriptions and their Policies.

Once again, it is generally recommended to assign the Blueprint definition at a higher scope than initially needed to allow for future flexibility assigning the configuration in the future.

Resource Group

Resource groups also have the same benefits as subscriptions, just at a smaller scale. The big win here is networking specific Blueprints. Going back to the hub and spoke topology, having a Blueprint defined for deploying spokes can be useful. The Blueprint has a resource group defined within it that contains the core networking components needed to deploy for creating new spokes in the network topology.

For example, an ARM template for a new VNet with associated configuration, automatically configuring the required permissions, and having Policies ensuring that the deployment is consistent across the other spokes within the environment is a concrete use case of resource group deployments.

Managing Blueprint assignments

Once a Blueprint is defined at the chosen scope level, it’s possible to assign the Blueprint to any object beneath that scope. We generally recommend creating definitions at higher levels than initially considered for the Blueprint. For example, create the definition at a management group level rather than on a specific subscription. This provides the flexibility to easily assign across multiple different resources a single Blueprint rather than having multiple iterations that need to be maintained and kept in sync.

Exclusions

If needed, a Blueprint exclusion can be created that prevents the Blueprint from acting on the resource. Exclusions should be done with care and under minimal circumstances. Too many exclusions across the environment make the definition look like swiss cheese, which doesn’t help anyone. At that point, it becomes too difficult to understand the scope and requirements of what may fully or may not be enforced. This can create a false sense of security for consumers of the subscriptions.

Blueprint lifecycle

As security and compliance needs change, so must the Blueprints organizations rely on, as such Blueprints should be considered living infrastructure with its management lifecycle.

• Initial draft - This can be self-created, a Microsoft sample, or something from the community.
• Published definitions – Once a Blueprint is finalized, a published version is defined.
• Assigned Blueprint - A published Blueprint is assigned to a scope.
• Iterative draft - Making changes to an already existing Blueprint to create a newly published version.

It’s possible to have multiple published versions of a Blueprint assigned across the infrastructure. Suppose there is a breaking or invasive change required in a Blueprint or differing change control policies. In that case, someone can easily make those changes and roll them out across individual scopes in a controlled manner rather than an all-or-nothing approach.

Versioning can follow any versioning scheme you prefer, and there is a section for adding change notes when publishing a new version. However, it’s essential to have a consistent versioning pattern, and you should consider tracking change numbers or other administrative data in the Blueprint notes.

Conclusion

At this point, we’ve covered the foundation of the patterns and concepts of Blueprints. In Part Four of this series, we deploy the FedRAMP Moderate Blueprint into an Azure tenant. For more information and to get assistance with your cloud engineering and compliance challenges, please visit: Coalfire Engineering.

More from this blog series:
Part 1:Using Azure Blueprints to Control Azure Compliance
Part 2:Azure Policies