iTranslated by AI
Combining Microsoft Entra Private Access with Hub-Spoke Architecture
TL;DR
- Wanted to try combining Microsoft Entra Private Access with Azure's Hub-spoke architecture
- Was able to control access to Spokes via identity (ID)
- This is exactly what Zero Trust Network Access is all about
Introduction
After investigating things like How Microsoft Entra Private Access bends packets (I didn't quite get it) and The Exit of Microsoft Entra Private Access, I've started to get a feel for how Microsoft Entra Private Access (MEPA) works. So, it's time to try out various architectures in a practical way. This time, I'll combine Azure's common Hub-spoke architecture with MEPA.
Azure's Hub-spoke Architecture
Let's briefly review Azure's Hub-spoke architecture.
Hub-spoke architecture
Hub-spoke network topology in Azure - Azure Architecture Center and other resources are helpful. This architecture consolidates connections to on-premises, internet ingress/egress, firewalls, NVAs, etc., into a Hub, while placing individual workloads in Spokes. By connecting the Hub and Spokes via VNet Peering, mutual communication can be enabled and controlled. In particular, services like ExpressRoute used for on-premises connectivity can be complex to operate and lead to increased costs if prepared for each system, so there is an intention to consolidate their use.
MEPA and Hub-spoke Architecture
As mentioned earlier, Hub-spoke consolidates on-premises connections into the Hub, and it's also possible to accept Point-to-Site VPN (P2S VPN) from individual PCs there.
In this article, instead of such a conventional common architecture, I'll consider using MEPA (specifically, its ZTNA capability) instead of P2S VPN.
Based on the Hub-spoke concept, I've decided to place the Microsoft Entra Private Access Connector (MEPA-C) in the Hub.
On top of that, I'll test whether access to the Spokes can be controlled using MEPA's features.
The Architecture for This Time
As the name suggests, this time I'll build a network that acts as a typical remote access source, like a home network, and a Hub-spoke architecture on the Azure side.
As mentioned earlier, a MEPA-C is deployed in the Hub, and Azure VMs are deployed in each of the two Spokes for communication verification.
remote-network-and-hub-spoke
Settings around Microsoft Entra Private Access Connector
While only one MEPA-C is deployed this time, within the Entra admin center, multiple units are treated collectively as a Connector group.
Also, for the ZTNA configuration, an Enterprise application is used, and by configuring the "Network access" property—one of its properties—you set whether to control traffic directed to specific IP addresses and port numbers.
Briefly, the flow involves having a MEPA-C group as a cluster of MEPA-Cs, associating an Enterprise application with that MEPA-C group, and then configuring the Network access property as part of that Enterprise application.
Microsoft Entra Private Access configuration model
An interesting aspect of the configuration is that the relationship between a MEPA-C group and Enterprise applications is not 1-to-1, but 1-to-many. In other words, you can associate multiple Enterprise applications with a single MEPA-C group.
Therefore, I thought that even with only one MEPA-C (or MEPA-C group), associating multiple Enterprise applications would enable access control for multiple Spokes.
That is, managing network access control for Spokes at the identity layer—this is precisely the true nature of a Zero Trust network.
Let's Try It Out
So, let's give it a try.
I've prepared "spoke01" with the address space 10.0.0.0/16 and "spoke02" with 10.10.0.0/16.
I also created two Enterprise applications: one corresponding to spoke01 and another for spoke02.
For each Enterprise application, I assigned users: "user01" for spoke01 and "user02" for spoke02.
The goal is for user01 to be able to access the Azure VM in spoke01, but not the Azure VM in spoke02.
First, let's open the Advanced Diagnostics screen.
I am logged in as user01, but even the 10.10.0.0/16 range, which is only permitted for user02, appears in this list.
GSA - Advanced diagnostics
Now, let's try to mstsc into that unauthorized address.
It's quite a fresh experience to see the Microsoft Entra ID authentication screen pop up for an mstsc connection.
If access is not permitted by the Enterprise application, an error appears on the Microsoft Entra ID screen, and the connection is ultimately rejected.
In other words, from an LWF perspective, it seems like it captured the traffic to that destination and tried to send it through the tunnel, but was rejected by Microsoft Entra ID; it tried authenticating once more but ultimately failed.
GSA - access error
So, while the unauthorized IP ranges are shown on the Advanced Diagnostics screen, access is actually denied at the authentication layer, which means it works as intended.
Summary
So, I tried combining MEPA with Azure's Hub-spoke architecture.
I was able to realize that network access to Spokes can be controlled using identities, which is exactly what Zero Trust Networking is.
While it is common to control access with something like a firewall, IP-address-based control makes it difficult to handle cases where a PC moves to a different network.
Ultimately, I believe the granularity of what a user can access is the best approach, so while it might be a bit complex, it could be a viable option.
References
- How Microsoft Entra Private Access bends packets (I didn't quite get it)
- The Exit of Microsoft Entra Private Access
- Hub-spoke network topology in Azure - Azure Architecture Center
- Getting started with Microsoft Entra Global Secure Access (Private Access Edition)
Update log
- Added reference links - 2024/07/14
- Fixed typos, etc. - 2024/07/14
Discussion