Azure / avdaccelerator

AVD Accelerator deployment automation to simplify the setup of AVD (Azure Virtual Desktop) based on best practices
MIT License
324 stars 207 forks source link

[Feature Request] - Deploy private endpoints for key vault and storage without private dns integration #524

Closed stalejohnsen closed 9 months ago

stalejohnsen commented 10 months ago

Describe the feature end to end, including deployment scenario details under which the feature would occur.

In the current bicep implementation you have the option of deploying key vault and storage with private endpoints. If you do so you have two options: 1) Deploy private dns zones 2) Reference existing private dns zones by resource id. Typically customer that implement Azure Landing Zone already have these private dns zones centralized in the connectivity / hub but the workload team (AVD) does not have permission to write to the centralized platform team owned private dns zones. This is instead handled by Azure Policy: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/private-link-and-dns-integration-at-scale

AVD accelerator should have an option to deploy private endpoints but not integrate with private dns zones at all since this will be added by Azure Policy in the previous mentioned privatelink and dns integration at scale solution or other alternative dns setups.

Why is this feature important. Describe why this would be important for your organization and others. Would this impact similar orgs in the same way?

It's important for further alignment of AVD accelerator + Azure Landing Zone.

Please provide the correlation id associated with your error or bug.

Deploying with createPrivateDnsZones = true and not specifying avdVnetPrivateDnsZoneKeyvaultId will result in this deployment error: Property id '' at path 'properties.privateDnsZoneConfigs[0].properties.privateDnsZoneId' is invalid. Expect fully qualified resource Id that start with '/subscriptions/{subscriptionId}'

Can you describe any alternatives that you have taken since this feature does not exist?

No response

Feature Implementation

No response

moisesjgomez commented 10 months ago

@stalejohnsen Thank you for raising this issue. It is a fair point that Private DNS zones may be provisioned under platform team scope and thus not giving the workload team access to write. It is currently designed to require Private DNS zone configuration at deployment because if Private Endpoints are being used without adding records to the Private DNS Zones, the deployment will fail. We will review this further.

cc: @swathibhat1 Let's add this to the backlog and discuss further.

danycontre commented 10 months ago

@stalejohnsen great feedback.

Some thoughts:

Not registering the private endpoints at deployment time but waiting for policies to apply will break the FSLogix deployment since the storage rules are set to only allow connections on the private endpoint but the VMs can't resolve the private IP until the DNS settings are in place.

For the deployment of FSLogix to be successful, we will need to run a deployment without private endpoints and then add the PE setup as an add-on brownfield scenario.

danycontre commented 9 months ago

@swathibhat1 let's work on this one as an ADO new feature request / enhancement.

@stalejohnsen we will keep you updated.