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
Description
Larger organizations utilize Azure Policies to ensure that a Subnets contain a Network Security Group/Route Table ID at creation time, which is incompatible with the azurerm_subnet_network_security_group_association and azurerm_subnet_route_table_association resources - which are required to be able to workaround issues in the Azure API during terraform destroy.
Unfortunately these issues are unavoidable due to the design of the Azure API - and whilst we could seek to reintroduce these two fields - ultimately this'd reintroduce the issue and so isn't a viable solution.
These "association" resources create an empty Subnet and then subsequently patch them to add the network_security_group_id and the route_table_id fields - but crucially by having these split out allow operations to be ordered such that these destroy operations aren't possible.
One option to work around this is to use the azurerm_virtual_network resource to define the subnets with these fields inline - however this only works when these subnets are defined centrally and so doesn't work for all users/scenarios.
As such this issue covers adding an example Azure Policy to achieve this scenario, namely:
- Allowing the creation of a Subnet (with no Network Security Group ID / Route Table ID when there's no Network Interfaces [IP Configurations] present)
- When attempting to create a Network Interface [IP Configuration] within the Subnet, require that a Network Security Group ID/Route Table ID exists
This Policy should allow organizations to comply with Policy requirements (requiring that all Subnets have a Network Security Group/Route Table ID) whilst working around the issues in the Azure API.
New or Affected Resource(s)
azurerm_policy_definition
azurerm_subnet
azurerm_subnet_network_security_group_association
azurerm_subnet_route_table_association
References
Community Note
Description
Larger organizations utilize Azure Policies to ensure that a Subnets contain a Network Security Group/Route Table ID at creation time, which is incompatible with the
azurerm_subnet_network_security_group_associationandazurerm_subnet_route_table_associationresources - which are required to be able to workaround issues in the Azure API duringterraform destroy.Unfortunately these issues are unavoidable due to the design of the Azure API - and whilst we could seek to reintroduce these two fields - ultimately this'd reintroduce the issue and so isn't a viable solution.
These "association" resources create an empty Subnet and then subsequently patch them to add the
network_security_group_idand theroute_table_idfields - but crucially by having these split out allow operations to be ordered such that these destroy operations aren't possible.One option to work around this is to use the
azurerm_virtual_networkresource to define the subnets with these fields inline - however this only works when these subnets are defined centrally and so doesn't work for all users/scenarios.As such this issue covers adding an example Azure Policy to achieve this scenario, namely:
This Policy should allow organizations to comply with Policy requirements (requiring that all Subnets have a Network Security Group/Route Table ID) whilst working around the issues in the Azure API.
New or Affected Resource(s)
azurerm_policy_definitionazurerm_subnetazurerm_subnet_network_security_group_associationazurerm_subnet_route_table_associationReferences
route_table_idwithin thesubnetsblock #7196