Enterprise-Scale
Enterprise-Scale copied to clipboard
Azure
Feature Request - Deny Private DNS in Landing Zone Subscriptions
In line with deploying private DNS zones in the connectivity subscription to support private link we should also block the creation of privatelink.* DNS zones in the landing zone management group.
Can we check where we are in terms of having this as built-in as part of the effort? :-) // @victorar @daltondhcp
We already provide a custom policy to deny creation of Micosoft.Network/privateDnsZones, but I do agree that we should provide an option to assign it as part of the reference implementations.
However, as it stands today, the policy will block the creation of any private DNS zone, regardless of prefix/name of the zone. Given how centralized DNS works, this should generally not be a problem since LZ teams wouldn't be able to use a private DNS zone deployed in the LZ anyway. Do you agree or do you think it makes sense to refine the policy to only block creation of zones with certain prefixes such as 'privatelink*'?
With regards to built-in coverage, given how the custom policy we have looks like today, we actually already have coverage with the built-in policy 'Not allowed resource types/6c112d4e-5bc7-47ae-a041-ea2d9dccd749'.
The way I handle this in customer environments is to modify the policy to deny creation of privatelink.* zones as you call out. The other thing we do is have an exclusion scope for that policy assignment to not apply on the Platform/Connectivity management group. So during the initial boot-strapped deployment I would expect the "Deny DNS zones" to apply at the top management group with an exclusion for the connectivity management group.
Thank you for the input. Currently, we recommend assigning this policy at the Landing Zones or Landing Zones/Corp management group since that is where we host all the subscriptions targeted by the Deploy-DNSGroup policies etc. Are there any specific scenarios where you see that this would also be beneficial for Identity/Management on the platform side? Generally, we want to avoid leading with exclusions/notScopes.
The primary reason I do it this way is because we want to prevent any "privatelink.*" DNS zone from being created outside of the shared networking subscription(s). No one should be creating private link DNS zones in any other area because of all the other dependencies required to make it work in hybrid models (conditional forwarding from on-prem DNS, DNS zone linked to appropriate VNet's in Azure, etc.). I also think it is fine to apply it just to the landing zone management groups with the assumption that "platform" teams understand this behavior.
As part of the recent policy refresh, we have addressed this as part of #1273 . However, we only made this an audit policy as we did not want to restrict the DNS zones from being provisionally provisioned in case they were required.
https://github.com/Azure/Enterprise-Scale/wiki/ALZ-Policies#:~:text=Audit%20Private%20Link%20Private%20DNS%20Zone%20resources
Closing out as per above