Add delegation support to virtual network subnet blocks

[rickardl]

• Implemented delegation configuration in virtual_network_resource.go to allow specifying delegation services and actions for subnets within virtual networks.
• Updated tests in virtual_network_resource_test.go to cover the new delegation functionality in the subnet blocks.
• Documented the delegation feature in virtual_network.html.markdown, providing users with guidance on how to use this new capability.
• Adjust related subnet resource code in subnet_resource.go for compatibility and consistency with virtual network changes.

This enhancement enables users to configure service delegations for subnets directly in the blocks, supporting scenarios that require specialized services such as Azure Container Instances or Azure NetApp Files to be associated with specific subnets.

Attempts to resolve #25025

[rickardl]

To align our organization with the Azure Cloud Adoption Framework (CAF) and adhere to Azure Policies, we've employed Terraform modules for streamlined network security and service deployments. A central aspect of this strategy is the deployment of vNet spokes connected to our central Hub. These spokes must support Microsoft Fabric and Container Apps, necessitating the ability to delegate subnets for seamless service integration.

Challenge with current separation between subnet and vNet resources

A key challenge stems from the Azure policy Subnets should be associated with a Network Security Group. This mandates the attachment of Network Security Groups (NSGs) at the time of subnet creation. Due to this requirement, vNet creation becomes complex as it cannot proceed without pre-defined subnets and associated NSGs, demanding an integrated approach from the very beginning.

The current design of the azurerm_virtual_network resource presents a roadblock. It lacks support for configuring subnet delegation (recently implemented in this PR) and NSGs simultaneously. This limitation hinders many organizations' ability to comply with Azure's security best practices. The current design also prevents us from making this delegation a second day activity, because the subnet is now managed by an existing resource (as documented).

Potential Solution

A potential solution lies in extending the azurerm_virtual_network resource to enable delegation within subnet blocks. This enhancement would allow us to create vNets while simultaneously adhering to Azure's security policies.

Let me know your thoughts

[tombuildsstuff]

hey @rickardl

Thanks for this PR.

The subnet block within the azurerm_virtual_network resource is a TypeSet which is problematic in this instance - since it means that any changes to this block (e.g. the addition of new fields) are going to be a breaking change to user configurations in it's current form.

Whilst we’re planning to extend the subnet block within the azurerm_virtual_network resource to support additional properties in the future (which is currently tracked in this issue) - which (given the nature of the fields involved) is going to require moving away from a TypeSet to achieve that. That in turn requires bumping the minimum version of the Terraform Protocol which would need to be done in a major version of the Provider since it unfortunately involves breaking changes to the Terraform Configuration.

All of that is to say, whilst we’d like to thank you for this contribution - and this is something we plan to support in the future - since we’re still waiting to head about the dependencies, unfortunately we’re going to need to mark this one as Blocked for the moment until there’s news on that front.

Thanks!

[tombuildsstuff]

Related: https://github.com/hashicorp/terraform-provider-azurerm/issues/25765

[stephybun]

Closing in favour of #26533

[github-actions[bot]]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.