Effortless Private Endpoint Management in Azure Landing Zones: A Streamlined and Compliant Approach
1. Challenge
In Azure Landing Zones, the network infrastructure, including components like VNET Gateways and ExpressRoute circuits, is part of the platform landing zone. However, in line with the subscription democratization principle, workload owners should be empowered to deploy infrastructure as needed while remaining compliant with corporate policies.
To achieve this in Azure Landing Zones, a custom Subscription Owner role grants workload (VNET) owners full access, excluding role assignments and networking. While this setup generally works, it poses a challenge for Private Endpoints. Registering a Private Endpoint into the required Private DNS Zone, which is centrally managed in the platform landing zone, is not possible because workload subscription owners lack access to these Private DNS Zones. Although they can be granted access using the Private DNS Zone Contributor role, assigned to the “connectivity” subscriptions or management groups, this role provides too much access, such as editing or deleting records. Ideally, only the (de-)registration of the CNAME record for the Private Endpoint should be allowed. This article describes a simple solution to this problem while ensuring compliance with Azure Landing Zone policies.
MS Learn outlines an approach for "Private Link and DNS integration at scale", but it has several drawbacks:
- The policies can quickly become large and complex.
- Each Private Link Resource type requires dedicated code in the policy.
- This method is incompatible with several resource types such as AKS and PostgreSQL Flexible Server.
The approach described in this article is easy to deploy and provides a seamless, Azure Landing Zones-compliant solution.
2. AZURE Landing Zones
The diagram below shows the resource structure in an AZURE Landing Zone. A subscription in the "Landing Zones" management group serves as boundary for a single workload. The owners of the workload are assigned the "Subscription Owner" role on the subscription. The Private DNS Zones however, reside in the "Connectivity" subscription, part of the "Platform" management group.
Deploying a Private Endpoint in the workload subscription requires creating a CNAME record in the correct Private DNS Zone (in the platform landing zone), not accessible by "Subscription Owners".
3. Role Based Access Control
To register a Private Endpoint’s CNAME record, the identity (user, service principal, or managed identity) must have the “Microsoft.Network/privateDnsZones/join/action” permission on the Private DNS Zone. While this is the only essential action, for a seamless experience across PowerShell, CLI, and the portal, at least two additional actions are necessary:
- Microsoft.Resources/subscriptions/resourceGroups/read: This allows browsing the resource groups in the portal, with no access to the resources in the group. The portal requires this to allow browsing to the Private DNS Zone.
-
Microsoft.Network/privateDnsZones/read: This allows seeing the Private DNS Zones (resource properties, but not the records), again to allow browsing to the required Private DNS Zone in the browser.
- Optionally you can add Microsoft.Network/privateDnsZones/*/read: This allows reading the records in Private DNS Zone. It's not a must, but allows validating presence of the CNAME records.
4. Custom Role
The simplest and recommended way to assign rights for a specific set of actions to an identity is through a custom role. Note that this requires an Entra ID P2 license, which is also necessary for the Azure Landing Zone (ALZ) recommended custom roles. The Bicep code below lists the role definition and facilitates easy deployment of the role into the landing zone environment:
This BICEP template has to be deployed into the "Intermediate Root " management group ("Contoso" in the diagram in the previous paragraph). Below you find a PowerShell snippet showing how to deploy the bicep code:
5. Role assignments
After deployment, there’s one additional step: assign this role to every identity that needs permission to deploy Private Endpoints for workload subscriptions (also known as "Application Landing Zones"). The role assignment must be scoped to the “Connectivity” Management Group within the platform landing zone. This process is illustrated in the diagram below:
Published on:
Learn moreRelated posts
How to Integrate Azure Service Bus with Microsoft Dynamics 365 CRM Step by Step with Example?
Keeping data flowing between applications is critical in today’s connected business world. Organizations using Microsoft Dynamics 365 CR...
Enhancing Secure Sign-Ins with Temporary Access Pass in Azure Active Directory
Introduction While working on improving user account recovery scenarios, a common challenge often arises: how to securely allow a user to sign...
Azure SDK Release (September 2025)
Azure SDK releases every month. In this post, you'll find this month's highlights and release notes. The post Azure SDK Release (September 202...
Batch Processing Triggered Pipeline Runs in Azure Synapse
This post describes a pattern for batch processing triggered pipeline runs in Azure Synapse
Reliably refreshing a Semantic Model from Azure Data Factory or Synapse Pipelines
This post describes a pattern for reliably refreshing Power BI semantic models from Azure Data Factory or Azure Synapse Pipelines.
Power Pages Fundamentals #24: Boosting Portal Security with Azure Single Sign-On: Quick Read Series
Contoso Motors is a large automotive service company.They have built a Power Pages customer portal for their external partners and customers t...
Building Azure functions that never store secrets — ever
What if your function could hit Microsoft Graph with no client secrets, no certs, and no Key Vault entries? That is exactly what a Managed id...