Scenario: I have Pay-As-You-Go instance of Azure API Management created. In that, as APIs, I have imported Azure Functions App. Azure Functions app is on Consumption Plan as well. These azure functions are calling some external APIs and getting data. I return data as is from these functions.
Issue: To get data from external APIs, I need to get my IP address whitelisted.
My calling pattern is APIM => Azure Function => External API. I am hitting APIM endpoint from my UI to get data. I have not exposed azure functions endpoint to UI.
Issue is what IP should be whitelisted to get the data ?
Options Tried:
I got the APIM virtual address(public) whitelisted, but that didn't work.
I added logs to my each function to log outbound IP address (using ipconfig.me). This is giving me different IP address then that of APIM public IP.
My confusion is, if I have imported these functions to APIM, then my outbound IP address should be of APIM and not of functions, right ? or my understanding is wrong here ?
It will be really helpful if someone can help with this scenario.
We need to get our IP whitelisted so that we can get data. For that changes to infra can be done, even if we need to switch to premium plans.
In your case APIM works as a gateway to your system, so you would use outbound IP address for APIM for IP restrictions configured on Azure Functions level. This would secure access to Functions and limit it to only APIM.
As you need to secure External API, which is accessed via Azure Functions, you need to check outbound IP for your App Service Plan(whether it's Consumption or not). The scenario you were trying would work only if outbound traffic is sent via some kind of gateway (see - https://learn.microsoft.com/en-us/azure/azure-functions/functions-how-to-use-nat-gateway)
Without a gateway, outbound IP can be checked with the following commands:
az functionapp show --resource-group <GROUP_NAME> --name <APP_NAME> --query outboundIpAddresses --output tsv
az functionapp show --resource-group <GROUP_NAME> --name <APP_NAME> --query possibleOutboundIpAddresses --output tsv
Related
Firstly, I integrate VNET with Azure App Service
In order to route traffic to VNet, I add WEBSITE_VNET_ROUTE_ALL with value 1 in App service settings.
I created NATgateway and attached it to the subnet.
I also created a route and attached it to the subnet in that route, I gave the address prefix as VNET address space and for the Next hop type I selected virtual appliance and in Next hop address I add NAT gateway public IP.
Note: I used the below link for reference:
https://sakaldeep.com.np/1159/azure-nat-gateway-and-web-app-vnet-integration-to-get-static-outbound-ip
after doing all above steps and I checked with below command I didn't get NAT gateway IP as result
az webapp show --resource-group <group_name> --name <app_name> --query outboundIpAddresses --output tsv
Azure App Service is a multi-tenant service. All App Service plans in the same deployment unit, and app instances that run in them, share the same set of virtual IP addresses. When you run
az webapp show --resource-group <group_name> --name <app_name> --query outboundIpAddresses --output tsv
you just get the Outbound IP Addresses Properties of your web app. You can find all possible outbound IP addresses for your app, regardless of pricing tiers, click Properties in your app's left-hand navigation. They are listed in the Additional Outbound IP Addresses field. The above outbound IP addresses will not change.
But if you send a request from your web app within a VNet over the internet, you should find the NAT gateway IP as the source.
For example, you could try to find the public IP from SSH (Linux app service) with
the command.
curl ipinfo.io/ip
I am trying to solve a problem. I have to access APIs that are hosted on my on premises server (on-prem) from Azure hosted Web API.
The problem is that my on-prem server only allows white listed IPs. I know we can get outbound IPs from our Web App (Azure hosted). But I am not sure whether they are static or will change based on scaling.
Another Solution is to create VNET and add that Web app into that VNET. But I would like someone to suggest better solutions.
There are couple of choices you have.
First, you can have a look at the possibleOutboundIpAddress of your App Service and whitelist this IPs. This however also opens up the door for IPs not really in use by your App Service.
az webapp show --resource-group <group_name> --name <app_name> --query possibleOutboundIpAddresses --output tsv
Secondly, you can put a NAT Gateway in-front of your App Service. This however requires an App Service Plan that supports virtual network integration.
Configure regional virtual network integration from within your app service.
Force all outbound traffic originating from that app to travel through the virtual network. This is done by setting WEBSITE_VNET_ROUTE_ALL=1 property in your web app configuration
Create a public IP address.
Add a NAT gateway, attach it to the subnet that contains the app service and make use of the public IP created in step 3.
If you would also like to use a static inbound IP you can find more information here
The outbound IPs for Azure App service are generally static and will not change on scaling. There are normally 4 outbound IPs and they only change if you change the SKU or there is a need at MS end to increase the capacity of their data center (rare or may never happen in near future).
I would recommend creating a VNET as that is more secure than whitelisting IPs at your on prem service. But if you want to want list the outbound IPs, I would recommend creating a wrapper for your on prem APIs in Azure and whitelist IPs for these in your on prem firewall. This will ensure that you don't have to whitelist every time you want to create an API in Azure that needs to access on prem APIs.
Unfortunately there is no straight forward way to do this in Azure for App Services, I also had this issue recently.
The only solution (for now anyway) is to add the list of outbound IPs of the App Service to your allow rules.
Just be careful with scaling between the tiers because it will change the outbound IP addresses. (https://learn.microsoft.com/en-us/azure/app-service/overview-inbound-outbound-ips#when-outbound-ips-change)
The simplest way would be to use an Azure VM with a static public IP which is used for both inbound and outbound.
Sam Cogan has a good blog post where he does go through a couple of options.
(https://samcogan.com/obtaining-a-static-outbound-ip-from-an-azure-virtual-network/)
A hybrid connection might be a solution https://learn.microsoft.com/en-us/azure/app-service/app-service-hybrid-connections? I think they are designed for accessing on premise services.
I am currently working with a client that requires access to all Azure resource locking down as much as possible and I am having problems with the Storage Account that is utilised by our Azure Functions.
With the Firewalls and Virtual Networks blade in portal set to "All Networks" I am able to deploy to the Function App and it runs without issue.
However once I enable the access restriction by checking "Selected Networks"no matter what virtual network subnets I enter or IP Addresses I can not get the communication to work
I have entered the Outbound IP Addresses of our Consumption based Function App and also check that the additional IP Addresses from the Powershell and all have been added to the whitelist. I have also added all the CIDR IP ranges of the local Azure datacenter but again it does not work.
The problem we have is that once the access restrictions have been put into place we are unable to deploy to the Function App and the app no longer runs. Is this scenario supported and what is the mechanism for tying down access to the Storage Account so that only the Function App can utilise it.
As far as I know, you have two options to restrict access to your storage account from your function app or web app.
Whitelist the outboundIpAddresses and possibleOutboundIpAddresses of the function app in the firewall of the storage account. However, it does not work if the Azure function app and Azure storage located in the same region refer to Sam's answer.
when you hit the storage account from your function, because they are
in the same region as each other, all the traffic goes over the
internal Azure network on internal IP's, not the public IPs listed in
the web app, and so is not allowed over the firewall.
If your resources were in different regions, you could use the network section of function app to allow function app to access resources in a VNet, then enable service endpoint for Microsoft.Storage in this app integration subnet. But you need Azure Functions Premium plan referring to this tutorial: integrate Functions with an Azure virtual network.
Sometimes, the deployment order for networking is important. In this case, you will deploy the followings:
Firstly, you could deploy new VNet integration with an unused subnet. After the VNet Integration is completed and the function app is restarted, you could enable service endpoint for this subnet. In the end, you could add the subnet in the firewall of the storage account.
Note that the new version is in Preview, currently. You could also check these characteristics and get more references from this thread.
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
I am working on a WebJob that periodically retrieves information from an API on a remote server.
In order to be able to access the API, my IP address must be whitelisted, but I am not sure how to achieve that for a WebJob.
So my question is: how do I configure a static outgoing IP through which my WebJob can access the internet?
(Assuming the WebJob is deployed to an App Service Plan, not a VM)
You already have a good answer from #junnas above.
Just want to add that there is a way to find out all possible IP’s that your app could use.
Here’s a link to MS documentation that covers your question in detail-
https://learn.microsoft.com/en-us/azure/app-service/app-service-ip-addresses#find-outbound-ips
You can find the set of all possible outbound IP addresses your app can use, regardless of pricing tiers, by looking for the possibleOutboundIPAddresses property.
az webapp show --resource-group <group_name> --name <app_name> --query possibleOutboundIpAddresses --output tsv
An App Service has a set of outgoing IP addresses which you can find from its Properties:
It uses one of them at random for outbound communication and you cannot decide which.
My suggestion, whitelist all of them.
Just beware though, those addresses can change, though they don't change often.