Private in the Azure public Cloud

Once we deploy a solution into the public cloud without thinking too much about it, we usually only have 1 layer-of-defence, which is authentication/authorization. This will mostly be through username/password, single sign-on, access-keys or other secrets.

Take a look at the diagram below. We take 3 compute services (Kubernetes, Virtual Machine and App Service), and 3 storage services (Container Registry, Storage Account and SQL Database). Other variations are also possible, but in this case, only Kubernetes and the Virtual Machine are in a VNet (Virtual Network). All other services have a public IP address and no integration with the VNet.

This is a party for that hacker from Russia, who has every chance to penetrate services with a public IP address.

CHARACTERISTICS:

• Infrastructure as a Service (IaaS) services (such as Kubernetes and Virtual Machine) already have VNet integration by default.
• Platform as a Service (PaaS) services (such as Container Registry, Storage Account, SQL Database and App Service) do not have VNet integration out-of-the-box.
• Azure services do not access on-premises data resources.

You can run the new Docker app locally with ‘docker run –rm <imageid>’, getting the imageid from the Docker build output. This causes the Docker container to load locally and start the default app in that container. In the Dockerfile, you will see at ‘entrypoint’ that the new app is automatically started.

An easy way to add a second layer-of-defence is to apply IP white-listing. All PaaS (and SaaS) services have this capability. With IP white-listing, you specify which IP addresses are allowed (think office, home-workers and Azure services).

This method is a common one. It’s easy to get started, and you can accomplish a lot in a short time.

This already makes that hacker from Russia a lot harder, but not impossible.

However, this solution has a few drawbacks:

• IP addresses do tend to change, especially for home workers.
• Several PaaS services have only the IP addresses (with no name) in the firewall. Without records, there is no way to tell which IP address was intended for whom. So they probably stay in there unnecessarily long.
• Sometimes you need to add IP addresses of Azure services (see Download Azure IP Ranges and Service Tags), which are very broad. Also, hackers can also take Azure services that come in the same IP range, and thus can penetrate through your second layer-of-defence.

I won’t go too deep into it either since there is plenty to be found about it. Let’s go ahead and see if there’s a Rich man’s solution….

For a solid second layer-of-defence, we are going to make full use of network isolation in a VNet. This ensures that we set up a similar network as companies have on-premises.

In Azure, it might look like this:

CHARACTERISTICS:

• For IaaS services (such as Kubernetes and Virtual Machine), nothing will change. These, as we have already seen, are always deployed in a VNet.
• For many PaaS services, the firewall is closed, and we create a Private Endpoint in the VNet. More details follow below.
• For App Service (PaaS), an App Service Environment is created in the VNet, making the App Service entirely deployed in the VNet, and not accessible from the public Internet. More details for these also follow below.
• Using an Express Route, we create a permanent network connection between the office (on-premises) and the VNet in Azure. This is a two-way connection. Perhaps an Express Route is on the pricey side, in which case it can be done with a site-to-site VPN.

Through these modifications, an additional layer-of-defence has been added.

That hacker from Russia doesn’t stand a chance. The fort is locked! He will probably set his sights on someone else.

I have already briefly shown the use of Private Endpoints and App Service Environment. This is where it gets complex, however: virtually every PaaS (and SaaS) service has its own way for network isolation. These bring additional costs for Azure resources, as well as additional complexity that will translate to higher development costs. Hence, this is the Rich man’s solution.

Following are the most common PaaS services, with their corresponding solution for network isolation…

PRIVATE ENDPOINTS, FOR STORAGE SERVICES

Applies to:

• Storage Account
• SQL Database (Server)
• Cosmos DB
• MySQL
• PostgreSQL
• Container Registry
• Key Vault
• And many others, see the documentation

With a Private Endpoint, you create a network interface with a private IP address in the VNet. This network interface is connected to the storage service. Also, a DNS record is created with the exact same name/URL as your storage connection string, but it refers to the private IP address instead of the public IP address. On the storage service, the firewall (of the public IP) is closed.

 

This whole thing ensures that without modifying the application, with the exact same connection string, you still connect to the storage service.

Cost: €9 /month, in addition to the storage service

Private Endpoints are the successor to Service Endpoints. Service Endpoints are still available and even easier to use, but also more limited in capabilities.

Documentation:

• Azure Private Endpoint | Microsoft Docs
• Use private endpoints – Azure Storage | Microsoft Docs

APP SERVICE ENVIRONMENT (ASE), FOR APP SERVICES AND FUNCTIONS

The App Service Environment is an environment within which multiple App Service Plans (Web servers) can be deployed, with the App Services (Web sites) on top of them. The big difference is that now App Services can only be accessed from the VNet, and access on-premises data resources.

 

If you are normally used to an App Service Plan having a SKU of Free, Basic or Standard, then on the App Service Environment it has a SKU of Isolated (I1, I2, I3).Cost: € +/- 950 /month per App Service Environment v2, on top of the I1, I2, I3 App Service Plan cost.

