IP Address white-listing for Azure Function running under Consumption Plan

[niravbhalodiya]

Hi,

I have Azure Function App running under dynamic consumption based plan. Inside my function app, I have functions which communicate with the MS SQL server database which is located at AWS windows VM(EC2 Instance).

As we are running under dynamic consumption plan, we do note have a specific/static set of IP address to white-list on MS SQL DB server. So as per Microsoft azure recommendation, we have to white-list the whole IP ranges of the data-center of my Azure function app hosting location.

But, In AWS we have limit to add number of inbound security rules, which is less than the number of IP address ranges we have available for Azure East US region data-center.

Is there anyway we can identify the IP addresses my Azure function will utilize for outbound connection ?

If No, than how to identify the data-center IP address ranges to white-list for the Azure functions ? It is not possible to white-list all the IP Address ranges of East US data-center( Having more than 400 subnet IP addresses)

Also If I only white-list the outbound IP addresses of all the Scale Units of East US data-center instead of whole data-center IP subnet ranges will work for SQL connection ?

[mamaso]

Unfortunately we can't identify the IP address ranges for your function more specifically than the datacenter IP addresses.

This article applies to azure functions as well: https://blogs.msdn.microsoft.com/waws/2017/02/01/how-do-i-determine-the-outbound-ip-addresses-of-my-azure-app-service/

[JasonBSteele]

