The goal for every Azure admin is to use Azure PaaS services without using public IPs (Internet) — at all costs. We want to protect our traffic using the internal virtual network and Azure backbone to increase the security involved in the information being exchanged between Azure IaaS (infrastructure-as-a-service) and PaaS (platform-as-a-service). In this article, we are going to create two Storage Accounts: the first one will be protected using service endpoints and the second one using private endpoints. We will see how to configure them and the changes that happen when each solution is used.
Using service endpoints
The first method to protect your workload is using service endpoints. This feature works at the virtual network level where we allow a specific Azure service — thus the name service endpoint — by creating an extension of the current virtual network to be visible from the Azure service.
After that, the Azure service (a Storage Account in our article) will no longer be available on the Internet, and it will be reachable only from the virtual network associated with it.
There is one caveat with service endpoints when we lock down the Azure service to use a specific virtual network — we will be blocking traffic from on-premises as well. We can work on adding the public IP that the on-premises is coming from to the list of allowed IP addresses, but it has to be done manually, and we will cover how to do it in this section.
There are a couple of ways that we enable service endpoints. The more straightforward method is through the Azure service that you are trying to protect. When managing Storage Accounts, we can select Public endpoint (selected networks) in the Networking page of the Create Storage Account wizard, and select the virtual network and subnet, as depicted in the image below.
If you have the Storage Account already created, we can always click on Firewalls and virtual networks in the desired Storage Account. In that new blade, we should select Selected Networks, and then + add an existing virtual network, and select the virtual network and subnet.
In the same area, we can add public IPs from the on-premises network to allow communication from those sources to the Azure service in question. We can use this as a workaround to resolve the communication issue between on-premises and Azure services using service endpoints and firewall restrictions.
Note: When switching to service endpoints, we are telling the service to use the internal IP address, thus blocking any public access to the service. During that change, communication with the subnet may be impacted for a brief moment.
When we perform the changes either during the provision or after the fact, a new entry for the service endpoints in the virtual network will be listed.
Using private endpoints
The way that private endpoints work is different from a service endpoint. For starters, when a private endpoint is created, a network interface is also created and added to the subnet and a private DNS zone is built to support the name resolution using the internal IP address.
From that point on, all the communication using that private endpoint goes from the Azure virtual network to the Azure service securely using Azure backbone.
There are a couple of benefits of using private endpoints. First, it supports the on-premises network seamlessly because it is just another IP on the existing virtual network. Second, it maps a specific Azure service instance instead of the entire Azure service.
We can configure private endpoints during the provision or after the fact. When provisioning an Azure resource (in this case, a Storage Account), we should go to the Networking page, select Private endpoint (Item 1), and click on + Add (Item 2).
In the new blade, define a resource group, name, and select the virtual network and subnet. In the private DNS integration, the default option is Yes, which will trigger the creation of a new private DNS zone to support the integration.
Note: Network security groups and user-defined routes do not apply to network interfaces defined as private endpoints. You may want to place all private endpoints on their subnet, although, it is not a requirement.
Note 2: When provisioning using the Azure Portal, a required feature at the virtual network level is set automatically. For a virtual network to support a private endpoint, a setting called PrivateEndpointNetworkPolicies must be set to $True.
We can configure in an existing resource as well. Go to the Private endpoint connections item within the Azure Resource properties. When we click on + Private endpoint, we’ll see a wizard to help the provisioning process, and it will look like the image above.
The creation of a private endpoint creates several other resources on the backend, as depicted in the image below. It creates a private endpoint resource, a network interface, and a private DNS zone (if there is no previous zone to match that service).
The private DNS zone is going to be created for the resource type, in our case targeting specifically blob workloads in a storage account. Any new future blob private endpoints will be added to the same private DNS zone.
If we test from a client, the public name has a second alias, as we can see in the image below.
Azure PaaS services: Customize them as you like
We demonstrated how to use two methods to secure the communication to your Azure PaaS services using either private endpoint or service endpoints. There is a lot more to those services, and they can be tweaked to accommodate your business and security requirements. However, this article is an excellent start to understanding how they are implemented and what changes they bring to your infrastructure.
Featured image: Designed by Upklyak / Freepik
