Exploring Hub and Spoke Topology: Private Endpoints
In the Microsoft cloud security benchmark NS-2, it states:
"Use service native features to secure network access to the resources to avoid and reduce the exposure of the resources to the untrusted network."
You have to make your resources off the public internet as much as you can. But why?
A Deep Dive into Topology
A typical Azure network follows a hub-spoke topology for three simple reasons:
Security
Routing 3. Scalability
Creating a chokepoint helps to control all traffic in your tenant. Imagine it as roadblocks; yes, you can pass them if you are not breaking the law.
A hub-spoke topology separates management and workloads into two distinct roles:
The Hub: Our "Security Screening" into the network.
The Spokes: Our "Departure Gates."
All spokes are connected to the hub, but spokes themselves are not connected to each other directly. We do this for a couple of reasons:
We want to monitor and check all traffic, both inbound and outbound.
If a spoke is hacked, the threat actor does not have a direct path to all other spokes, preventing the whole network from being compromised.
The Role of Network Virtual Appliances (NVAs)
In our hub, we have multiple Network Virtual Appliances (NVAs). NVAs are used to control the flow of traffic between network segments that have different security levels. These include:
Azure Firewall
Private DNS Zones
Public DNS Zones
NAT Gateways
Load Balancers
For now, let's focus on having a firewall. In the picture below, we can see our topology:
You can see spokes peered to the hub VNet but not peered to each other. The firewall here helps with security and with routing; using firewall rules, we can route traffic between our spokes.
Why not put everything in one VNet?
Using one VNet for all your resources undermines the architectural benefits of isolation and scale. Although you have subnets, it becomes a mess, and there will never be enough space for all resources in a corporate topology.
By using the hub-spoke topology, we can:
Easily manage each network/subnet.
Scale for more workloads.
Maintain granular control (a VNet for each workload).
Ensure all traffic goes through the firewall.
Implementation: Routing and Integration
For traffic from the spokes to reach the firewall, we have to deploy a Route Table and add User Defined Routes (UDRs) in it, then link the route table to our subnets.
App Services are PaaS offerings, which means they can't access resources in our VNet by default. To enable communication, we use VNet Integration, which gives your app access to resources in your virtual network but doesn't grant inbound private access to your app from the virtual network.
Objectives
In this setup, we have two primary objectives:
Allow public traffic to the web app.
Allow private connection from the web app to the Key Vault.
Problem 1: Routing Public Traffic
What may be a problem is routing App Services through our firewall because we want the web app to be accessible through the internet.
Network rules help us with this. Usually, the optimal solution is using an Application Gateway. It operates at Layer 7, allowing for URL filtering, session affinity, SSL offloading, and other features.
In your network rules, add the IP of your Application Gateway or * as your source and your app's outbound addresses as the destination. This way, your app is accessible publicly without compromising security or scalability.
Problem 2: Secure Access to Key Vault
Our App Service requires access to the SQL database, but the password is stored inside the Key Vault. We want it to access it only through Microsoft's backbone network with no public access.
Here come Private Endpoints (PEP), which create a Network Interface Card (NIC) into the subnet we want, making it accessible privately. The same Private Endpoint logic applies to the SQL database itself, but let's look at the Key Vault as our primary example.
To solve this:
Create a PEP and a Managed Identity for your app with a role to read secrets.
Managed System Identities enable resources to have RBAC / Custom roles like any user in your tenant.
By default, a PEP comes with a Private DNS Zone, so you just have to link it to your VNet and set the destination to the Key Vault's FQDN.
Note: Don't forget to disable public access on your Key Vault.
Conclusion
So there you have it, your web app is publicly accessible through the Application Gateway, but your Key Vault and SQL database are completely isolated from the internet. That's NS-2 in action.
Start with the hub-spoke topology, add your firewall and routing rules, then lock down your sensitive resources with private endpoints. Just remember: if it doesn't need public access, don't give it public access.
Last updated