Private Azure cloud hub and spoke infrastructure

28 June 2023

When you're finished setting up the first bricks of your cloud, you want to be able to create a secure infrastructure on it. This can lead to many challenges! Privatization is a common way to secure your infrastructure, no matter where it is.

What does privatization mean, and why do you need it?

The security posture of your infrastructure can greatly be improved by privatizing it. The goal is to harden the communication between your resources with a set of rules and standards. There is a couple of ways of implementing this in your infrastructure:

With only public endpoints, you can configure a zero-trust architecture, that relies heavily on authentication between parties. The counterpart is that communication goes over the public internet.
With private endpoints, you can set up a network-isolated architecture. It relies on network segmentation and flow management

We will be talking about the latter.

As a matter of fact, the latter is slightly more complicated to set up with public cloud infrastructure (Azure, AWS, or GCP) because most of the resources that are created have a public endpoint. They are offering more and more ways to configure private endpoints and ways to configure an isolated network architecture.

Let’s have a quick dive into how they manage it!

How do the 3 main cloud providers manage it?

Unfortunately, they do not manage it the same way! So let me unravel the core concept within the 3 top cloud providers.

AWS

AWS is the oldest cloud provider, and its approach is the simplest. When you create in your infrastructure, for example, an RDS (a PAAS resource), it is by default configured in a subnet. When another resource wants to connect to it, it can use its endpoint. Depending on its location, it will either:

resolve to the public IP address from outside the VPC
resolve to the private IP address from within the VPC or peered VPC with the correct configuration.

This is because AWS automatically updates public and private DNS resolvers and helps you to contact it without too much configuration overhead.

GCP

GCP is the second-oldest cloud provider in the list, and it decided to not bother managing DNS. When you want to contact a PAAS resource, you don’t use the hostname but the IP address directly.

Azure

Azure is the youngest of the 3 and decided to make things hard, but it lets you manage it as you want.

You can’t contact PAAS resources with an IP because of the HTTPS certificate. It is issued to the domain name of the type of resource. If the private IP address was put in the certificate's Alternate Name field (as we can sometimes see on other mechanisms), it could work but, this is not the method pushed by Microsoft.
Azure DNS is never updated, it always points toward the public IP address of the resource. Thus, we need to override by other means.

We will now see how Azure infrastructure choices impact the construction of a private hub and spoke infrastructure.

Privatization of a hub and spoke infrastructure

The hub and spoke networking model organizes your cloud network infrastructure into multiple connected virtual networks.

This model allows you to manage communication and/or security requirements across multiple tenants in your infrastructure.

hub_spoke_networking_model_1

We will focus on PAAS resources because IAAS are way easier to privatize but harder to maintain in the long run. We want the best of two worlds: Managed by Azure and secured.

Azure solution to privatize resources

The challenge is that most Azure PAAS resources are deployed by default with a public endpoint.

Fortunately, Azure is progressively rolling out solutions to configure a network on our PAAS resources.

VNET integration

One of the first solutions was VNET integration, they could be configured on App services to ensure that egress traffic goes through a subnet. This limitation is that it does not ensure that ingress traffic arrives from a private network, it arrives from the internet.

vnet_integration

Azure private link

Now the most common solution is a private link. It is a technology designed to connect services to a VNET. It allows you to ensure that ingress traffic to your resource is limited to only a private endpoint.

There are two main components to Azure private link

Private link service allows you to expose your own service behind an Azure load balancer. It can then be consumed by clients in their own VNET.
Private Endpoint will be the key to this article. It allows you to create an endpoint for your PAAS resource in a subnet. Deactivating the public endpoint and allowing traffic only from within a private VNET.

Unfortunately, setting up private links /endpoints requires, overriding DNS hostname to point to the private endpoint.

Private DNS

Fortunately, Azure provides a service to help configure within your infrastructure private link/endpoint, it’s called Azure private DNS.

VNET link

It allows you to configure private DNS zones that are only accessible from VNET that are connected to them via VNET links.

