Azure Deployment Stacks

Johan Olsson

• 5 min read
Azure Deployment Stacks

Welcome to the world of Azure, where 'stacking up' your resources is more than just a routine task. In this article, we'll take the frame to the stack into the world of Azure Deployment Stacks, where organizing resources is as straightforward as stacking blocks. So, grab your curiosity and let's explore how the Deployment stack feature simplifies resource management, making it as intuitive as stacking bricks.

Core Structure

To establish a common understanding of Azure's core structure, let's recap:

Azure's organizational structure revolves around the resource provider that define and manage resources. These resources are organized within resource groups. Subscriptions serve as the foundational units, responsible for access and billing. They can be integrated into a management group hierarchy, leading to the root group for comprehensive management and governance. At the top, we find Azure Active Directory (Azure AD) or Entra ID, responsible for identity and access management. This framework ensures a well-organized Azure ecosystem.

IaC - Infrastructure as Code

Azure offers several ways to describe your infrastructure as code. These methods can be broadly categorized into three declarative approaches, with a fourth option that can be considered as prescriptive.

  1. ARM Templates (Azure Resource Manager Templates)
  2. Bicep Templates (named as a clever 'pun' on "bicep" due to its extension of ARM)
  3. Third party solutions (i.e. Terraform, Ansible etc.)
  4. Azure CLI / AZ Powershell cmdlets
    • This approach leans more towards prescriptive rather than being entirely declarative. However, it's good to know that you can deploy infrastructure using this approach as well.

These options provide files or scripts that describe the desired infrastructure and its configuration. Infrastructure as Code (IaC) is valuable because it allows for full version control, enabling changes to the state of infrastructure, disaster recovery, and much more. Azure can use these templates for either a Complete Deploy or the more common Incremental Deploy. In a Complete Deploy, resources are deleted before being redeployed, while an Incremental Deploy only adds or reconfigures existing resources.

It's worth noting that a single template should ideally consist of resources that share the same lifecycle. Azure can deploy these files at various scopes:

  1. Tenant
  2. Management Group
  3. Subscription
  4. Resource Group

When selecting the Tenant, Management Group, or Subscription scopes, the template can create child resources. For instance, at the Subscription Scope, it can create resources and resource groups in multiple resource groups but not create new subscriptions. In contrast, the Resource Group Scope cannot create new Resource Groups but can manage and create individual Resources in a Resource Group. The same principle applies to Tenant and Management Group scopes.

Challenges of Templates

While IaC and templates offer significant advantages, they also introduce certain challenges:

  1. Long term lifecycle and cleanup: Managing the lifecycle and cleanup of resources can become complex. Resources within a template are not inherently tied to a shared lifecycle, which can result in difficulties when evolving systems, applications, or infrastructure. Removing resources or RBAC rules from a template does not automatically remove the associated resources, potentially leading to orphaned resources that can incur costs over time.

  2. Permission problems: When deploying infrastructure, organizations often rely on high-privilege service principals or users with extensive access rights. There is a lack of 'deny' assignments, making it challenging to restrict who can modify or delete resources. This can lead to security and compliance issues.

  3. Manual Resource Deletion: The manual process of deleting resources can be problematic, particularly in scenarios where production resources are tightly restricted for access or deletion, leading to operational challenges.

Azure Deployment stacks to the rescue!

Azure Deployment Stacks introduce an innovative approach to managing groups of resources as atomic units, without being tied to specific resource groups or subscriptions. When a template is submitted to a deployment stack, it defines the stack and its associated resources. If a resource is removed from a deployment stack, it can either be Detached or Removed, depending on the configuration for action on unmanage. Deployment stacks can even have deny assignments, making them a powerful addition to the Azure resource management toolkit.

This is not only exciting but also a welcome feature for many, including myself.

Getting started with Deployment Stacks is straightforward. You can take an existing Bicep or ARM template and make a simple switch in your regular deployment CLI command:

From:

az deployment group create --name "<deployment name>" -g "<resource group>" -f "<template.bicep>"

To:

az stack group create --name "<stack name>" -g "<resource group>" -f "<template.bicep>" --deny-settings-mode 'none'

Notice the az deployment is switched to az stack

Here, the --name parameter now becomes more significant as it defines the name of the deployment stack resource. Additionally, --deny-settings-mode is a mandatory parameter that determines which operations are denied on resources managed by the stack, although in the above statement we currently does not enable any deny permission settings.

The az stack command creates a deployment stack, encompassing the resources defined in the template. When a resource is removed from the template and redeployed to the stack, the default behavior is that the removed resource enters a "Detached" mode. If you wish to delete resources not in the stack, such as already detached or removed resources in the template file, you can specify the --delete-resources true option.

Deny Settings modes

There are three different options for the --deny-settings-mode:

  1. None: This option doesn't use any deny settings at all.
  2. DenyDelete: It restricts resources in the stack from being deleted but allows other modifications, except for the optional configurable actions or principals.
  3. DenyWriteAndDelete: It restricts resources in the stack from both modification and deletion, except for the optional configurable actions or principals.

Deny Exemptions

With deny exemptions, you can utilize DenyDelete or DenyWriteAndDelete modes in the deployment stack while exempting up to five Azure Entra ID principal IDs using the --deny-settings-excluded-principals parameter. You can also exempt up to 200 specific RBAC actions using the --deny-settings-excluded-actions parameter.

This feature is powerful as it enables you to restrict the deletion and modification of resources within a deployment stack, preventing accidental changes or deletions that could be overwritten in the next infrastructure deployment. You can, for instance, exclude the deployment principal or a Privileged Identity Management (PIM) group.

DevOps Possibilities

This new approach to deployment and lifecycle management unlocks exciting DevOps possibilities. Imagine you have resources deployed using Deployment Stacks, and you need to remove a resource or an RBAC rule from the template:

  1. Remove the resource from the template file.
  2. Trigger a workflow or pipeline that deploys the stack.
  3. Review the detached resources in the workflow.
  4. Make a manual decision within the workflow to delete detached resources.

In this scenario, you can even restrict manual deletion and modification to only the deploying service principal environments.

The strength of consolidating all resources within a stack becomes particularly evident when you can effortlessly distinguish the RBAC assignments within a specific deployment stack. This capability fosters a more organized and controlled environment, especially when applications and resources are distributed and share compute and storage with a mesh of RBAC assignments.

Wrapping up

Azure Deployment Stacks introduce a fresh approach to resource management, turning the intricate task of orchestrating Azure resources into a straightforward process. By utilizing the same .bicep or ARM templates you are familiar with, Deployment Stacks allow you to control a multitude of resources across management groups, subscriptions, and resource groups, all as cohesive atomic units.

This feature offers a secure framework for updating, deleting, and modifying resources, fortified by deny settings and exemptions, thus enhancing resource management within Azure. In a world where the challenges of resource organization are akin to building with blocks, Azure Deployment Stacks provide you with a powerful and user-friendly toolkit, making the process as intuitive as your favorite virtual sandbox.

Ready to get started with Azure Deployment Stacks? Learn how to use them effectively by checking out the official documentation on How to Use Azure Deployment Stacks. It's time to take control of your Azure resources and unlock the full potential of this innovative feature.

So go ahead and stack your resources, Azure-style, and experience resource management like never before.