I've the following scenario:
There's a VNET which has a few services (Azure Container Apps + Azure Functions) which are internal services (do not acccept any external traffic). This VNET is connected to On-Prem using ExpressRoute. There's a service (API) hosted On-Prem, which we want to call from ContainerApps/Functions that is only accessible internally. This service is behind firewall. The administrators of this On-Prem service wants us to provide the private IP(s) of the services which will call the On-Prem service - the important part is that we want this IP(s) to be static, so we do not need to change any firewall settings frequently. As far as I know, there's no way to control the private IP of neither ContainerApp nor Azure Function. I've considered Azure NAT Gateway, but it seems to be only working with public IP(s).
Are there any other alternatives ?
Looking at the latest specification (api-version=2022-06-01-preview), it supposed to be possible.
In the vnetConfiguration block, you can specify the outbound type and the virtual applicance IP:
vnetConfiguration: {
...
outboundSettings: {
outBoundType: 'UserDefinedRouting'
virtualNetworkApplianceIp: 'X.X.X.X'
}
}
This required a Premium sku:
sku: {
name: 'Premium'
}
Found also this interesting article about locking down the VNET:
Lock down VNET with Network Security Groups and Firewall
Related
I'm trying to have good understanding of Azure vnet integration.
I want to deploy an API management service in Azure and I have to choose a SKU. I'm wondering if vnet integration is require for private outbount trafic ?
For instance, I have a backend vm in a vnet. Does the traffic have to go through internet if I do not use vnet integration ?
I deployed basic api management service, I can create private endpoint but this is only for inbound trafic right ?
Thanks,
I can create private endpoint but this is only for inbound traffic right?
Yes, a private endpoint will give a private IP address for inbound traffic only. Use private endpoints and regional VNet integrations in two separate subnets if you need both inbound and outbound traffic.
Currently, Private Endpoints are not supported for the Outbound traffic as the Networking model "Private endpoint" is in preview stage.
You can see the below table for the supported networking models for the types of networking traffic based on usage scenarios given by Microsoft in this Doc:
Refer to this MS Doc regarding the VNet Integration & Private Endpoint for different types of Networking Traffic types.
If I am setting up an Azure SQL Database in a vnet which Azure App Service and Azure Function will access. Is using both Subnet Delegation and Service Endpoints the right way to go? I didn't fully understand the documentation.
Regarding subnet delegation, I read this Microsoft article and this stackoverflow post, which stated:
When you delegate a subnet to an Azure service, you allow that service to establish some basic network configuration rules for that subnet, which help the Azure service operate their instances in a stable manner.
That sounds like a good thing but makes me wonder how it worked efficiently w/o subnet delegation.
As for Service Endpoints, I read this Microsoft article, which states:
Virtual Network (VNet) service endpoint provides secure and direct connectivity to Azure services over an optimized route over the Azure backbone network. Endpoints allow you to secure your critical Azure service resources to only your virtual networks. Service Endpoints enables private IP addresses in the VNet to reach the endpoint of an Azure service without needing a public IP address on the VNet.
Does that mean I cannot reach the Azure SQL Database from my home machine w/a firewall rule?
They both sound like they have the same benefits and I'm struggling to understand the difference. I suppose the larger question is should I enable both for the simple architecture outlined above.
In the Microsoft service endpoints documentation they also mention:
Microsoft recommends use of Azure Private Link for secure and private access to services hosted on Azure platform. For more information, see Azure Private Link.
For some reason that seems like an Azure to on-premise thing.
• You cannot use a ‘Subnet Delegation’ along with a ‘Private endpoint’ since that subnet is delegated for the said service, in your case, the Azure SQL Database. Through a subnet delegation, you can define the NSG association for it, as well as associate multiple delegated subnets to a common NSG. You can also define the IP Address space for the delegated subnet, the route table association with it, the custom DNS entry configuration in Azure DNS as well as define the minimum number of IP Addresses available for that delegated subnet. Similarly, with regards to service endpoint, these stated functions are not available.
• In service endpoint, you do not have control over the routing mechanism as well as the IP address related allotment, reservation, or configuration. Also, managing DNS entries for the resources managed through them and controlling them through a firewall or NAT gateway isn’t required unlike a subnet delegation because all these things are managed by Microsoft Azure’s backbone network on your behalf.
Thus, both have their own features and specifications for enabling you to configure according to your own requirements.
Does that mean I cannot reach the Azure SQL Database from my home machine w/a firewall rule?
Yes, you will have to create a firewall rule to allow the access from on-premises system to Azure SQL Server/Database and configure the service endpoint accordingly to allow the VPN client IP Addresses for accessing the same over public internet.
Also, through Azure private link, you won’t be able to connect from on-premises to Azure as it uses a private IP address and a private DNS zone entry related to it to connect to Azure resources in the same virtual network.
To know more regarding the configuration of Azure service access from on-premises network, kindly refer to the below given link: -
https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-service-endpoints-overview#secure-azure-service-access-from-on-premises
Also, refer to the below snapshots regarding the configuration and selection of service endpoint for a particular subnet: -
I have two NodeJS App Services.
They can connect to each other with no problem using the URL which is created for App Services by default. (That is through the public internet.)
Then I successfully enabled VNet Integration for both App Services, and assigned the same VNet and also subnet two both of them.
How should I modify the connection URL now to connect to appservice2 from appservice1 (without using the URLs which are publicly available on the internet)?
I could not find any host name or IP address information in Azure Portal using which I could have successfully established the connection.
Thanks for any suggestions!
When you want two app services to connect to each other over a private network, there are generally two steps you have to take to set this up correctly. Note that the app service URL will always stay the same, it is only the networking part that changes.
Both app services should have vnet integration enabled, which allows the app service to route its traffic through the vnet.
If you want others (e.g. another app service) to connect to an app service via a vnet you can choose between:
a) Service endpoints
b) Private endpoints
Reading your question, I assume you completed the first step correctly. But you have to complete either step 2a or 2b to get this to work properly. I would recommend you choose service endpoints because they are more straightforward than working with private endpoints. Below you'll find a detailed description and considerations for every step.
1. Vnet Integration
The subnet you use as an integration subnet has to be a dedicated subnet. This means it is only used for vnet integration.
Only one app service plan can be used with this dedicated subnet, this one app service plan may include multiple app services.
If there is a network security group attached to that subnet, it needs to allow outbound traffic.
If there is an azure firewall attached to your vnet and you want to make a call to a public endpoint, it should allow outbound traffic.
Vnet route all should be enabled if you want all the outbound traffic to travel over the vnet.
If you want to read more, I would recommend reading this documentation.
Here is a simple example of how you would create vnet integration by selecting the dedicated subnet:
Service Endpoints
Service endpoints allow you to lock down inbound access to your app so that the source address must come from a set of subnets that you select.
Service endpoints are automatically provisioned by azure when you enable access restrictions to the app service.
This is a much simpler alternative to private endpoints.
Does not work in large-scale networks where you want to connect from an on-prem network to an azure vnet.
You may turn to this documentation to read about all the features and limitations of service endpoints.
Here is an example of how you would enable services endpoints for your app service by creating an access restriction:
Private Endpoints
Private endpoints also need a subnet, but you can connect as many private endpoints to the subnet as there are IP addresses available.
When you use private endpoints, you also need to have a private DNS zone. Otherwise, the app service URL does not resolve correctly to an IP address.
Private endpoints are more complex than service endpoints because of the extra subnet and DNS requirements.
Here is a nice tutorial that let's you set up an app service with private endpoint.
The following example shows you how to create a private endpoint for your app service. You have the option to let azure create a private DNS zone automatically, or you can do this manually:
If you want to access app services without public internet, then enabling VNET integration in those services alone won't be enough. You need to create a private endpoint that provides the IP from the virtual network to access the app service internally within the VNET and it also disables public access to the app service over the internet. Also please be aware that the private endpoint implementation will have some cost implications as well.
If your requirement is just to establish a secure connection between your virtual network & app service and to avoid access over the public internet, a service endpoint is the simplest solution. If you also need to access the app service from on-premises through an express route or Azure Gateway, a regionally peered virtual network, or a globally peered virtual network, Private Endpoint is the solution.
Steps to set up a service endpoint are detailed in the provisioning service endpoint link
Steps to set up a private endpoint are detailed in the connect to the web app using private endpoint link
Also if you want to deep dive into private endpoint configuration for app service, I would recommend you to read through the following tutorial
I build an architecture, where you can trigger an Azure Function to push data into a Cosmos DB, which lies behind my DMZ. Some implementation guidelines state, that a service endpoint should be always enabled if possible. However, if I do so, the Cosmos DB is potentially exposed to the Internet (although I would not allow any IPs in the Cosmos DB firewall). With exposure I mean the order of handling services in Azure (https://msdnshared.blob.core.windows.net/media/2016/05/1.bmp). Thus, the Cosmos DB would have by default a public endpoint.
Can I restrict any public access from the internet, except blocking all IP addresses?
Can I restrict any public access from the internet, except blocking
all IP addresses?
Actually, By enabling service endpoint, you have limited that only requests originating from that subnet could access the Azure Cosmos DB. Traffic from your VNet to the Azure service always remains on the Microsoft Azure backbone network. So, it's a secure way to access resources in Azure.
After enabling a service endpoint, the source IP addresses of virtual machines in the subnet switch from using public IPv4 addresses to using their private IPv4 address, when communicating with the service from that subnet. Also, the default NSG associated with that subnet continues to work with service endpoints, read here. If you want to deny all outbound internet traffic and only allow access to cosmos DB from that subnet, you could add service tag as the destination in the outbound rules in NSG.
edit
You could have a look at this Azure private link(preview), but it seems it's not available for Azure Cosmos DB Account yet.
Azure Private Link enables you to access Azure PaaS Services (for
example, Azure Storage and SQL Database) and Azure hosted
customer/partner services over a Private Endpoint in your virtual
network. Traffic between your virtual network and the service
traverses over the Microsoft backbone network, eliminating exposure
from the public Internet.
With the new VNet integration mode (currently in Preview), what are now the pros (and/or cons) of chosing external ASE instead ?
Thank you
VNet Integration is often used to enable access from apps to a databases and web services running in your VNet. With VNet Integration, you don't need to expose a public endpoint for applications on your VM but can use the private non-internet routable addresses instead.
There are some things that VNet Integration doesn't support including:
mounting a drive
AD integration
NetBios
private site access
accessing resources across ExpressRoute
accessing resources across Service Endpoints
If you have an External ASE, the publish VIP is also the endpoint that your ASE resolve to.
With VNet Integration, you don't need to expose a public endpoint for applications on your VM but can use the private non-internet routable addresses instead.
App-assigned IP-based SSL addresses: Only possible with an External ASE and when IP-based SSL is configured. With an External ASE, you can assign IP addresses to individual apps.
Public inbound IP address: Used for app traffic in an External ASE, and management traffic in both an External ASE and an ILB ASE.
For more details, you could refer to this article.