Effortless Private Endpoint Management in Azure Landing Zones: A Streamlined and Compliant Approach

[Svenbaeck]

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:

targetScope = 'managementGroup'

metadata name = 'PrivateEndpointDnsContributor Role'
metadata description = 'Role for registring a Prviate Endpoint in a Private DNS Zone'

var varRole = {
  name: '[${managementGroup().name}] PrivateEndpointDnsContributor'
  description: 'Role for Contributing to Private Endpoint DNS Configuration'
}

resource resRoleDefinition 'Microsoft.Authorization/roleDefinitions@2022-04-01' = {
  name: guid(varRole.name, managementGroup().name)
  properties: {
    roleName: varRole.name
    description: varRole.description
    type: 'CustomRole'
    permissions: [
      {
        actions: [
          'Microsoft.Resources/subscriptions/resourceGroups/read'
          'Microsoft.Network/privateDnsZones/read'
          'Microsoft.Network/privateDnsZones/*/read'
          'Microsoft.Network/privateDnsZones/join/action'
        ]
        notActions: []
        dataActions: []
        notDataActions: []
      }
    ]
    assignableScopes: [
      tenantResourceId('Microsoft.Management/managementGroups', managementGroup().name)
    ]
  }
}

output outRoleDefinitionId string = resRoleDefinition.id

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:

Connect-AzAccount

$inputObject = @{
    DeploymentName        = 'PrivateEndpointDnsContributor-{0}' -f (-join (Get-Date -Format 'yyyyMMddTHHMMssffffZ')[0..63])
    Location              = "eastus"
    ManagementGroupId     = "contoso"
    TemplateFile          = "./PrivateEndpointDnsContributor.bicep"
  }
 
New-AzManagementGroupDeployment @inputObject

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:






Continue reading...