Securing Azure Applications: Network Segmentation & Terraform Best Practices

Securing your Azure applications isn’t just about locking the front door—it’s about architecting a fortress where each service has its own dedicated chamber. In today’s deep-dive, we unravel how Azure’s networking features—subnets, service delegations, private endpoints, and Private Link—combine with Terraform’s automation prowess to create a hardened application network.

The Need for Network Segmentation in Azure​

Azure’s recommended approach is as pragmatic as it is secure: segregate application components into dedicated subnets. When you deploy apps (such as Azure Function Apps or App Services) into isolated subnets, you control access on a granular level. The benefits are numerous:
• Isolation of services to prevent lateral movement in case of breaches
• Simplified management of routing and security policies
• Reduced risk of accidental exposure through shared network resources
In our case study, two distinct applications are each placed in their own subnet within a virtual network. While they reside in the same overarching network space (for example, using an address space like 10.0.0.0/16), each service operates within its own slice—such as 10.0.1.0/24 and 10.0.2.0/24. This approach echoes the best practices outlined in Microsoft documentation and helps ensure that your Windows-based services and backend integrations remain tightly controlled.

Terraform-Powered Deployment: A Code Walkthrough​

Terraform code makes it easier to manage these segmented deployments consistently. Consider a scenario where you’re deploying resources including a storage account, a service plan, and Windows Function Apps. The code defines a virtual network alongside two subnets:
• The virtual network (vnet) is declared with an address space like 10.0.0.0/16
• Two subnets (subnet1 and subnet2) are created for separate apps, each with its own address range
When you assign a Function App to a specific subnet using the virtual_network_subnet_id property, you’re effectively channeling traffic through that isolated segment. However, during deployment, an error might pop up:
  "PrivateEndpointCreationNotAllowedAsSubnetIsDelegated"
This error is a direct consequence of Azure’s restrictions. When a subnet is delegated to a service (in this example, Microsoft.Web/serverFarms for our Function Apps), it’s exclusively configured for that service type. Adding a Private Endpoint to such a subnet is akin to trying to mix oil and water—it just doesn’t work.

Code Insights: Delegation and the Private Endpoint Dilemma​

Here’s the typical Terraform snippet for subnet delegation:
  resource "azurerm_subnet" "subnet1" {
   name = "subnet1"
   resource_group_name = azurerm_resource_group.rg.name
   virtual_network_name = azurerm_virtual_network.vnet.name
   address_prefixes = [ "10.0.1.0/24" ]
   delegation {
    name = "delegation"
    service_delegation {
     name = "Microsoft.Web/serverFarms"
     actions = [
      "Microsoft.Network/virtualNetworks/subnets/join/action",
      "Microsoft.Network/virtualNetworks/subnets/prepareNetworkPolicies/action"
     ]
    }
   }
  }
Delegation tells Azure that the subnet is dedicated for specific services and automatically applies networking rules such as IP allocation, routing, and conflict prevention. This is invaluable when managing multiple services, but it becomes a roadblock if you try to mix in private endpoints, which also require a dedicated network interface (NIC) attached to them.
The solution? Always separate the lanes. Instead of trying to attach private endpoints within the delegated subnets, create an entirely new subnet—say subnet3 (perhaps using 10.0.3.0/24)—solely for hosting your private endpoints:
  resource "azurerm_subnet" "subnet3" {
   name = "subnet3"
   resource_group_name = azurerm_resource_group.rg.name
   virtual_network_name = azurerm_virtual_network.vnet.name
   address_prefixes = [ "10.0.3.0/24" ]
  }
Then, assign your private endpoint resources to subnet3. This dedicated separation not only resolves Azure’s restrictions but also enhances clarity in your infrastructure design.

Private Endpoints and Azure Private Link: Locking Down Connectivity​

A private endpoint in Azure is essentially a private IP address from your virtual network assigned to a specific Azure service. When you deploy a private endpoint, Azure automatically provisions a network interface with its own IP, ensuring that traffic to your service doesn’t traverse the public internet. But there’s a twist: if you place this endpoint in a subnet already delegated to another service, Azure will reject the configuration.
This is where Azure Private Link comes into play. Private Link connects your private endpoint to the actual Azure service over the Azure backbone network. Think of it as a dedicated tunnel that securely bridges your application with the service—bypassing the public internet entirely.
By creating a dedicated subnet for private endpoints and then configuring Private Link, you ensure that your services remain communicable with each other in a secure, closed-loop. This setup not only enhances security but also streamlines management since all private communication occurs over a fault-tolerant, dedicated network path.

Best Practices for Azure Application Network Security​

When designing your network architecture in Azure with Terraform, consider these best practices:
• Use separate subnets for service deployments and private endpoints.
• Delegate subnets specifically for services, leveraging Azure’s automatic IP allocation and routing features.
• Configure Network Security Groups (NSGs) and private DNS settings (like A records) to further refine access controls.
• Test inter-service communication thoroughly to ensure that private endpoints and Private Links are set up correctly.
• Keep your Terraform code modular—this makes it easier to adjust configurations as your application scales.
These guidelines help fortify your application’s network, reducing attack surfaces while maintaining streamlined connectivity between services.

Summing It Up​

In essence, effective network security on Azure demands meticulous planning and a keen understanding of how its various components interact. By using Terraform to orchestrate your Azure deployments, you not only automate the process but also enforce best practices like segregation of subnets, proper delegation for service-specific resources, and the dedicated use of private endpoints for secure connectivity.
This blueprint exemplifies how to balance flexibility with security. Much like designing a modern mansion with dedicated wings for different functions, a well-planned Azure network ensures each component is both secure and efficiently accessible.
Got thoughts on the approach? Does your organization have a unique twist on implementing Azure network security? Share your experiences and join the conversation as we keep our applications—and our networks—as secure as Fort Knox while running smooth on Windows.
Happy securing, and may your pipelines always be free of errors!

---

Source: Medium