Securing Your Application Network in Azure with Terraform

In today’s cloud-first era, ensuring your application’s network remains secure is paramount. While deploying your app to Azure is a significant achievement, the real challenge lies in protecting it from unauthorized access while still allowing robust inter-service communication. In this detailed exploration, we delve into securing your application network in Azure using Terraform. By examining the design and code logic from a recent comprehensive guide, we’ll walk through the practical aspects of subnets, private endpoints, DNS configurations, and network security groups (NSGs).

---

Securing Your Azure Network: The Blueprint​

Azure’s recommended approach emphasizes segmentation. Instead of having a flat network where every service can reach all others, the strategy is to isolate components into dedicated subnets. This helps manage access at a granular level—allowing only the required communications between services while blocking unnecessary traffic.
Imagine you have two services that need to talk to each other. Instead of lumping them together in one network, you deploy them into separate subnets. This setup bolsters security by applying policies tailored to each subnet, thereby reducing the attack surface.

---

Getting Started with Terraform​

Terraform makes infrastructure as code (IaC) a reality. Using simple configuration files, you can provision the required Azure resources and define their relationships. Let’s break down some key Terraform code snippets from the guide:

Creating Core Azure Resources​

The initial step involves setting up the basic building blocks. Here, we create:

• A storage account
• A service plan (for hosting function apps)
• Two function apps, each in its own subnet

Below is a simplified excerpt illustrating the creation of the function apps:

---

resource "azurerm_storage_account" "sa1" {
name = "dnsexamplesa"
resource_group_name = azurerm_resource_group.rg.name
location = azurerm_resource_group.rg.location
account_tier = "Standard"
account_replication_type = "LRS"
}
resource "azurerm_service_plan" "asp" {
name = "dns-asp"
resource_group_name = azurerm_resource_group.rg.name
location = azurerm_resource_group.rg.location
os_type = "Windows"
sku_name = "P1v2"
}
resource "azurerm_windows_function_app" "app1" {
name = "dns-app1"
resource_group_name = azurerm_resource_group.rg.name
location = azurerm_resource_group.rg.location
storage_account_name = azurerm_storage_account.sa1.name
storage_account_access_key = azurerm_storage_account.sa1.primary_access_key
service_plan_id = azurerm_service_plan.asp.id
virtual_network_subnet_id = azurerm_subnet.subnet1.id
site_config {
application_stack {
dotnet_version = "v8.0"
}
cors {
allowed_origins = ["Microsoft Azure"]
support_credentials = true
}
}
app_settings = {
"WEBSITE_RUN_FROM_PACKAGE" = "1"
"WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED" = "1"
}
}
resource "azurerm_windows_function_app" "app2" {
name = "dns-app2"
resource_group_name = azurerm_resource_group.rg.name
location = azurerm_resource_group.rg.location
storage_account_name = azurerm_storage_account.sa1.name
storage_account_access_key = azurerm_storage_account.sa1.primary_access_key
service_plan_id = azurerm_service_plan.asp.id
virtual_network_subnet_id = azurerm_subnet.subnet2.id

site_config {
application_stack {
dotnet_version = "v8.0"
}
cors {
allowed_origins = ["Microsoft Azure"]
support_credentials = true
}
}
app_settings = {
"WEBSITE_RUN_FROM_PACKAGE" = "1"
"WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED" = "1"
}
}​

These code blocks set the stage for our secure network setup. Each function app is attached to the respective subnet of a virtual network (vNet), which is created subsequently.

---

Network Segmentation with Virtual Networks and Subnets​

The next logical step is designing the network segmentation. In Azure, a virtual network provides isolation and control, and subnets allow you to compartmentalize services further. Here’s how the virtual network and its subnets are declared:

---

resource "azurerm_virtual_network" "vnet" {
name = "dns-vnet"
location = azurerm_resource_group.rg.location
resource_group_name = azurerm_resource_group.rg.name
address_space = ["10.0.0.0/16"]
}
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"]
}

resource "azurerm_subnet" "subnet2" {
name = "subnet2"
resource_group_name = azurerm_resource_group.rg.name
virtual_network_name = azurerm_virtual_network.vnet.name
address_prefixes = ["10.0.2.0/24"]
}​

Here, each function app is isolated in its respective subnet. But merely placing them in subnets doesn’t guarantee a foolproof configuration; further steps are needed to enforce network security policies.

---

The Role of Subnet Delegation​

A recurring error many developers encounter when setting up Azure resources with Terraform is the “missing delegation” error. But what exactly is subnet delegation, and why is it important?
Subnet delegation assigns a subnet exclusively to a specific Azure service. In our context, delegation ensures the designated subnet is correctly configured for Azure App Services (such as Function Apps). This achieves several key objectives:
• IP Allocation – Azure takes over assigning and reserving IP addresses automatically.
• Routing – Azure manages routing rules, reducing the need for manual configuration.
• Conflict Prevention – By limiting the types of resources that can be deployed in the subnet, Azure minimizes the risk of conflicts.
• Policy Enforcement – Azure applies service-specific network policies seamlessly.
Without delegation, even if your function apps reside in the right subnets, Azure will not enforce the recommended policies. Here’s how you update the subnet code to add service delegation for your applications:

---

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"
]
}
}
}
resource "azurerm_subnet" "subnet2" {
name = "subnet2"
resource_group_name = azurerm_resource_group.rg.name
virtual_network_name = azurerm_virtual_network.vnet.name
address_prefixes = ["10.0.2.0/24"]

delegation {
name = "delegation"
service_delegation {
name = "Microsoft.Web/serverFarms"
actions = [
"Microsoft.Network/virtualNetworks/subnets/join/action",
"Microsoft.Network/virtualNetworks/subnets/prepareNetworkPolicies/action"
]
}
}
}​

