What is Azure Private Endpoint?
Cloud Security Architects often make use of “Azure Private Endpoints” to enable access to Azure PaaS services. There are many Azure PaaS Services that supports Private Endpoints e.g., Azure Storage, Azure App Services, Azure CosmoDB, Azure SQL Database, etc. This eliminates the need for the service to be publicly accessible. Access to these private endpoints use Microsoft backbone network without ever going over the public Internet. Private endpoint is a network interface that uses a private IP address from your virtual network. This network interface connects you privately and securely to a service that's powered by Azure Private Link. By enabling a private endpoint, you're bringing the service into your virtual network.
When you bring your Azure PaaS services into your private virtual network all traffic to the service is now routed through the private endpoint and traffic remains on the Microsoft global network. In this architecture and design, DNS is a critical component to make the application work correctly by successfully resolving the private endpoint IP address. To connect to the Azure PaaS service over private endpoint, separate DNS settings, often configured via private DNS zones, are required. The settings must resolve to the private IP address of the private endpoint. The network interface associated with the private endpoint contains the information that's required to configure your DNS. The information includes the FQDN and private IP address for a PaaS Service resource enabled with private endpoint.
Avoid backhaul of traffic to on-premises network using Netskope Private Access
To make your PaaS service available to your users and enable secure access from on-premises networks you would then have to connect to the VNet using either a VPN (site to site) or ExpressRoutes with private-peering. When your user is not connected to on-premises network then they will have to use VPN to connect to on-premises network before they can gain access to the PaaS services by going over either site to site VPN or ExpressRoute with Private Peering. With Netskope we can avoid such backhaul of traffic to on-premises network and help improve your user experience to access PaaS services in cloud.
Alright! with some primer on Private Endpoint out of our way....
Now, let’s look at how we can provide access to your Azure PaaS Services configured with Private Endpoints inside Netskope? Well, the answer is to use Netskope Private Access (NPA), it is part of the Netskope security cloud and enables zero-trust secure access to private enterprise applications in Hybrid IT. You may be thinking, is it that simple? I guess “it depends” what do you see from your end “6” or “9”?
Like everything else in life things can be simple or complicated, the intent of this post is to share some thoughts on how to architect and design and provide technical guidance so that you can make an informed decision or at least things are simple for you while you are trying to figure out your overall architecture and design for this use case.
The first thing we want to decide is to where should we deploy Network Private Access Publisher? The Netskope Private Access Publisher can be deployed on AWS, Azure, GCP, HyperV, VMWare ESXi, and any Ubuntu 20.04 based virtual machine (VM). Since this post is about Microsoft Azure, the two logical deployment choices you can go with.
- Deploy Network Private Access Publisher on-premises.
- Deploy Network Private Access Publisher in Azure.
There is no right and wrong choice here, it’s really boils down to your overall architecture and requirements – Yes, that’s another way of me saying “it depends”. I know, I suppose to provide you an answer and make things simple. Have some faith, I’m getting there … for me to make things simple for you, I’ve to do an “opinionated” architecture and design guidance and if you are okay with my approach, let’s pick the deployment option #2 i.e., deploy your Network Private Access Publisher in Azure.
I would assume you are familiar with Microsoft Cloud Adoption Framework, as part of this framework, we were introduced with the concept of “Landing Zones”. The concept of “Landing Zone” is to ensure that when an application or workload lands on Azure the required “pluming” is already in place. If you like an analogy then this concept is similar to how city utilities such as water, gas and electricity are accessible before new houses are constructed. I would like you to consider Network Private Access Publisher as part of such essential services.
From the lens of Microsoft Cloud Adoption Framework and Azure Landing Zones – Network Private Access Publisher belongs to “Connectivity” Subscription and inside your Hub virtual network. In order to help you with this deployment, we have created an Infrastructure as Code (IaC) using Terraform that is available on our public GitHub repo at; https://github.com/netskopeoss/tf-e-publisher-azure
Here is a video walkthrough of this deployment.
Not a fan of Terraform? No problem, the Network Private Access Publisher VM is available in Azure Marketplace so you can use the UI based deployment!
With the deployment aspect of Network Private Access Publisher taken care of, the next architecture and design you would have to handle is making sure Network Private Access Publisher can resolve Azure PaaS Services endpoints to your service Private Endpoint. There are few ways we can do our DNS architecture and design i.e.,
- Use a private DNS zone to override the DNS resolution for a private endpoint. A private DNS zone can be linked to your virtual network to resolve specific domains.
- Use your DNS forwarder to override the DNS resolution for a private link resource. Create a DNS forwarding rule to use a private DNS zone on your DNS server hosted in a virtual network.
Since we have already established to keep things simple for us, we will use option # 1.
In the below architecture configuration diagram, we use Azure provided DNS without a custom DNS server required. In this design, the client (including Network Private Access) queries for the private endpoint IP address to the Azure-provided DNS service 168.63.129.16. Azure DNS will be responsible for DNS resolution of the private DNS zones. The network architecture is using “Hub and Spoke” topology as per Microsoft Cloud Adoption Framework. Both, the Hub virtual network and the spoke virtual networks are linked to the same private DNS zone.
With the above design in place, the rest of configurations are like what is required to publish any other private application using Netskope Private Access. The product documentation at https://docs.netskope.com/en/netskope-private-access.html can provide more detailed steps.
Let’s say you want to access Azure Storage account (e.g., a Blob container) using the Private endpoint with Netskope Private Access then the following configuration needs to be done;
- Azure Private DNS with name “privatelink.blob.core.windows.net” must be created.
- A DNS record “A” record for the Azure Storage Account sub resource i.e. blob i.e., <name_of_your_storage_account>.privatelink.blob.core.windows.net. For example; bdsbxcsacf82.privatelink.blob.core.windows.net
- The Virtual Network where Network Private Access Publisher VM is deployed should be Linked to this Private DNS Zone.
- Private app definition in Netskope must be created for your blob container using its FQDN i.e., <name_of_your_storage_account>.blob.core.windows.net. For example; bdsbxcsacf82.blob.core.windows.net
It is important to understand that the FQDN used in our Private App Definition since Azure creates a canonical name DNS record (CNAME) on the public DNS for the PaaS services. The CNAME record redirects the resolution to the private domain name, and it will resolve to private endpoint IP since our Netskope Private Access Publisher is linked with Azure Private DNS zone as well, we will be able to resolve the endpoint to a private IP.
- Policy definition is created for the Private App so users can access a private app through the Netskope Private Access Publisher.
If you are visual person like me then the design and DNS query flow from Network Private Access Publisher VM perspective will be like this for our example use case;
In the above diagram, a storage account is created in a Subscription and Private Endpoint is created inside Spoke-1 virtual network. The Private DNS with the associated A-record for the sub resource type blob is also created and the hub virtual network, where Network Publisher Access VM is deployed, is linked with this private DNS zone. The spoke virtual network doesn’t need to be linked to this private DNS zone and it is shown as optional, if you have a requirement to resolve this storage account from with-in the Spoke-1 vnet then create the virtual network link to the private DNS zone from the spoke vnet.
To test our DNS configuration, we can do the following quick test;
- A nslookup to our example storage account name “bdsbxcsacf82.blob.core.windows.net” from a user system that is not allowed to use this private application or any test system that is not connected to Netskope for traffic steering for private access will resolve to a Public IP Address for our storage account.
- A nslookup to our example storage account name “bdsbxcsacf82.blob.core.windows.net” from a user system that is allowed to use this private application through the Network Access Publisher will resolve to a Private IP Address for our storage account.
In this case, you see an IP address of 191.1.1.3 and that doesn’t really match what the A-Record we have defined for the private endpoint in Azure, does it?
It’s important to understand another concept when it comes to Network Private Access, when you define a host on the private application definition and assign that private application to a user via policy, NPA client on the endpoint will listen for any DNS name queries and, if any of them match the private application hostname, it will resolve them to 191.x.x.x IP address. Then, when a process is making a request to that IP address, NPA intercepts it (by implicitly tunneling all traffic to 191.x.x.x IP addresses), tunnels it to a publisher, and the publisher performs name resolution based on the DNS settings it has configured.
If there are issues in connecting to your Azure PaaS service, then we can also do a quick nslookup check from the Network Private Access Publisher VM itself to ensure our DNS configurations are working properly.
In case it’s not clear, the above design will work for all Azure PaaS Services as long as the PaaS service you are using support Private Endpoint, and you have the DNS architecture done accordingly.
For any alternate design options e.g, where you have a desired to use custom DNS & forwarders or if you will be deploying Network Private Access Publisher VM on-premises, we can do another post to go over those details given the interest from the community.
That’s it for this post!