[Module Proposal]: `avm-ptn-subnets-nsgs-routes`

[kewalaka]

Check for previous/existing GitHub issues/module proposals

• [X] I have checked for previous/existing GitHub issues/module proposals.

Check this module doesn't already exist in the module indexes

• [X] I have checked for that this module doesn't already exist in the module indexes.

Bicep or Terraform?

Terraform

Module Classification?

Pattern Module

Module Name

avm-ptn-subnets-nsgs-routes

Module Details

This is a proposal for Pattern Module for creating subnets with network security group & route tables either created inline or supplied to the module.

The concept of this pattern module is to make it easier for workload teams, given a vnet by the platform team, to be able to create resource networking.

Teams can optionally bring existing route tables or NSGs (pass in by resource ID), or they can be created in this module, in which case the subnet is connected to the route table or NSG via the map key.

There is an implementation here passing deployment tests; https://github.com/kewalaka/terraform-azurerm-avm-ptn-subnets-nsgs-routes

Example usage:

locals {
  subnets = {
    snet0 = {
      name                       = "${module.naming.subnet.name_unique}0"
      address_prefixes           = ["10.0.0.0/24"]
      network_security_group_key = "nsg0"
      route_table = {
        id = azurerm_route_table.this.id
      }
    },
    snet1 = {
      name                       = "${module.naming.subnet.name_unique}1"
      address_prefixes           = ["10.0.1.0/24"]
      network_security_group_key = "nsg0"
      route_table_key            = "rt0"
    },
    snet2 = {
      name             = "${module.naming.subnet.name_unique}2"
      address_prefixes = ["10.0.2.0/24"]
      delegation = [{
        name = "Microsoft.Web.serverFarms"
        service_delegation = {
          name = "Microsoft.Web/serverFarms"
        }
      }]
    }
  }

  network_security_groups = {
    nsg0 = {
      name = module.naming.network_security_group.name_unique
      security_rules = {
        "http_inbound" = {
          "access"                     = "Allow"
          "name"                       = "httpInbound"
          "direction"                  = "Inbound"
          "priority"                   = 150
          "protocol"                   = "Tcp"
          "source_address_prefix"      = "*"
          "source_port_range"          = "*"
          "destination_address_prefix" = "*"
          "destination_port_ranges"    = [80, 443]
        }
      }
    }
  }

  route_tables = {
    rt0 = {
      name = "${module.naming.route_table.name_unique}-created"
      routes = {
        address_prefix = "1.2.3.4/24"
        name           = "${module.naming.route.name_unique}-created"
        next_hop_type  = "Internet"
      }
    }
  }
}

module "networking" {
  source = "../../"
  # source                      = "Azure/avm-ptn-subnets-nsgs-routes/azurerm"
  # version                     = "..."
  location                    = azurerm_resource_group.this.location
  resource_group_name         = azurerm_resource_group.this.name
  virtual_network_resource_id = azurerm_virtual_network.this.id

  network_security_groups = local.network_security_groups
  route_tables            = local.route_tables
  subnets                 = local.subnets

}

Do you want to be the owner of this module?

No

Module Owner's GitHub Username (handle)

No response

(Optional) Secondary Module Owner's GitHub Username (handle)

kewalaka

[kewalaka]

example E2E run : https://github.com/kewalaka/terraform-azurerm-avm-ptn-subnets-nsgs-routes/actions/runs/9144797788/job/25143075907

[prjelesi]

@kewalaka tnx, lets find module owner.

[matt-FFFFFF]

Hi I thought this was going to be part of the vnet module.

Why do we need this pattern?

[kewalaka]

Hi I thought this was going to be part of the vnet module.

Why do we need this pattern?

The vnet module will do subnets, 💯

This is more,its all the subnet related things - allows routes,nsgs to be created too, or passed in as per the example in this issue

I found in the usage of nsgs routes and subnets there was repeated logic in workload modules to wire these things together. It makes the workload owner code much simpler - they don't need to worry about the locals mangling needed to wired up supplied components

Perhaps it needs a better name 😆

Out of curiosity, any comment the way I'm joining stuff by keys, a reasonable approach?

[kewalaka]

Clarifying more, this example does use the (not yet released) vnet module to make the subnets

https://github.com/kewalaka/terraform-azurerm-avm-ptn-subnets-nsgs-routes

It also uses the AVM nsg module, and the intention is to use the AVM route table when available

With configuration parameters (e.g, tfvars or yaml), you still need a way to link subnets to their associated route and nsg. With this module, you can either do that by specifying the key of the item, or to cater for scenarios where you need to use an existing item, you can pass in the resource id (in my case, the platform teams lays down a default route table to the fw appliance as part of vending, but we do want to give app owners the opportunity to override this).

It means the workload team can make a config of their subnets,routes and nsgs, and this module will wire it together for them.

Hope that helps.

[kewalaka]

avm-ptn-subnets-securityrules-routes
avm-ptn-subnets-nsgs-routes 
avm-ptn-subnet-networking

..any better?

It is recognised that I suck at naming things 😆

[ChrisSidebotham]

+1 to discuss this for the bicep side too as an extension to the sub vending approach, application teams will typically take control of their own virtual network.

[kewalaka]

picked a better name to disambiguate it from the vnet module, now:

https://github.com/kewalaka/terraform-azurerm-avm-ptn-subnets-nsgs-routes

[kewalaka]

+1 to discuss this for the bicep side too as an extension to the sub vending approach, application teams will typically take control of their own virtual network.

i agree but I find the opposite - contrary to guidance most platform teams seem either unwilling to let go of the subnet management side of things, and that is combined with a unwillingness on the app-owner side to deal with the networking.

For our vending we are using the ALZ approach to lay down the vnet, and the leveraging something like this to optionally lay down subnets, NSGs, routes. My aim is to support transition - so if and when teams do want to pick up subnet management, as I think they should, the approach allows for this.

[ChrisSidebotham]

Tagging @jaredfholgate for awareness

[kewalaka]

@jaredfholgate just clarifying this is built on the recent vnet module changes, its purpose is to help make it easier to create maps of nsgs, routes and subnets as configuration then have this module wire them together.

There are examples in my repo

https://github.com/kewalaka/terraform-azurerm-avm-ptn-subnets-nsgs-routes/tree/main/examples/subnets_nsgs_and_routes

It also uses the NSG AVM, and I plan to incorporate the route table AVM when available.

I built it as I had this same logic repeated in several app workloads and wanted to hide away the locals malarkey required to make the wiring up work.

[prjelesi]

@kewalaka let we have internal sync about this and i will get back to you.

[jaredfholgate]

Hi. @swathialuganti and @pavanmog have taken ownership of this module. Please could we get it added to the index? Thanks