Application network security in Azure isn’t just about spinning up a couple of apps—it’s about carefully designing a network that isolates and protects your services while ensuring they can still talk to each other. In a recent Medium post, Bob Code takes us on a hands-on journey through configuring subnets, endpoints, DNS, and NSGs with Terraform. He not only walks through the code but also explains the rationale behind Azure’s recommended security blueprint. Let’s break down the key insights and explore the broader implications for Windows and cloud administrators.
• Helps isolate workloads
• Reduces the attack surface by only exposing necessary endpoints
• Simplifies applying security policies on a per-service basis
Bob Code’s example creates two separate function apps housed within their own subnets. This design serves as a starting point for better network security. The Terraform code creates a virtual network (vnet) along with subnets to ensure that even though the two apps reside in the same vnet, they communicate only through their designated channels.
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" {
This snippet (and its counterpart for app2) sets up the groundwork for deploying your applications securely on Azure. The use of Terraform code ensures that these configurations are both reproducible and maintainable—a critical requirement for any production environment.
• IP allocation
• Routing
• Conflict prevention
• Policy application
Bob Code’s updated Terraform code for subnets includes a delegation block. When you delegate a subnet to a specific service (for example, Microsoft.Web/serverFarms for Azure functions), Azure enforces service-specific rules that streamline network management. However, there’s a catch: once a subnet is delegated, certain functionalities, like attaching private endpoints, become restricted.
For example, without delegation, your service subnet might be fine. But if you try to add a private endpoint directly to it, you’ll encounter an error because Azure won’t allow private endpoints in a subnet that’s already been delegated. This scenario is a classic reminder: with great power (delegation) comes some limitations.
However, as Bob Code’s article highlights, if you try to attach a private endpoint to a subnet already dedicated (delegated) to a service like Azure Functions, you’ll hit this error:
"Private endpoint ... cannot be created as subnet ... is delegated."
This limitation is by design. Delegated subnets are reserved exclusively for their assigned services, preventing conflicts and ensuring dedicated resources for service-specific management.
• Your application services (in delegated subnets) remain isolated and benefit from Azure-managed policies.
• Private endpoints get their own dedicated network space, enabling secure linkages without stepping on the toes of delegated configurations.
Here’s a snippet of how this subnet for private endpoints might look:
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" {
This approach ensures that private endpoints function without conflict, preserving the integrity of the delegated subnets while still allowing a secure, private connection. It’s a clear reminder that sometimes separating concerns—whether in code or network architecture—is the best strategy.
Azure Private Link is a game-changer for Windows users and administrators looking to secure PaaS services like SQL Server, Storage accounts, or App Services. By using Private Link, you avoid exposing sensitive data to the public internet, thereby significantly mitigating the risk of external breaches.
In addition to security, Private Link simplifies network management. It abstracts the complexity behind secure connections, reducing the need for intricate firewall rules or complicated routing logic. For IT professionals managing a hybrid environment, this efficiency translates directly into easier maintenance and stronger security postures.
Key benefits of NSGs include:
• Granular traffic filtering based on source, destination, port, and protocol
• Simplified administration of network security policies
• The ability to apply policies at both the subnet and resource level
In an environment where you’re using Terraform to automate your deployments, integrating NSG configurations is a best practice. Whether you’re having internal communication between apps or restricting external traffic, NSGs help ensure that only authorized traffic gets through. Their pairing with delegated subnets and dedicated private endpoint subnets reinforces a robust security strategy.
Key takeaways for Windows and Azure users include:
• Segregation is key—separate different services into their own subnets to reduce the attack surface.
• Use subnet delegation to allow Azure to automatically manage networking rules, but be mindful of its limitations regarding private endpoints.
• When creating private endpoints, allocate a dedicated subnet to avoid conflicts and ensure private connectivity.
• Leverage Azure Private Link to build secure, private connections between your services, keeping all traffic off the public internet.
• Incorporate NSGs for an added layer of security, filtering traffic and enforcing company policies with precision.
In today’s cloud-first world, designing a secure network isn’t optional—it’s essential. While the technical details might seem overwhelming at first, careful planning and automation with Terraform can dramatically simplify this process. And as always, while there’s always room for more robust solutions, the architecture outlined here provides a secure foundation for modern cloud applications.
By adopting these best practices, you not only improve the security posture of your applications but also streamline maintenance and operations in an increasingly competitive digital landscape. As Microsoft and Azure continue to evolve, staying ahead of security trends and adapting your architecture accordingly will be essential for long-term success.
Short, sweet, and secure—this robust setup reminds us all that the best defense in digital architecture is smart, deliberate design combined with powerful, built-in cloud capabilities.
Source: Medium
Segregating Your Application with Subnets in Azure
Azure’s blueprint for securing applications starts with the principle of segregation. Instead of lumping all your services into one network space, Azure recommends placing each service in its own subnet. This separation:• Helps isolate workloads
• Reduces the attack surface by only exposing necessary endpoints
• Simplifies applying security policies on a per-service basis
Bob Code’s example creates two separate function apps housed within their own subnets. This design serves as a starting point for better network security. The Terraform code creates a virtual network (vnet) along with subnets to ensure that even though the two apps reside in the same vnet, they communicate only through their designated channels.
Setting Up the Foundation Using Terraform
The initial Terraform code demonstrates how to deploy two applications using Azure Functions in a controlled environment. The code snippets include resource definitions for storage accounts, service plans, and the two function apps. Here’s an abbreviated look at what the initial setup might involve: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
app_settings = {
"WEBSITE_RUN_FROM_PACKAGE" = "1"
"WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED" = "1"
}
}
This snippet (and its counterpart for app2) sets up the groundwork for deploying your applications securely on Azure. The use of Terraform code ensures that these configurations are both reproducible and maintainable—a critical requirement for any production environment.The Role of Subnet Delegation
Deploying services into a subnet is one thing—making sure that Azure applies the correct network policies automatically is another. That’s where subnet delegation comes into play. Subnet delegation in Azure automates:• IP allocation
• Routing
• Conflict prevention
• Policy application
Bob Code’s updated Terraform code for subnets includes a delegation block. When you delegate a subnet to a specific service (for example, Microsoft.Web/serverFarms for Azure functions), Azure enforces service-specific rules that streamline network management. However, there’s a catch: once a subnet is delegated, certain functionalities, like attaching private endpoints, become restricted.
For example, without delegation, your service subnet might be fine. But if you try to add a private endpoint directly to it, you’ll encounter an error because Azure won’t allow private endpoints in a subnet that’s already been delegated. This scenario is a classic reminder: with great power (delegation) comes some limitations.
Private Endpoints: A Double-Edged Sword
A private endpoint gives your Azure service a private IP address from your virtual network, allowing secure communication over the Azure backbone rather than the public internet. Think of it as giving your application a secret handshake that’s recognized only within your trusted environment.However, as Bob Code’s article highlights, if you try to attach a private endpoint to a subnet already dedicated (delegated) to a service like Azure Functions, you’ll hit this error:
"Private endpoint ... cannot be created as subnet ... is delegated."
This limitation is by design. Delegated subnets are reserved exclusively for their assigned services, preventing conflicts and ensuring dedicated resources for service-specific management.
Creating a Dedicated Subnet for Private Endpoints
The natural solution? Create a dedicated subnet just for private endpoints. In the Terraform code, Bob Code addresses this by introducing a new subnet (say, subnet3) that isn’t subject to service delegation. This design separation means:• Your application services (in delegated subnets) remain isolated and benefit from Azure-managed policies.
• Private endpoints get their own dedicated network space, enabling secure linkages without stepping on the toes of delegated configurations.
Here’s a snippet of how this subnet for private endpoints might look:
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
}
This approach ensures that private endpoints function without conflict, preserving the integrity of the delegated subnets while still allowing a secure, private connection. It’s a clear reminder that sometimes separating concerns—whether in code or network architecture—is the best strategy.The Power of Azure Private Link
Once the private endpoints are set up, the next step is connecting them to the applications through Azure Private Link. In simple terms, Azure Private Link creates a private connection between your private endpoint and the Azure service. This full integration ensures that communication travels exclusively over the secure Azure backbone.Azure Private Link is a game-changer for Windows users and administrators looking to secure PaaS services like SQL Server, Storage accounts, or App Services. By using Private Link, you avoid exposing sensitive data to the public internet, thereby significantly mitigating the risk of external breaches.
In addition to security, Private Link simplifies network management. It abstracts the complexity behind secure connections, reducing the need for intricate firewall rules or complicated routing logic. For IT professionals managing a hybrid environment, this efficiency translates directly into easier maintenance and stronger security postures.
Emphasizing Network Security Groups (NSGs)
While the article’s focus is on subnets, endpoints, and DNS configuration, it’s worth taking a moment to consider the role of Network Security Groups (NSGs). NSGs are your front-line defenders—they control inbound and outbound traffic to your subnets and resources.Key benefits of NSGs include:
• Granular traffic filtering based on source, destination, port, and protocol
• Simplified administration of network security policies
• The ability to apply policies at both the subnet and resource level
In an environment where you’re using Terraform to automate your deployments, integrating NSG configurations is a best practice. Whether you’re having internal communication between apps or restricting external traffic, NSGs help ensure that only authorized traffic gets through. Their pairing with delegated subnets and dedicated private endpoint subnets reinforces a robust security strategy.
Testing and Validating Your Network Design
After setting up your infrastructure using Terraform, testing becomes critical. Bob Code touches on testing connectivity between the apps via the private endpoints. Here are some testing points you should consider:- Validate that your function apps are correctly deployed within their respective subnets.
- Confirm that the dedicated private endpoint subnet is functioning and correctly forwarding requests.
- Use network diagnostic tools available in Azure to monitor traffic flow.
- Ensure that NSG rules (if applied) are correctly enforcing security without interrupting legitimate communication.
Conclusion: Balancing Functionality and Security
Bob Code’s deep dive into application network security using Terraform on Azure serves as a practical guide for both new and seasoned cloud professionals. By carefully segregating applications into dedicated subnets, implementing delegation for service-specific policies, and establishing dedicated spaces for private endpoints, administrators can construct an environment where security is baked in from day one.Key takeaways for Windows and Azure users include:
• Segregation is key—separate different services into their own subnets to reduce the attack surface.
• Use subnet delegation to allow Azure to automatically manage networking rules, but be mindful of its limitations regarding private endpoints.
• When creating private endpoints, allocate a dedicated subnet to avoid conflicts and ensure private connectivity.
• Leverage Azure Private Link to build secure, private connections between your services, keeping all traffic off the public internet.
• Incorporate NSGs for an added layer of security, filtering traffic and enforcing company policies with precision.
In today’s cloud-first world, designing a secure network isn’t optional—it’s essential. While the technical details might seem overwhelming at first, careful planning and automation with Terraform can dramatically simplify this process. And as always, while there’s always room for more robust solutions, the architecture outlined here provides a secure foundation for modern cloud applications.
By adopting these best practices, you not only improve the security posture of your applications but also streamline maintenance and operations in an increasingly competitive digital landscape. As Microsoft and Azure continue to evolve, staying ahead of security trends and adapting your architecture accordingly will be essential for long-term success.
Short, sweet, and secure—this robust setup reminds us all that the best defense in digital architecture is smart, deliberate design combined with powerful, built-in cloud capabilities.
Source: Medium
