Share via

Manage sensitive resources in Azure

Kaushik Ray 5 Reputation points
2025-11-27T05:10:04.0766667+00:00

We operate more than 70+ Azure subscriptions for multiple teams. Each subscription is created by our central platform team, and we deploy a standard set of shared/platform resource groups and resources, for example:

 

rg-master-cloudmonitoring (Common)

rg-platform-cloudmonitoring  (Common) 

rg-azure-dns-zones / rg-dept-dns-zones  (For network based subsc) 

rg-platform-monitoring  (Common)

rg-platform-networking (For network based subsc)

rg-platform-private-dns-resolver (For network based subsc)

rg-platform-public-dns-resolver (For network based subsc)

rg-platform-defender-monitoring (Common)

rg-master-dns-zones (For network based subsc)

Three to four of these resource groups(marked as common) exist in every subscription, and some subscriptions have additional platform resource groups depending on requirements(network, dns related).

 

These resource groups and resources are fully owned and managed by the platform team, and must not be modified or deleted by the application teams. The application teams are subscription owners/controllers for their workloads, but they are expected to deploy only into their own, non-platform resource groups.

 

We want to:

 

  • Implement a robust, Azure-recommended way to protect (lock/control) these platform resource groups and resources across all subscriptions, even though the exact set varies per subscription.
  • Avoid issues where Terraform deployments fail because the resources are locked when the platform team needs to update or add platform resources. 

Establish a clear process and technical pattern to temporarily unlock during deployment and then reapply locks afterwards, ideally aligned with Azure governance best practices.

 

What is the recommended Azure approach (e.g., use of management locks, RBAC, Azure Policy, Terraform patterns, or automation) to protect these shared platform resource groups and resources, while still allowing controlled updates by the platform team in this multi-subscription scenario?

Azure Policy
Azure Policy
An Azure service that is used to implement corporate governance and standards at scale for Azure resources.
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Q&A Assist
    2025-11-27T05:10:20.13+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    To protect your shared platform resource groups and resources across multiple Azure subscriptions while allowing controlled updates by the platform team, you can implement the following Azure governance best practices:

    1. Management Locks: Use Azure management locks to prevent deletion or modification of the platform resource groups and resources. You can apply locks at the resource group level with the CanNotDelete lock type to ensure that application teams cannot modify or delete these resources. This can be done using Azure PowerShell or Azure CLI commands as outlined in the Azure documentation.
    2. Role-Based Access Control (RBAC): Implement RBAC to restrict access to the platform resource groups. Assign the application teams roles that allow them to manage their own workloads but do not grant them permissions to modify or delete the common platform resource groups. For example, you can assign the Reader role to application teams for the platform resource groups while giving the platform team the necessary permissions to manage these resources.
    3. Azure Policy: Use Azure Policy to enforce compliance and ensure that only the platform team can make changes to the designated resource groups. You can create policies that audit or deny any unauthorized changes to these resources, providing an additional layer of governance.
    4. Automation for Temporary Unlocking: To avoid deployment issues with Terraform, establish a clear process for temporarily unlocking the resources during updates. You can automate this process using Azure Functions or Azure Automation. Create scripts that will:
      • Remove the management lock before a deployment.
      • Execute the Terraform deployment.
      • Reapply the management lock after the deployment is complete.
    5. Terraform Patterns: Implement Terraform patterns that include pre- and post-deployment hooks to manage the locking and unlocking of resources. This can be achieved by using Terraform's null_resource with provisioners to execute the unlocking and locking scripts as part of the deployment workflow.

    By combining these approaches, you can effectively manage and protect your shared platform resources while allowing the platform team to perform necessary updates without encountering deployment failures due to locked resources.

    References:

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.