By delegating your subnets to Microsoft.Web/serverFarms, you ensure that policies and routing are managed automatically, streamlining the overall security posture.

---

Private Endpoints: Locking Down the Traffic​

You might ask, “Once my apps are secure within isolated subnets, how do they communicate with each other privately?” This is where private endpoints (PE) step into the picture. Private endpoints assign your Azure service a private IP address from your vNet, effectively acting as a secure bridge between your app and the underlying Azure service.

Understanding the Error: Delegation vs. Private Endpoints​

A common pitfall is attempting to deploy private endpoints within subnets that are already delegated. For example, if you try to attach a private endpoint directly to subnet1 (delegated to Microsoft.Web/serverFarms), you’ll encounter an error like:
  PrivateEndpointCreationNotAllowedAsSubnetIsDelegated
The error occurs because delegated subnets are reserved exclusively for their assigned services. To overcome this, you need a dedicated subnet for private endpoints. Here’s the Terraform code to add a new subnet for 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"]
}​

Now, you can safely deploy your private endpoints into this dedicated subnet:

---

resource "azurerm_private_endpoint" "app1_pe" {
name = "app1-pe"
location = azurerm_resource_group.rg.location
resource_group_name = azurerm_resource_group.rg.name
subnet_id = azurerm_subnet.subnet3.id
}

resource "azurerm_private_endpoint" "app2_pe" {
name = "app2-pe"
location = azurerm_resource_group.rg.location
resource_group_name = azurerm_resource_group.rg.name
subnet_id = azurerm_subnet.subnet3.id
}​

By segregating private endpoints into their own subnet, you prevent conflicts between delegated services and privately accessible resources.

---

Azure Private Link: Bridging the Gap​

Once you have private endpoints in place, the next link in the chain is Azure Private Link. This feature is vital for securely connecting private endpoints to their target Azure services using the Azure backbone network. It allows for streamlined connectivity without exposing services publicly.
In essence, Azure Private Link mediates traffic between your private endpoint and the corresponding Azure service (like App Service or Azure SQL Database). This mechanism ensures that your application’s traffic is entirely contained within the secure boundaries of the Azure network.

---

DNS and Network Security Groups (NSGs): Putting the Finishing Touches​

While subnets, delegation, and private endpoints provide the framework for secure communication, DNS and NSGs add additional layers of security and manageability.

DNS Configuration​

Utilize Azure Private DNS to handle the domain resolution between services using private endpoints. By configuring private DNS zones, you can ensure that your services resolve to internal IP addresses instead of their public counterparts. This further protects your application by avoiding unnecessary exposure to the public internet.

Network Security Groups (NSGs)​

NSGs act as virtual firewalls at the subnet level. By defining NSG rules, you can restrict inbound and outbound traffic, thereby eliminating potential attack vectors. For instance, you might configure NSG rules to allow only HTTPS traffic from known sources or to restrict communication to certain IP ranges. Strategically applying these rules across subnets ensures that while your services can communicate privately, their exposure to the external network is minimized.

---

Testing and Troubleshooting​

After setting up the infrastructure, thorough testing is paramount to ensure everything works as expected. Common points of validation include:
• Confirming that function apps in their respective subnets communicate correctly without exposing unwanted traffic.
• Verifying that private endpoints are properly allocated within their dedicated subnet.
• Testing the DNS resolution to ensure that internal names resolve to the intended private IP addresses.
Understanding the interplay between subnet delegation and private endpoints can be tricky. For example, the error indicating that a subnet delegated to Microsoft.Web/serverFarms cannot host a private endpoint reminds developers of the importance of isolating network functions into their respective subnets.
If issues arise, reviewing the Terraform state and Azure logs can help pinpoint misconfigurations. Don't be afraid to dive into Azure documentation for nuances on delegation, Private Link, and NSG configurations.

---

Best Practices and Next Steps​

For IT professionals managing Windows workloads on Azure, consider the following best practices:
• Segregate resources: Always use dedicated subnets for distinct functions (e.g., one for delegated services and another for private endpoints).
• Use Terraform consistently: Leverage IaC to ensure configurations are reproducible and version controlled.
• Keep NSGs updated: Regularly review your NSG rules to adapt to evolving security requirements.
• Monitor DNS resolutions: Misconfigurations here can disrupt inter-service communication.
• Test thoroughly: Validate the end-to-end security of your app with both automated tests and manual verifications.
By adhering to these practices, you’re not just deploying secure applications; you’re laying down the groundwork for resilient, scalable architectures.

---

Conclusion​

Securing application network traffic in Azure involves more than just deploying compute resources. It requires a careful orchestration of virtual networks, subnets, delegation, private endpoints, DNS, and NSGs. Using Terraform to define and deploy these configurations not only standardizes your infrastructure but also streamlines the process of enforcing best practices across your environment.
The detailed walkthrough provided here highlights the importance of segregating services into different subnets, the nuanced role of subnet delegation, and the essential nature of private endpoints paired with Azure Private Link. By following these guidelines and integrating continuous testing, you can build secure, isolated, and resilient application architectures on Azure.
Whether you’re a seasoned IT professional or just embarking on your cloud security journey, these insights offer practical steps to bolster your Azure network security. What strategies have you found effective in securing your application’s network? Feel free to share your experiences and lessons learned!

---

In a world where digital threats evolve rapidly, keeping your Windows and Azure environments secure with robust, best-practice configurations remains the cornerstone of enterprise IT. Happy coding and secure networking!

---

Source: Medium