Azure Private Link Integration

This repository is meant as a culmination of notes and practices that I have leveraged to help support enterprise customers leverage the Azure Private Link Service. I will be adding collateral as it fits but wanted to focus more on the implementation and operationalization of the Azure service. If you are not familiar with the service and why it is critical to securing (more East-West traffic), please see the Microsoft documents here - https://aka.ms/privatelink

One of the biggest barriers to implementation is in understanding how DNS gets implemented to support Private Endpoints. My recommendation is to review Daniel Mauser's repo on PrivateLink here - Daniel Mauser's Github Repo on Privatelink. This repository is extensive and covers the different DNS patterns that are not clear from the Azure docs. I wanted to address one specific scenario by taking a deeper look at a common design pattern: **On Premise DNS forwarding traffic to Azure. See here for a better understanding of how this resolution works (and helps keep the communication secured between the requestor and the Endpoint). Specifically, my client had the following requirements:

• Enable on-premise resources to be able to leverage Azure Private Link
• Maintain Azure DNS in Azure (using MS DNS - but this could just as well be Bind or 👍 Azure Private DNS Zones
• Enable on-premise resources to be able to leverage Azure Private Link (in this case Azure Backup)
• Be able to resolve Private Endpoints without traversing the Internet
• Minimize administration for the on-premise Bind team

1. Network connectivity - DNS is by design minimal traffic, that being said there is definitely a consideration for security here. Scope and accessibility must be considered in the architecture to minimize bad actors from accessing enterprise services

2. Assuming that the Bind servers are configured (version 9+) and permitted to communicate across port 53 into the Azure DNS (more on that in a moment). This can be tested from a bind server by performing a simple: dig @{IP_ADDRESS_FOR_AZURE_DNS} known_host Watch for a connectivity error like "connection timed out; no servers could be reached"

3. Offload the management on the bind servers by creating a forward lookup zone for core.windows.net.
   🔒 This zone is important because creating a higher-level domain (i.e. windows.net) will cause issues for DNS users/services that are trying to get to common services such as https://dotnet.microsoft.com/.Using core.windows.net covers the following FQDN Endpoint for the following services:
   • blob.core.windows.net
   • dfs.core.windows.net
   • file.core.windows.net
   • queue.core.windows.net
   • table.core.windows.net
   • web.core.windows.net
   • database.windows.net

   This is not the complete list of services and may require creating individual zone forwarders for services that are NOT included in this list, such as mongo.cosmos.azure.com

   Create the entry on the Bind server - **/etc/bind/named.conf.local:**
   
   ```
   zone "core.windows.net" {
   type forward;
   forward only;
   forwarders { ***IP_ADDRESS_FOR_AZURE_DNS***; };
   };
   ```
   Substitute the IP_ADDRESS_FOR_AZURE_DNS for the IP address of your DNS in Azure (based by primary and secondary services)
   <pre>

4. DNS in Azure can be of most types. Here are some examples:
   • 👍 Azure Private DNS - this is the recommended approach for deployment and operations. With Azure Private DNS, there isn't the concern of managing the infrastructure, nor managing IP address changes (because it supports dynamic DNS)
   • DNS Forwarders - this is specifically designed to address eliminate DNS administration in Azure. The approach is to have a device in Azure that will forward specifically to the Azure Recursive Resolver. That resolver requires having the forwarder's request to originate from within Azure (i.e. we can't directly connect from our onprem Bind server). This can be a standalone (or VM Scale Set) Bind forwarder (more on that in a minute), or a container instance in docker, or could be even NGINX DNS proxy - (though I am personally reticent to use NGINX in this way). Configuring a standalone Bind forwarder is quite straight forward, it is po
   • NRPT and DNS Masq is another approach to minimally managed and deployed services.
   • MS DNS and other full DNS services in Azure - The links here should be enough to address custom and configurable options out there. Keep in mind that without leveraging Dynamic DNS - consideration should be given to static IP addresses.