Consequently, only resources within the VNET can resolve entries from the private DNS zone.
vnet_links

Private DNS zone name

As seen in the above schema, the zone includes a prefix: privatelink. This is a requirement for private DNS and private endpoints to work.

Configuring this zone overrides the DNS resolution from within the VNET to allow you to connect to the private endpoint. The public domain name is not overwritten because it will impact the public DNS resolution of resources.

You can find in the official documentation the list of domains to configure in private DNS zones. You can create your own private DNS zones, but since HTTPS certificates are issued to the FQDN of the resources, you will need to configure the resources to manage custom HTTPS certificates.

Private DNS at scale within a hub and spoke

In a hub and spoke infrastructure it is not recommended to create a private DNS zone per VNET but to create only one and connect it to the HUB VNET.

For security reasons, you should not allow spokes to create their own private DNS zone, because it will create 2 DNS sources of truth, which is not a good idea.

Furthermore, spokes should be able to consume private resources easily.

To solve this problem, everyone should contribute to the private DNS zone in the HUB, but it’s a sensitive resource because it contains DNS resolution for every spoke.

Azure solved this issue with Azure policies, in summary, you need to

Create in advance every private DNS zones for the resources you are using
Enforce the use of private endpoints with an Azure policy

Automate the DNS record creation in the DNS zone created with a DeployIfNotExists Azure policy

Security

You can see in the above article that you can enforce security principles with Azure policy, for example denying the creation of resources with a public endpoint.

In fact, private endpoints allow for enforcing a lot of security principles within your infrastructure.

First of all network isolation with NSG (Network security group) and PrivateEndpointNetworkPolicies configuration which is a preview feature as of 15/09/2022. You will thus be able to create only resources with private endpoints and segregate communication between them with NSG.

On-premise integration and Azure magic IP

Finally, let’s get into the hybrid part of a hub and spoke. Hybrid infrastructure is composed of an on-premise and cloud infrastructure.

The DNS conundrum

The challenge here resides in the DNS protocol. On-premise workloads need to be able to resolve Azure workload FQDN with its own DNS server. Thus, the on-premise DNS server needs to be able to contact Azure private DNS.

Unfortunately, you can’t link private DNS zones with on-premise networks. You need to rely on conditional forwarders. It allows you to forward DNS requests to another DNS server. For this to work, you need to point to the IP of this other DNS server.

Azure private DNS zones do not expose IP, so you cannot configure conditional forwarders directly to it.

The solution to this is to configure a resource within the HUB VNET that can manage DNS and has IPs.

For this, there are 3 solutions :

2 Virtual machines installed with DNS software like bind9

Pro: It works
Cons: You need to manage virtual machines …

AADDS (Azure active directory domain services)

Pro: It’s a manage services
Cons: If you only use it for the DNS you are using 5% of its capacities, and you need a virtual machine to configure it.

Azure DNS Private Resolver

Pro: It’s a manage services built specifically for this use case
Cons: it’s still in preview as of 15/09/2022

Azure magic IP

Regardless of the resource you chose, you will not be able to request the Azure private DNS zones, even with the VNET link.

You will need to configure a forwarder in the resource you choose, to forward requests towards Azure magic IP 168.63.129.16. Which is in charge of doing DNS resolution according to the private DNS Zone linked to the VNET the request was submitted. In our case, the HUB VNET.

To make sure you only have 1 source of truth I recommend configuring custom DNS on every VNET to point towards the IP of the resource you chose. It will also allow your Azure resource to resolve on-premise workload if you add forwards to the on-premise DNS server.

Consequently, resources on-premise and Azure resources in a spoke VNET can resolve private endpoints on Azure.

A schema to resume how it works:

azure_magic_ip-1

Conclusion

Creating a secure infrastructure on Azure with a hub and spoke architecture can be a challenge, and I hope that this article will help identify all the work needed to set it up.

If you want help setting this up on Azure or any other cloud provider with IAC tools, you can ping us.