I'm struggling with how to use Azure API management together with App Service Environment v1 (aka ASEv1), i.e. how to set the things via Azure portal.
I have ASE with one app service (target is several of them) and I have APIM gateway pointing to the public host name of the service.
What I have to do to make the app services in ASE VNet to be accessible only through the APIM gateway, to keep the back-end services hidden?
I need to be able to manage APIM from Azure portal and to be able to access the services directly via FTPS for deployment, collecting logs, etc.
--
I've created a new subnet for the APIM and put it in the ASE VNet , where already ASE subnet was. Now I probably have to set some NSG rules but I'm not sure how and if it is all I'm supposed to do.
The second thing I'm not sure is how to change the APIM API settings. It now points to a public URL of the service - I do not know if it will be available after NSG changes.
There are a couple of options, depending on what you really want. If you're fine having your backend services visible by outside but not callable, you can employ any means of authentication between APIM and backend services:
Shared secret - header/query param
Client certificate authentication
IP filtering on the side of backend services
If you want to really hide backend services from outside, you'll have to put APIM and ASE into same VNET.
Following seems to work, although it may need some fine tuning.
In short, each layer put into separate external VNet with own Network Security Group (NSG), using caller's public IP address to manage access to VNet:
back-end service web app in ASEv1 VNet "vnet-ase", with associated NSG "nsg-ase"
APIM gateway put to a separate VNET "vnet-apim", with associated NSG "nsg-apim"
in nsg-ase allow access from public IP of APIM GW, to vnet-ase
nsg-apim will be used to manage connections to the APIM gateway
Related
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'm trying to secure my containerized web app with a Premium V2 App Service Plan. I've enabled Service Endpoints for an integration subnet for the different App Services to restrict incoming traffic from each other except for the frontend (so all of them are integrated with the VNet and all have incoming traffic restricted to that VNet except for the frontend).
I have also other Azure services like Azure Functions or a Storage Account that can have inbound traffic restricted by using those Service Endpoints. However, One of the App Services calls an external 3rd party API that lies on Azure too. That API may or not be behind a static IP. However, it has a Custom Domain associated.
The problem arises when I try to connect to that API from one of the VNet integrated App Services. As the destination IP is inside one of the IP ranges that are added to the routing with the use of a Service Endpoint, traffic is sent via that Service Endpoint instead of simple Azure routing. I've tried overriding the route with a Route Table associated to that subnet but that seems not to be possible, with or without a NAT Gateway attached to the subnet. I guess Azure routing is prioritized here. I'm sure the route is not effective as I used it on a different subnet where I deployed a VM.
Is there any way I can use that Service Endpoint for my internal traffic only so it's not used when it goes to an Azure hosted API or I need to switch to a different approach like Private Endpoints or an ASE?
I am unsure what you're looking for but if you want to explicitly define routes you should try using app services setting "WEBSITE_VNET_ROUTE_ALL" = 1 which overrides the default precedence of routing and makes sure that every outbound call follows the route defined inside route table of subnet.
Use the following steps to add the WEBSITE_VNET_ROUTE_ALL setting in your app:
Go to the Configuration UI in your app portal. Select New application setting.
Enter WEBSITE_VNET_ROUTE_ALL in the Name box, and enter 1 in the Value box.
When WEBSITE_VNET_ROUTE_ALL is set to 1, outbound traffic is still sent from the addresses that are listed in your app properties, unless you provide routes that direct the traffic elsewhere.
We've been able to ask the 3rd party to disable blocking rules. It turns out they had a rule that blocked this specific traffic.
I already tried changing that setting, but didn't try putting a route table on it. However, it'd make no difference as I can't define a list of allowed outbound IPs belonging to Azure since we have no static IP to call.
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 have Azure APIM setup and deployed few apis into the apim instance using the azure devops pipelines. Later we wanted to Integrate the APIM with the Vnet, so assigned the apim instance to a Vnet, with dedicated subnet and also assigned NSG rules with recommended ports open as per the MSFT documentation. Also attached certificates and defined some custom domain names as well. But end of the day, I was not able to see and APIs nor create/deploy the to the instance again. Not exactly sure what the issue is?
This is one of the error I see everytime I get to the instance page.
**Failed to connect to management endpoint at apim-xxx-xxx-dev-xxx.management.azure-api.net:3443 for a service deployed in a virtual network. Make sure to follow guidance at https://aka.ms/apim-vnet-common-issues.**
Not sure whether this is the issue or something else....
Any help or information is highly appreciated.
In the internal VNet integration, the API Management gateway and developer portal are accessible only from within the virtual network via an internal load balancer. See the documentation here. In this type of deployment, you will have to use a VPN or express route connection to the Azure VNet.
As #wali mentioned in his answer, with the internal VNet integration, all APIM service endpoints can only be accessed from within the VNet.
If you want to expose backend APIs in a VNet to external users via APIM, you can consider using the external VNet integration.
If you want both the external and internal users to access the APIs via APIM, you can use the internal VNet integration with an Application Gateway, like what is mentioned in this document.
Trying to secure an API apps endpoint without Azure Active Directory. I have seen examples of NSG for securing SQL Server endpoints.
But with PaaS services (web apps / api apps/ logic apps) since they dont have VNETS I am bit confused as to how NSG will restrict traffic.
On Api app blade I see a "Networking" option and clicking that takes me into setting up VNET integration. When I click VNet setup starts gateway setup and configuration.
Has anyone done something similar where they secure backend api services using NSG and not API Gateway or AAD authentication.
Thanks !!
If you integrate the app service with a vnet, you can use NSGs to restrict the traffic, but only for the traffic connecting via the private network. vnet integration works with a vpn connection, hence the required deployment of a gateway on the vnet.
In this setup, the api app will still be accessible on the internet and that traffic will not be affected by the NSG, since it does not touch the vnet.
If you want to secure incoming traffic based on network origin you could implement that in application, but I would recommend against relying solely on that for security.