I have had to use a third party service (https://www.quotaguard.com) to provide a proxy that can be whitelisted. This is far from ideal, it would be great if this feature were available in Azure.

[jonfinerty]

I also have a use case where I need an Azure function with a known ip address (to be whitelisted), and it's looking like the only way we can work around it is either we use a proxy like above or a different fundamental technology.

[jbinder]

@mamaso So it isn't safe to use the OutboundIpAddresses as suggested in the article? For Azure Functions those can be found in the Azure Resource Explorer: https://blogs.msdn.microsoft.com/benjaminperkins/2016/03/02/how-to-find-you-outgoing-azure-app-service-ip-address/

[youngcm2]

@jbinder What did you end up using? @mamaso? Can you use the OutboundIpAddresses listed in ResourceExplorer?

[jbinder]

@youngcm2 I did not find a better approach than using OutboundIpAddresses / PossibleOutboundIpAddresses and rechecking those IPs when scaling etc. the app. So far there have been no issues with that.

[praneetloke]

@jbinder have you had any issues with using that mechanism with a Dynamic consumption plan?

[jbinder]

@praneetloke No!

[Gaspa79]

I am currently validating thru code and it's disgusting.

I'd like this option as well =)

[tahirh]

@jbinder I am running into a similar problem. I have a JS BlobTrigger defined in function app with dynamic plan. The blob storage is under a firewall; I have added the function apps outbound ip addresses as a whitelist. But still the JS BlobTrigger doesn't fire. I have used PythonSDK too to connect to the blob storage from function app using account name and key. Here too, I get an authentication error.

Any ideas?

[jbinder]

@tahirh I don't have experience with that, but it sounds like it might be unrelated. Did you ensure it is the fault of the firewall indeed, e.g. by disabling it?

[tahirh]

@jbinder When I disable the firewall I can connect to the blob storage just fine with no problems at all. I assume now that it is turning on of the firewall which causes the problem.

[praneetloke]

@tahirh I don't know much about the blob trigger but, from the sound of it, it sounds like the blob storage calls the function app, like a webhook url or something? So, you may have to whitelist your function app's outboundIpAddresses as the "outbound" address in your firewall since the function app is not calling into your storage. Not sure if that is what you did.

[tahirh]

@praneetloke Well I did something like this. I took the outboundIpAddresses from function app given in the properties blade. I added these to the Firewall and Network blade for the blob storage account where these IPs are actually inbound if this is what you meant.

[praneetloke]

@tahirh yeah I think that's your problem. Your firewall should somehow be allowed to communicate with those IPs. What you have done now is allow the function app to communicate with your blob storage. I'd suggest opening a support ticket with MS. I am sure they can help you out.

[tahirh]

@praneetloke Thanks a lot! I did already. When I have an answer I will put it here ...

[HMoen]

@praneetloke, any response from MS regarding this? From my experience, the outbound ip address won't work since it seems AF uses an internal ip in the form of 10.x.x.x (keeps changing as a new instance spins up) to access storage. I tried adding an internal ip range to the firewall, but that's not allowed.

You can see this internal ip address with the following: var clientIp = ((HttpContextWrapper)request.Properties["MS_HttpContext"]).Request.UserHostAddress; logger.LogWarning($"Internal IP: {clientIp}");

[praneetloke]

@HMoen it wasn't me who had the problem with the storage account. It was @tahirh.

[joshnoe]

@jbinder the article you linked to had it's videos taken down, FYI

[murali2020kris]

@praneetloke @HMoen I have the same problem. I opened a support ticket with MSFT Did you get any updates from them?

[HMoen]

@murali2020kris, I ended moving to an app service plan where the issue persists with storage on a VNet. I have an open MSFT support ticket pending. They had to scale it up to another department. I will post back with their response.

[tahirh]

@HMoen Ran into the same problems. Also contacted MSFT and they suggested adding some data center ips which worked for a while but then all of a sudden stopped working. We finally resorted to using ASEs and deployed function apps there.

[murali2020kris]

Is it acceptable though to add ASE just to implement simple firewall security. ASE is relatively expensive and big hassle to roll out and maintain. Shouldn't security come as part of App service price.

[HMoen]

@murali2020kris, even with an ASE, AF is still blocked by the storage firewall using a VNet or the assigned public IPs of the AF. Reason is that both storage and ASE are in same region thus AF will use rotating internal IPs to access storage which “as of now” is not supported by storage firewall. They suggested creating the storage container in another region in order for storage firewall to detect public IPs of the AF, which is not ideal due to unnecessary latency added.

[haiquan]

I did some test, and maybe find the reason. When the function and storage are hosted in the same region (such as US West), the function will not use the outbound IP to access Storage, seems like it use the private IP to access Storage. When I create a storage in a different region (such as US East), then evrything works well. The function in the US West can access the storage in the US East.

[murali2020kris]

This is the response from MSFT "Current behavior is By Design. Public App Service, including Azure Functions (which runs on top of App Service infra) does not support calling Azure Storage that have service endpoints available. Long-term there is engineering work underway to provide an avenue for apps running in public App Service, and eventually Functions as well, to work with Service Endpoint secured Azure Storage accounts. But no ETA at this time."

[jbinder]

@joshnoe Ah right, the OutboundIpAddresses/PossibleOutboundIpAddresses can be found on https://resources.azure.com/ as properties in subscriptions/[subscription]/resourceGroups/[resourceGroup]/providers/Microsoft.Web/sites/[site].

[alexkarcher-msft]

Hello everyone, at the moment you can enable this by deploying your Function App into an App Service Environment, which will give you one static outbound IP. We are working on an offering to enable this in a serverless plan before the end of the year.

[sgalles]

If I get this right this is now solved for the premium plan only, correct ? ref : https://azure.microsoft.com/en-us/blog/announcing-the-azure-functions-premium-plan-for-enterprise-serverless-workloads/

[alexkarcher-msft]

Nope. You will still be routed through a number of shared outbound IPs. Using an ASE is still the only way to achieve this functionality.

I'll update this doc when we have a different answer: https://docs.microsoft.com/en-us/azure/azure-functions/functions-networking-faq#how-do-i-set-a-static-ip-in-functions

[boomertech]

I have a function app service that is connected to my VNET through VNet Integration. The problem I have is that if I put any IP restriction on the function app to secure it it breaks because it cant communicate with the storage account. It works if I dont secure the storage account but then that is even worse. How can I restrict access to only the networks I want on both and have the two service communicate. If I had an IP to whitelist that would be great, but, even if you whitelist all outgoing IPs for the function app through the storage account firewall it still doesnt work with an IP restriction in place. So, all someone has to do is find the DNS name of my function app functionname.azurewebsites.net and there can be a breach. Has anyone encountered this before?

[HMoen]

@boomertech, put your app service and storage account in different regions. If they're in the same region, the function app will access the storage account using internal IPs which you can't whitelist in the storage account's firewall.

Example:

• App Service: East US
• Storage Account: East US 2 (add function app outgoing IPs to firewall)

I'd recommend adding an API Management resource to your architecture (same region as your function app) and putting it in front of your function app. APIM will provide you with a static IP that you can use in your function app's firewall.

This solution is not ideal for secure storage access since the function app outgoing IPs are shared, but at least your function app will be locked down to only the APIM resource.

[boomertech]

Thanks for the input but you cant do VNet integration without the app being in the same region. I need this capability so that the function app can use a subnet with a Storage service endpoint.

[NoelStephens]

One additional solution is to make your Azure Function process JSON-serialized class objects. When your app/client sends a request/data to the function, it would send a serialized class that would include the IPAddress of the incoming connection.
You can find several posts on obtaining the client side of the equation by searching for "C# get public IP address". Here is a good thread with several options: https://stackoverflow.com/questions/3253701/get-public-external-ip-address

Once you have the public IP, client side, then you can populate the "azure function request serializable class" that can include the IP address of the incoming connection prior to sending the request to the Azure function. You can also incorporate various encryption methods into the serialization process in order to assure that it is "more secure".

Just an additional "alternate solution" that can provide additional "internal checking of incoming requests".

[CReich02]

Is using an ASE still the only solution for this? What about setting up a proxy server on a VM and routing traffic through that?

[jjxtra]

I've added my function app as a contributor to the storage resource group. Shouldn't this be enough to allow it access regardless of firewall?

[jschwellnus92]

Wow what a joke this is. A Function app requires a storage account to operate, yet that storage account cannot be locked down unless you run your Function in an ASE ($$$), or unless the Function is in a seperate DC and you whitelist the outbound IP's.

[Andreas717]

This is really a blocker for me. The consumption plan is ment for low cost szenarios and we really just want to call onpremise services. Could you please provide a new timeline for the implementation?

[jjxtra]

I gave up trying to secure my azure storage using the firewall and instead just rotate keys every month. Seems like it would be such an easy thing to give the storage permissions to be called from your azure functions only...

[boomertech]

You will need to use NSGs to secure storage.

On Mon, Mar 30, 2020, 4:00 PM Jeff Johnson notifications@github.com wrote:

I gave up trying to secure my storage using the firewall and instead just rotate keys every month

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Azure/Azure-Functions/issues/464#issuecomment-606214087, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHIDHH6BUV2SSUNEFIUJHM3RKD27BANCNFSM4DYWVKEA .

[princelundgren]

@alexkarcher-msft is there any update on the progress of this issue? When will this be prioritized?

I image this feature is a big blocker for a lot of businesses deciding to go over to a serverless solution in Azure and should be highly prioritized. We have microservices running Azure Functions consumption plan which we can't in an easy way integrate with external services that require IP whitelisting, because having a static public IP address for all microservices running Azure Functions is still not possible in Azure.

AWS is way ahead Azure in this. They have a consumption plan which can easily be connected to a virtual network via few clicks in the Function. This easily enables a single static outbound and inbound public IP address for all microservices in that virtual network.

UPDATE: Check this page for how many others are saying this is a blocker for their businesses... https://feedback.azure.com/forums/169385-web-apps/suggestions/16790656-add-static-ip-address-for-outbound-traffic-without

[boomertech]

Have you done a vnet integration with your function app? You can also create two storage accounts, 1 for application data that you use the storage account firewall for and the other that you use to store the function app configuration data.

On Sun, May 10, 2020, 6:16 AM Prince notifications@github.com wrote:

@alexkarcher-msft https://github.com/alexkarcher-msft is there any update on the progress of this issue? When will this be prioritized?

I image this feature is a big blocker for a lot of businesses deciding to go over to a serverless solution in Azure and should be highly prioritized. We have microservices running Azure Functions consumption plan which we can't in an easy way integrate with external services that require IP whitelisting, because having a static public IP address for all microservices running Azure Functions is still not possible in Azure.

AWS is way ahead Azure in this. They have a consumption plan which can easily be connected to a virtual network via few clicks in the Function. This easily enables a single static outbound and inbound public IP address for all microservices in that virtual network.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Azure/Azure-Functions/issues/464#issuecomment-626304448, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHIDHHZEJHQRUD4WUBANM6DRQZ5JDANCNFSM4DYWVKEA .

[princelundgren]

@boomertech VNET integration with Consumption Plan is still not possible from what I understand from this issue still being open. Also here is the documentation stating that you require a Premium plan: https://docs.microsoft.com/en-gb/azure/azure-functions/functions-create-vnet

I'm not sure what you mean with the proposed solution about the storage accounts,. I have use-cases for having static outbound IPs for Azure Functions which this issue originally is about. Like many other businesses with security requirements, we need to have static outbound IPs in order to communicate with other internal microservices which are hosted by other teams, and also other external businesses or services we integrate to. Having one IP for all microservices would be a scalable solution for a growing business which has evergrowing solutions. VNET integration would solve this but as I understand its currently not possible with consumption plan.

[boomertech]

@prince what is you end goal? Do you have VPNs configured to on prem? Azures networking is definitely not as straight forward as AWS. In AWS you put resources IN your VPC. In azure you ATTACH to the vnet. This was an important realization for me to be able to secure our environment. I am not questioning your expertise but it took me over a year of working with Azure to get them to implement a way to whitelist services in NSGs.

I work for a company that specializes in test development and I had to figure out how to secure all resources enough to be comfortable storing data in azure. This took a mixture of vnet integration, NSGs, VPNs, IP restrictions and other little adjustments. Consumption based services are designed to scale on thier own by Microsoft's scaling algos and best used for really small publicly available services. Honestly, I would use the ASP if you are both looking for security and cost effectiveness. Any other solution for a secure environment is at a minimum 1k a month per environment assuming you have int, Dev, tst, uat, prd that's 60 grand a year base, and you still have to pay for the services you use on top of that.

On Sun, May 10, 2020, 9:34 AM Prince notifications@github.com wrote:

@boomertech https://github.com/boomertech VNET integration with Consumption Plan is still not possible from what I understand from this issue still being open. Also here is the documentation stating that you require a Premium plan: https://docs.microsoft.com/en-gb/azure/azure-functions/functions-create-vnet

I'm not sure what you mean with the proposed solution about the storage accounts,. I have use-cases for having static outbound IPs for Azure Functions which this issue originally is about. Like many other businesses with security requirements, we need to have static outbound IPs in order to communicate with other internal microservices which are hosted by other teams, and also other external businesses or services we integrate to. Having one IP for all microservices would be a scalable solution for a growing business which has evergrowing solutions. VNET integration would solve this but as I understand its currently not possible with consumption plan.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Azure/Azure-Functions/issues/464#issuecomment-626328917, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHIDHH2QD2CPJ3HN7KSLQX3RQ2UNFANCNFSM4DYWVKEA .

[princelundgren]

@boomertech thanks for clarifying the difference between VPC and VNET as it was not clear to me. I have been working with AWS for a while so I assumed as a Virtual Network in Azure meant that you would have the ability to use their Virtual Network service to put resources in this Virtual Network and control traffic to and from this Virtual Network and use a static IP address, if this is not what Microsoft has in mind with VNET then I need to find another solution.

The biggest selling point of serverless solutions are that you only pay for what you need, and it works great with a microservice architecture, and the only big problem I have here with Azure is how to setup a scalable secure solution for these microservices.

I can give an example of my endgoal of using a static IP, example is to be able to integrate with a sister company using their API, and they are requesting the IP addresses to our environments so they can give us access to their API. We then want the ability to give a sister company our static IP addresses to our dev, staging and production environments that they can add them to their whitelist, so that they can allow our environments to use their REST APIs. Do you know of a best-practice solution in Azure for this scenario?

The scenario above was a common scenario in a large global company I worked with(and we did work solely with serverless microservices solutions in AWS). Right now I'm working with building a new serverless microservice solution in Azure this time, for a business which possibly could have hundreds of integrations with other businesses(both partners and sister companies). There will be a point where one integration requires a public IP addresses for their whitelisting. So we'd like to have a solution which is easy to work with.

[boomertech]

@prince so to restrict traffic to only your sister connections I would whitelist their public IP block/range and then give them the URL and access keys to allow them to securly make the programmatic REST calls. If that it too much, meaning they have thousands of pub IPs, then I would utilize CORS on the function app to only allow requests from their domains to pass through, also using the access keys for an added later of security. Or you could do both.

On Sun, May 10, 2020, 10:57 AM Prince notifications@github.com wrote:

@boomertech https://github.com/boomertech thanks for clarifying the difference between VPC and VNET as it was not clear to me. I have been working with AWS for a while so I assumed as a Virtual Network in Azure meant that you would have the ability to use their Virtual Network service to put resources in this Virtual Network and control traffic to and from this Virtual Network and use a static IP address, if this is not what Microsoft has in mind with VNET then I need to find another solution.

The biggest selling point of serverless solutions are that you only pay for what you need, and it works great with a microservice architecture, and the only big problem I have here with Azure is how to setup a scalable secure solution for these microservices.

I can give an example of my endgoal of using a static IP, example is to be able to integrate with a sister company using their API, and they are requesting the IP addresses to our environments so they can give us access to their API. We then want the ability to give a sister company our static IP addresses to our dev, staging and production environments that they can add them to their whitelist, so that they can allow our environments to use their REST APIs. Do you know of a best-practice solution in Azure for this scenario?

The scenario above was a common scenario in a large global company I worked with(and we did work solely with serverless microservices solutions in AWS). Right now I'm working with building a new serverless microservice solution in Azure this time, for a business which possibly could have hundreds of integrations with other businesses(both partners and sister companies). There will be a point where one integration requires a public IP addresses for their whitelisting. So we'd like to have a solution which is easy to work with.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Azure/Azure-Functions/issues/464#issuecomment-626340774, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHIDHHZJV5UBZ4GDTRWSMSTRQ26EVANCNFSM4DYWVKEA .

[princelundgren]

@boomertech thanks for answering but I need to solve it the other way around(my sister company has the API not me). I want to get data from my sister company by doing a request from my backend to my sister company API, and they require the IP addresses to my backend for their whitelist.

[boomertech]

@prince is your back end in Azure or on prem?

On Sun, May 10, 2020, 11:24 AM Prince notifications@github.com wrote:

@boomertech https://github.com/boomertech thanks for answering but I need to solve it the other way around(my sister company has the API not me). I want to get data from my sister company by doing a request from my backend to my sister company API, and they require the IP addresses to my backend for their whitelist.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Azure/Azure-Functions/issues/464#issuecomment-626344555, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHIDHH3NI7UJICEU6LLBRKDRQ3BLTANCNFSM4DYWVKEA .

[princelundgren]

@boomertech my backend is Cloud only in Azure(as microservices consisting of multiple Azure Function Apps each with consumption plan)

[boomertech]

@prince will your sister company only accept IP addresses?

On Sun, May 10, 2020, 11:31 AM Prince notifications@github.com wrote:

@boomertech https://github.com/boomertech my backend is Cloud only in Azure(as microservices consisting of multiple Azure Function Apps each with consumption plan)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Azure/Azure-Functions/issues/464#issuecomment-626345496, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHIDHH5HBRFK7GJ5Y4ASIDTRQ3CFPANCNFSM4DYWVKEA .