This policy deletes custom DNS Servers on VNETs when enabling DDoS settings
Closed this issue · 8 comments
Describe the bug
We deployed this policy to an environment and found the DNS Servers configuration were removed as a result of the deployment. DDoS Settings were enabled, but when we tried to modify the policy to keep the DNS Server configuration in place, the policy will not deploy
Reproduce
Steps to reproduce the behavior:
- Go to Assign the policy and remediate
- Check that VNETs no longer have custom DNS Servers Defined
- See error
Expected behavior
VNET Deployment should happen without any property changes happening on the resource
Screenshots
If applicable, add screenshots/images to help explain your problem.
Environment- if applicable
- What version of CLI was used [Az –version]
Desktop (please complete the following information if applicable):
- OS: [e.g. iOS]
- Browser [e.g. chrome, safari]
- Version [e.g. 22]
Logs- if applicable
- If logs are available, please provide relevant snippets
Additional context
Add any other context about the problem here.
This issue is regarding this policy:
https://github.com/Azure/Azure-Network-Security/blob/master/Azure%20DDoS%20Protection/Policy%20-%20Virtual%20Networks%20should%20be%20associated%20with%20an%20Azure%20DDoS%20Protection%20Standard%20plan/VNet-DDoSEnable.json
Policy was posted here:
https://techcommunity.microsoft.com/t5/azure-network-security/deploying-ddos-protection-standard-with-azure-policy/ba-p/1942133
Thank you for reporting this. I'll start testing a fix ASAP.
Verified fix in the latest commit.
Thanks for adding that; however, now if a VNET doesn't have custom DNS servers, this deployment fails.
dhcpOptions may can be an empty object if it needs to be, dnsServers isn't a required property.
Ok, I think I have a fix in mind involving conditional templates. I will test as soon as I get more time.
The policy also seems to delete custom tags attached to the vnet
This policy was just updated and added as a built-in policy in the portal. The issues should no longer exist with the new logic: https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F94de2ad3-e0c1-4caf-ad78-5d47bbc83d3d