Mastering Azure Network Security: Best Practices with Terraform

Securing your applications in the cloud is a bit like locking your front door—but still leaving a carefully controlled side entrance for your trusted friends. For anyone deploying apps in Azure, the challenge isn’t only about getting your service up and running; it’s about ensuring that your network stays secure while enabling secure communication between services. This deep dive into Azure network security, illustrated with Terraform code, brings together best practices around subnets, delegation, private endpoints, DNS, and NSGs.

Deploying Your Azure App with Terraform​

Imagine you’ve just deployed your app to Azure. You’ve got your storage account, service plan, and even your function apps running. But the question that immediately arises is: Who can access your app, and how can you control that access? In the example provided, the code deploys two Windows Function Apps—each tucked away in its own subnet of a virtual network. The Terraform snippets demonstrate how to create all the necessary resources:

• Storage Account & Service Plan: These form the bedrock of your application, ensuring that it has both the storage and compute resources needed.
• Function Applications: Configured with relevant settings (like .NET version and CORS policy) to ensure they’re production-ready.
• Virtual Network and Subnets: The apps are assigned to different subnets within a single virtual network (VNET), ensuring logical segmentation.

This modular approach not only organizes your resources but also sets the stage for stronger security controls down the line.

Azure Networking Fundamentals: VNETs, Subnets, and Delegation​

Azure’s blueprint for application security recommends isolating services within their own subnets. This means your two function apps reside under separate subnets, enabling you to tightly control which services can “talk” to each other. But as you might have experienced, deploying app services to a subnet without proper delegation is akin to leaving your door unlocked for everyone.

Why Subnet Delegation Matters​

When you receive an error like “Subnet in VNET is missing a delegation,” it’s Azure’s way of reminding you that specialized services—like App Services or Function Apps—require a dedicated set of rules to manage IP allocation, routing, conflict prevention, and policy enforcement. By including a delegation block in your subnet definition, you effectively tell Azure, “This subnet is reserved exclusively for a specific service type.”
Delegation handles several crucial tasks:

• IP Allocation: Automatically manages and reserves IP addresses.
• Routing: Ensures each service’s traffic is correctly directed.
• Conflict Prevention: Avoids IP conflicts by enforcing dedicated resource rules.
• Policy Enforcements: Applies security and network policies aligned with the service requirements.

For example, updating your Terraform code to include a delegation block for services like "Microsoft.Web/serverFarms" allows your Azure Function Apps to integrate seamlessly with the network configuration.

Private Endpoints and the Necessity for Dedicated Subnets​

A key part of securing your application network is limiting exposure through private endpoints (PEs). Think of a private endpoint as a specialized network interface that assigns a private IP to a service, ensuring that traffic flows through the secure channels of your VNET. However, there’s a twist: if you try to deploy a private endpoint in a subnet already delegated to another service (like Microsoft.Web/serverFarms), Azure will block your attempt with a frustrating error message.

The Private Endpoint Dilemma​

The error “PrivateEndpointCreationNotAllowedAsSubnetIsDelegated” is a clear indicator that Azure wants you to maintain separation of concerns. In other words, a subnet designated for delegated services isn’t the right home for a private endpoint. The solution? Create a dedicated subnet (say, subnet3) strictly for your private endpoints. This dedicated space prevents conflicts and ensures that Azure can manage routing and security policies properly.

Bridging the Gap with Azure Private Link​

Once you’ve isolated your private endpoints, the next step involves connecting them back to your application. Enter Azure Private Link—a service that acts as the secure conduit linking your private endpoint to the corresponding Azure service (like your function app). In the background, the private endpoint’s network interface uses Azure’s backbone network to forward requests securely to the target service. The result is a seamless, secure connection that remains completely isolated from public internet exposure.

Integrating DNS and Network Security Groups (NSGs)​

While the Terraform code highlights subnets, delegation, and private endpoints, the broader network security strategy often incorporates additional layers:

• Private DNS and A Records: By integrating DNS configurations, you ensure that your private endpoints are resolvable within your network using familiar naming conventions.
• Network Security Groups (NSGs): NSGs play a pivotal role in controlling traffic flow. They give you fine-grained control over inbound and outbound traffic, ensuring that only approved communication paths are open.

Although not fully detailed in the snippet above, these components are essential in a robust security framework. NSGs help in filtering external traffic while DNS management ensures that your services are easily and securely located within the private network.

Testing, Debugging, and Next Steps​

One of the strengths of using Terraform is the repeatability and visibility it provides during deployment. When you encounter errors—like trying to add a private endpoint to a delegated subnet—the error messages guide you toward the right architecture:

1. Deploy Your Baseline Resources: Start with your storage account, service plan, VNET, and function apps.
2. Apply Subnet Delegation: Ensure each subnet has the proper delegation block for services like Microsoft.Web/serverFarms.
3. Isolate Private Endpoints: Create a dedicated subnet for your private endpoints to avoid conflicts.
4. Test Connectivity: Once deployed, verify that your private endpoints correctly maintain a secure conduit via Azure Private Link.

This methodical approach not only downplays the risk of misconfiguration but also demonstrates the inherent agility of Terraform when managing complex Azure network architectures.

Final Thoughts​

Securing your application's network in Azure isn’t just about locking down external access—it’s about creating a well-architected, multi-layered defense in depth that allows your services to communicate securely. By using Terraform code to configure subnets, delegation, private endpoints, and integrating DNS and NSGs, you’re following a blueprint that aligns with best practices recommended by Microsoft.
The thoughtful separation of delegated subnets for app services and dedicated subnets for private endpoints underscores the importance of planning in network design. It’s a nimble dance between functionality and security—a balance every IT professional must master.
As you explore, experiment, and refine your configurations, remember: the goal is to create an environment where your application can thrive securely in today’s ever-evolving cloud landscape. Feel free to share your insights or any creative tweaks you’ve discovered along the way—the conversation is always richer when experts join in.

---

Source: Medium