Securing you Azure Environment Part II / Hub n Spoke

So in my previous post I covered the basic concepts of Securing your cloud environment. In this post I want to dive a bit deeper into how we start implementing this process. First I would like to point out that this is kind of a default starter template. Every environment is different and requires specific tailoring to fit the needs of the client.

So to begin with I would like to introduce you to a concept called Hub n Spoke. This concept is nearly always used in enterprise cloud environments. The basics being that the network is segmented into multiple VNets, A single Hub Vnet and multiple Spoke VNets. So what’s a hub VNet you ask? Well a Hub Vnet is a central VNet that holds all shared resources mainly, but not only, from a networking perspective. In most cases the Hub will contain corporate Firewalls, WAF (Web Application Firewall), DDoS protection, Proxies and so on. In many cases the Hub will also contain Domain Controllers, Anti-Virus Servers, SIEM collectors and so on. The spokes will hold the actual workloads, these could range from a standard VM setup to AKS (Kubernetes) and even a mix of PaaS bases services such as webapps, Azure SQL and so on. The reasoning behind this is fairly simple.

1. On the one hand we want to allow different departments access to the cloud. We also would like to offer them a high degree of independence when using the cloud. However we still need to govern and secure these environments. Hence centralizing and isolating all security and shared resources to the hub allows us to have in-place controls while still delegating the spoke environments to the required departments.
2. Many companies are approaching the cloud from a hybrid perspective. They already have in-place on-prem solutions such as firewalls, Anti-Virus solutions etc. These companies have personnel with a high level of expertise on these solutions. It also wouldn’t necessarily make sense for them to use native cloud solutions as this would require them to manage multiple technologies (both on-prem and cloud) therefore the use of Marketplace solutions to deploy existing 3rd party solutions in to the cloud makes more sense to these companies.

So, how does it work. Lets take a look at the following diagram

On the left we have the Hub-VNet. The hub here contains both Firewalls, WAFs & some Virtual Machines. Each deployed to it’s own subnet, so we also have segmentation within the VNet itself. All of this is managed by IT staff. On the right we have the Spoke-VNet or in other words the actual workload which in this scenario is an AKS cluster. Now you can see between the two VNets that we have peering and a UDR. The peering effectively connects the Vnets together to allow for network data flow. The UDR (user defined route) will route all outbound traffic from the VNet to the firewalls in the Hub. So now we have full control of all traffic leaving the Vnet, similar to what we would expect in an on-prem environment. Finally we would implement an Azure policy to force the use of both peering and UDR. Finally we also make use of Private Endpoints. Private Endpoints allow us to use PaaS based services as if they were part of are VNet. While these services usually have only public endpoints, the used of a private link will assign them a private IP from are VNet range hence allowing us to restrict and control access to internal resources only. Once all of this is in place we can delegate control of the spoke VNet to the required department. Knowing that all traffic is flowing through are hub and that we have control and governance of the environment.

This is what I like to call a well architected approach

Stay tuned for the next post where we will discuss the use of Microsoft Defender for cloud