A major disadvantage of the current ASE (v2) is that it has a fixed (stamp) cost of about €950 /month, and on top of that the cost for the App Service Plans (e.g. for I1 it is €184 /month). But there is hope, as there is a new preview version of the ASE that is free of charge. See App Service Environment v3 (and Isolated v2 Plan). You then do not pay the fixed stamp cost of € 950 /month, but only the App Service Plans (I1v2, I2v2, I3v2), although the cheapest variant I1v2 is already € 350 /month.

Documentation:

• Azure App Service Environment | Microsoft Docs
• Azure App Service Environment v3 (preview) | Microsoft Docs

It can also be done differently.

In case you’re thinking that App Services can be linked to a VNet even without an App Service Environment, that’s right. However, you then need to use 2 concepts:

• Access from VNet to app service: Private Endpoint (requires Premium App Service Plan)
• Access from app service to VNet: VNet integration

Documentation:

• Integrate app with Azure Virtual Network – Azure App Service | Microsoft Docs

ON-PREMISE DATA GATEWAY, FOR POWER BI, POWER APPS AND LOGIC APPS

When using Power BI (reporting tooling), Power Apps (no-code/low-code application platform) and Logic Apps (no-code/low-code workflows), it is fairly obvious that they must also be able to access on-premises data resources, or securely access Azure data resources.

To achieve network isolation with Power BI, Power Apps and Logic Apps, you need to install the Data Gateway software on a Virtual Machine (Windows). This could be in Azure, but also on-premises.

 

Cost: Only the cost of the VM

Documentation:

• On-premises data gateways documentation | Microsoft Docs

INTEGRATED SERVICE ENVIRONMENT (ISE), FOR LOGIC APPS

With the previous solution “Data Gateway” for a Logic App, the compute is still running on a public-internet node. To ensure that not only data access but also compute is shielded, you can use an Integrated Service Environment (ISE).

 

The ISE is similar to the ASE, but specifically for Logic Apps. Various compute and storage resources are deployed that are managed by Microsoft.

Costs:

• Developer: € +/- 750 /month
• Premium: € +/- 6,600/month

Documentation:

• Connect to Azure virtual networks with an ISE – Azure Logic Apps | Microsoft Docs

HYBRID RUNBOOK WORKER, FOR AUTOMATION ACCOUNTS (RUNBOOKS)

Automation Accounts are used for process automation, configuration management, update management and PowerShell desired state configuration (DSC).

To achieve network isolation with an Automation Account, you need to install the Hybrid Runbook Worker software on a Virtual Machine (Windows or Linux). This could be on Azure, but also on-premises.

Cost: Only the cost of the VM

Documentation:

• Azure Automation Hybrid Runbook Worker overview | Microsoft Docs

INTEGRATION RUNTIME (IR), FOR AZURE DATA FACTORY (ADF)

Azure Data Factory is an ETL (Extract, Transform, Load) tool for copying and transforming data. For the old timers among us, this is the successor to SSIS (SQL Server Integration Services). Even with this service, it is very obvious that it must have access to on-premises data resources and/or network isolation.

To achieve network isolation with Azure Data Factory, you can choose from 2 options: A and B

A. SELF-HOSTED INTEGRATION RUNTIME

The Self-hosted integration runtime is again a software package that needs to be installed on a Virtual Machine (Windows). This could be in Azure, but also on-premises.

Cost: The cost of the VM + use of ADF.

Limitation:

• Can only copy data (data-copy), not transform (data-flow)!

Documentation:

• Self-hosted Integration runtime – Azure Data Factory | Microsoft Docs

B. MANAGED VIRTUAL NETWORK

It is also possible to use the (standard) Azure hosted Integration Runtime, but with a Managed Virtual Network. In this case, a VNet is created especially for the IR created by you, however, you yourself do not have access to this network. You can then create Private Endpoints towards Azure storage services, though, creating network isolation that way.

Cost: +/- 2x as much as the regular Azure Integration Runtime.

Limitation:

• Can access Azure storage services, but not on-premises data resources.

Documentation:

• Managed virtual network & managed private endpoints – Azure Data Factory | Microsoft Docs

SAFEGUARD

Using network isolation, it is possible to completely isolate a solution from public Internet. However, if less meticulous care is taken, a firewall may just be opened or a VM provided with a public IP address.

If you go to the trouble of making a solution secure, also look at safegaurds to keep the solution secure. This could be done with Azure policy, which ensures that, for example, it is not possible to deploy a VM with a public IP, and that a storage account always has the firewall on.

You need to provide multiple layers-of-defence in the public cloud yourself. The first will be authentication and authorization. The second will be at the network level. This can be done (as Poor man’s solution) with IP white-listing, or (as Rich man’s solution) with network isolation a.k.a. Private in the public cloud.

Depending on the Azure service, the solution for network isolation is very different. Below is a brief summary

 

With an advanced network isolation solution, you should have safeguards against misconfiguration. You can do that with Azure Policies.

The Russian hacker used is a metaphor for a malicious earthling, and could be of any other nationality.