Terraform-provider-azurerm: Subnet cannot be created with route table (unlike with the Azure API)

[D4zedC0der]

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

I work in a large organisation that has a federated approach to creating Azure infrastructure. A core/central team is responsible for subscriptions, Azure AD and some network resources (including VNET resources and route tables). The individual application/project teams can then pick things up from there and manage the subnets. There are also Azure Policies in place, which (amongst other things) make sure that we cannot create a subnet without a route table being attached. This setup has been advised by Microsoft consultants.

We also have a relationship with Hashicorp and their insight into this provider advises that the developers of the Microsoft SDK (including the one for Go) are advising the developers (including the developers of this provider I imagine) to not add a route table in the same call as creating the subnet, but instead to create the subnet with a second call.

Unfortunately, these 2 pieces of advice from separate areas within MS appear to conflict as we cannot currently use Terraform to create a subnet.

As such, this is a feature request for this provider to follow the API and allow us to create a Subnet linking to the route table in one call, which would resolve the issue. Failing that, a recommendation of how we can use Terrafom and this provider to create a subnet, please.

New or Affected Resource(s)

• azurerm_subnet
• azurerm_route_table
• azurerm_subnet_route_table_association

Potential Terraform Configuration

resource "azurerm_subnet" "example" {
  name                 = "testsubnet"
  resource_group_name  = azurerm_resource_group.example.name
  virtual_network_name = azurerm_virtual_network.example.name
  address_prefixes     = ["10.0.1.0/24"]

  route_table_id = azurerm_route_table.example.id

}

References

7196 - this was closed and locked and I don't think it should have been. After being closed I tried to explain, but I am not sure my explanation was shown. Hence I am raising this new issue with full explanation so that it can be reconsidered with full context.

[sdhibit]

I'm having a very similar issue, but with an additional policy restriction on network security groups too. Like in @D4zedC0der's case, our organization enforces Azure policy that denies subnet creation without a route table or NSG. For us, subnets are almost always created _after_ the virtual network is provisioned, so deploying with the subnet block in the azurerm_virtual_network resource as proposed in #7196 is not an option. In addition, the subnet block within azurerm_virtual_network is missing route table, service endpoint, and subnet delegation assignment options.

The azurerm_subnet resource would need to re-introduce the ability to assign route tables or NSGs at the time of creation, not afterward. Security policies implemented by an organization will prevent this provider's current recommendation of using azurerm_subnet_route_table_association and azurerm_subnet_network_security_group_association since they occur after the subnet is created. In my case, our organization is not willing to change these policies or even audit instead of deny.

Consider the following simplified policy definitions that deny subnet creation:

deny-subnet-without-route-table
{ "mode": "All", "policyRule": { "if": { "anyOf": [ { "allOf": [ { "field": "type", "equals": "Microsoft.Network/virtualNetworks" }, { "not": { "field": "Microsoft.Network/virtualNetworks/subnets[*].routeTable.id", "exists": "true" } } ] }, { "allOf": [ { "field": "type", "equals": "Microsoft.Network/virtualNetworks/subnets" }, { "not": { "field": "Microsoft.Network/virtualNetworks/subnets/routeTable.id", "exists": "true" } } ] } ] }, "then": { "effect": "deny" } }, "parameters": {} }

deny-subnet-without-network-security-group
{ "mode": "All", "policyRule": { "if": { "anyOf": [ { "allOf": [ { "field": "type", "equals": "Microsoft.Network/virtualNetworks" }, { "not": { "field": "Microsoft.Network/virtualNetworks/subnets[*].networkSecurityGroup.id", "exists": "true" } } ] }, { "allOf": [ { "field": "type", "equals": "Microsoft.Network/virtualNetworks/subnets" }, { "not": { "field": "Microsoft.Network/virtualNetworks/subnets/networkSecurityGroup.id", "exists": "true" } } ] } ] }, "then": { "effect": "deny" } }, "parameters": {} }

With these two policies in place, subnets can no longer be deployed using the current azurerm provider. I understand there were Azure API bugs that pushed for the creation of azurerm_subnet_route_table_association and azurerm_subnet_network_security_group_association while deprecating route_table_id and network_security_group_id on the azurerm_subnet resource. Is this still an issue in the Azure API and do we have to wait for an upstream fix? If there is still no plan to provide this functionality within the azurerm provider, I'll also ask for a recommendation on what the alternatives are.

[tombuildsstuff]

:wave:

The azurerm_subnet_route_table_association resource exists to workaround failures at destroy-time, where it's possible to create resources but not destroy them - due to the design of the Azure API (which returns an error along the lines of InUseSubnetCannotBeDeleted during deletion).

Whilst we could look to reintroduce the older route_table_id field, supporting both this and the azurerm_subnet_route_table_association resource (or potentially as a separate resource) - but unfortunately this'd just reintroduce this issue during destroy-time and so ultimately isn't as quick a fix as it may appear.

Instead I've opened #9022 which looks to add an example of how to use Azure Policy with these "association" resources - which I'm going to close this issue in favour of, would you mind subscribing to that issue for updates?

Thanks!

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!