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:
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!
Unfortunately, they do not manage it the same way! So let me unravel the core concept within the 3 top cloud providers.
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:
This is because AWS automatically updates public and private DNS resolvers and helps you to contact it without too much configuration overhead.
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 is the youngest of the 3 and decided to make things hard, but it lets you manage it as you want.
We will now see how Azure infrastructure choices impact the construction of a private 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.
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.
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.
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.
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
Unfortunately, setting up private links /endpoints requires, overriding DNS hostname to point to the private endpoint.
Fortunately, Azure provides a service to help configure within your infrastructure private link/endpoint, it’s called Azure private DNS.
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.
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.
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
DeployIfNotExists Azure policy
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.
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 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 :
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:
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.