Securing Azure Applications: A Comprehensive Guide to Network Security with Terraform

Deploying and securing an application in Azure is a bit like getting a brand-new sports car off the showroom floor—it looks fantastic and runs great, but you need to lock it up to keep the riffraff at bay. When you’ve just set up your Windows-based app in Azure using Terraform, the next challenge is protecting its network. Let’s break down how to use subnets, private endpoints, DNS, and NSGs to create a robust application network security posture in Azure.

Introduction​

Imagine you’ve just deployed your latest business-critical application in Azure. You’re proud of your work—until you wonder, “Is this app open for anyone to access?” The answer is an emphatic no. In today’s post, we dive into the architecture and Terraform code required to secure your application’s network in Azure, ensuring that only the right entities can communicate with each other while keeping external traffic firmly at bay.
We’ll explore:

• How segregating applications into separate subnets increases security.
• The role of subnet delegation.
• The importance of private endpoints and private links.
• How to configure DNS and network security groups (NSGs).
• Practical Terraform code examples to help you implement these features.

The Blueprint: Segregating Applications in Azure​

Azure’s recommended approach for network security involves isolating your app’s components across different subnets. This way, each service is effectively “caged” in its own compartment, making it harder for unwanted traffic to hop from one service to another. In our case, consider two services that need to talk to each other—but only on a need-to-know basis. This is achieved by placing them in separate subnets within the same virtual network (vnet).
The initial Terraform code might look something like this:

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](https://portal.azure.com)"]
      support_credentials = true
    }
  }
  app_settings = {
    "WEBSITE_RUN_FROM_PACKAGE"         = "1"
    "WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED" = "1"
  }
}

This code sets up two important pieces: your storage and service plan, followed by the deployment of your function apps. Each containerized app is then associated with its own subnet, establishing the foundation for a secured network.

Understanding Subnet Delegation​

When you place your app’s services into subnets, there’s an extra step required called subnet delegation. Think of it as designating a VIP area in your network where Azure enforces special rules on what can connect and what can’t. Delegation automatically manages:

• IP allocation: Reserving IPs and handling routing behind the scenes.
• Conflict prevention: Avoiding address or routing conflicts by ensuring exclusive use.
• Policy application: Automatically enforcing network and security policies for the delegated resources.

Without delegation, your function apps may throw errors or find themselves unprotected. For example, you might encounter an error like:
"Subnet dns-vnet in VNET is missing a delegation to…"
To rectify this, update your subnet configuration to include a delegation block. Here’s how you can adjust the code:

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"
      ]
    }
  }
}

With this change, your subnet is now explicitly prepared for hosting Azure App Service-related resources such as function apps and app service plans.

Private Endpoints and the Role of Private Links​

Once your apps are correctly isolated in subnets, the next challenge is ensuring secure communication. This is where private endpoints come into play. A private endpoint is simply a private IP address from your virtual network that connects to an Azure service – akin to a network interface card (NIC) that’s automatically configured when you establish the endpoint.
These endpoints are crucial because:

• They enable direct communication over a private network, entirely bypassing the public Internet.
• They simplify connectivity between services by automatically configuring the necessary IP settings and routing.

However, there’s a hiccup: if you try to attach a private endpoint directly into a subnet that’s already delegated for your function apps, Azure will object with an error similar to:
"Private endpoint ... cannot be created as subnet ... is delegated."
This is because delegated subnets are exclusively reserved for the specified Azure services. The solution? Allocate a dedicated subnet for your private endpoints. For example:

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" ]
}

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 endpoint traffic into its own subnet, you sidestep any conflicts with delegated subnets and ensure that traffic flows securely within Azure’s backbone network. The behind-the-scenes magic that connects your private endpoints with your apps is handled via Azure Private Link.

DNS, NSGs, and Managing External Traffic​

Once private endpoints are established, you’re left with one final piece of the security puzzle: ensuring that DNS and network security groups (NSGs) work their magic.

Private DNS and A Records​

Azure Private Link relies on Private DNS zones to resolve the private endpoint IP addresses. By properly associating a private DNS zone and creating the necessary A records, you guarantee that your app’s domain names resolve correctly to their private IP addresses on the Azure backbone. This eliminates the need for public DNS resolution and helps secure your connections further.

Network Security Groups (NSGs)​

Network Security Groups act as the gatekeepers for your virtual network. They enable you to define granular security rules that specify which traffic can flow to and from your subnets and resources. Integrating NSGs into your architecture ensures that external traffic is filtered based on your defined policies while allowing legitimate, internal communication.
Some best practices include:

• Deploying NSGs on both individual subnets and network interfaces.
• Defining rules to allow only trusted traffic, such as management traffic from trusted IP ranges.
• Regularly reviewing and updating NSG rules to reflect evolving security requirements.

Practical Implications and Best Practices​

Here’s a step-by-step breakdown to ensure your application network in Azure is secure:

1. Deploy your essential Azure services (storage, function apps, service plans) using Terraform.
2. Create a virtual network and segregate your services into separate subnets.
3. Enable subnet delegation for those subnets hosting Azure App Service resources.
4. Allocate a dedicated subnet for private endpoints to avoid conflicting with delegated subnets.
5. Configure Azure Private Link to ensure secure, private connectivity between your apps.
6. Set up Private DNS zones and A records for seamless resolution of private IPs.
7. Apply NSGs to filter external traffic and secure your network boundaries.

These steps not only prevent unauthorized access but also optimize the operational efficiency and security of your application network, making it a robust solution suitable for production environments.

Final Thoughts​

Network security in Azure, especially when orchestrated via Terraform, is all about precision and adherence to best practices. Delegated subnets, private endpoints, and the use of NSGs collectively create a multi-layered defensive strategy that aligns with Microsoft’s recommendations. As you might have noticed, errors like "PrivateEndpointCreationNotAllowedAsSubnetIsDelegated" serve as a stern reminder that mixing and matching network components without proper planning can lead to deployment headaches.
Have a look at your network design next time you deploy an app—are your subnets properly partitioned? Have you set aside the necessary space for private endpoints? And most importantly, are your NSGs up to the task of blocking unwanted traffic?
This comprehensive approach not only secures your application environment but also provides a clear roadmap for managing communication between different services. The next steps might involve layering additional security measures like enhanced logging, automated patching via Microsoft security patches, or even integration with other Azure security services.
For Windows enthusiasts and IT pros alike, mastering network security in Azure using Terraform is a critical skill set—one that not only keeps your apps safe but also ensures they run smoothly in today’s dynamic cloud environment.
What are your thoughts or experiences with securing application networks on Azure? Feel free to share your ideas and questions on this intricate balance between openness and security in our vibrant Windows community.

---

Source: Medium