Bug Report: Lacking permissions in default policy Deploy-Private-DNS-Zones

[steph409]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Versions

terraform: 1.5.1

azure provider: 3.3.5

module: 1.4.0

Description

Describe the bug

Policy: Deploy-Private-DNS-Zones There is a build-in policy on the corp-landing-zones management group. It creates an A record in the private DNS zone in the connectivity subscription.

In order to create the A record, the managed identity seems to need two permissions:

• on the corp-landing-zone, it has network contributor and Private DNS Zone Contributor, and this is sufficient to modify the private endpoints within this subscription.
• on the connectivity-platform-subscription, it has no permissions. It seems to need the permission Microsoft.Network/privateDnsZones/join/action to add the A record to the existing private DNS zone. This permission seems to be missing and I do not understand where in the code the permissions to the system assigned identities are managed.

Steps to Reproduce

I use the following sample configuration: vwan with custom parameters

where I modified the following lines:

spoke_virtual_network_resource_ids        = [ "/subscriptions/b742bc62-0000-0000-8c93-01d342f48f63/resourceGroups/demo-aks2-stephi/providers/Microsoft.Network/virtualNetworks/aks-network"]

enable_private_dns_zone_virtual_network_link_on_spokes = true 

Additional context

For testing, I have an azure container registry with a private endpoint, lacking a private dns entry. The policy successfully shows, that the a record is missing in the central DNS. When I trigger a remediation task, I get the following error message:

The subscription id starting with b74 is the corp-landing zone, the one with 99d is the connectivity one. The client-id ebd.. is the enterprise application for the policy Deploy-Private-DNS-Zones.

{"code":"DeploymentFailed","message":"At least one resource deployment operation failed. 
Please list deployment operations for details. 
Please see https://aka.ms/arm-deployment-operations for usage details.",
"details":[{"code":"LinkedAuthorizationFailed","message":
"The client 'ebd474c7-0000-0000-0000-fee25352e235' with object id 'ebd474c7-0000-0000-0000-fee25352e235' 
has permission to perform action 'Microsoft.Network/privateEndpoints/privateDnsZoneGroups/write' on scope
 '/subscriptions/b742bc62-0000-0000-0000-01d342f48f63/resourcegroups/demo-aks2-stephi/providers/Microsoft.Network/privateEndpoints/containerregistryaksstephi-endpoint/privateDnsZoneGroups/deployedByPolicy'; 
 however, it does not have permission to perform action 'Microsoft.Network/privateDnsZones/join/action'
  on the linked scope(s)
   '/subscriptions/99d115a2-0000-0000-0000-38b2feb4bcb7/resourceGroups/slcorp-dns/providers/Microsoft.Network/privateDnsZones/privatelink.azurecr.io' 
   or the linked scope(s) are invalid."}]}

I validated the scopes and the scope and this is exactly where the private dns zone is.

Happy to give further details if this helps.