Outbound IP Registration to Azure SQL Using Azure Functions

As Azure SQL Database is PaaS, it has its own firewall settings. Due to its white-listed nature, only traffic from registered IP addresses is allowed to access to the server instance. Of course, there is an option that the server allows all Azure resources to access to the server. However, this is not secure because there are chances that some malicious attacks come from other Azure resources. Therefore, registering only outbound IP addresses assigned to other Azure resources like Azure Web App instances is strongly recommended.

Interestingly, according to this article, those outbound IP addresses, assigned to a specific Azure Web App instance, can change from time to time when the app instance is restarted or scaling happens. If those outbound IP addresses are updated, there is no way to let the Azure SQL Database server instance know unless manually updating them. I expected that Azure Event Grid would support this scenario, but at the time of this writing, apparently it’s not yet possible. However, there is still a workaround, if we use Azure Functions. In this post, I’m going to show how to update the firewall rules on an Azure SQL Database instance, using Azure Functions and Azure Fluent SDK.

Why Fluent SDK?

There is the Azure SDK library and Fluent SDK used to be a part of it. From the functionality point of view both are the same as each other. However, Fluent SDK offers more succinct way of handling Azure resources, and provides better code readability. For example, this is how to get authenticated and authorised to access to Azure resources:

Can you see how the code looks like? It looks dead simple, yeah? With this Fluent SDK, let’s move on.

The sample code used in this post can be found here.

Building an HTTP Trigger

If I can draw a user story reflecting this scenario, it would be:

  • AS a DevOps engineer,
  • GIVEN the name of Azure Resource Group,
  • I WANT to retrieve all outbound IP addresses from Azure Web App instances and all firewall rules registered to Azure SQL Databases, from the resource group,
  • SO THAT new IP addresses are registered to the firewall rules, as well as unused ones are deleted from the firewall rule.

First of all, for local debugging purpose, it’s always a good idea to start from an HTTP trigger. Let’s create a simple HTTP trigger function like:

This is just a scaffolded function so it does nothing with Azure resources but leave logs onto the console. Let’s put the basic authentication logic using Fluent SDK.

There are a few spots noticeable.

  1. Azure credentials are handled by SdkContext and Fluent API.
  2. Azure context is handled by Azure and Fluent API.
  3. All environment variables are converted to Config, a strongly-typed object.

The Config is a static instance that retrieves environment variables. You can still use ConfigurationManager.AppSettings["KEY"] for it, but the ConfigurationManage won’t be a good idea when Azure Functions move forward to .NET Standard. So, it’s much safer to use Environment.GetEnvironmentVariable("KEY"). Of course, this Config class and its properties might not need the static modifier, if you consider dependency injection. For the convenience sake, I’m sticking on the static nature, for now. Here’s the code:

Now, we need to get outbound IP addresses from web apps in a given resource group. Between the two log lines put several lines of code to retrieve all web app instances then all outbound IP addresses are fetched from there.

Those IP addresses need to be registered to firewall settings on each Azure SQL Database instance. If there are discrepancies between outbound IP addresses and registered IP addresses, all unnecessary IPs should be removed from the firewall rules and only newly updated IP addresses should be added to the rule. Let’s finish up the function code. Once all Azure SQL Database instances are populated, code loops through them. In the loop, all registered IP addresses are fetched and compared to the outbound IPs so that we know which IP addresses are to be removed and inserted.

Yeah, the coding part is done. Now, let’s run this on our local machine. The database instance has the following firewall rules – to allow all internal IPs from Azure resources (pointed by red arrow), one web app outbound IP (13.x.x.x) and one public IP (115.x.x.x) from my laptop.

Punch the F5 key and send an HTTP request through Postman. The function has run smoothly. Now we’re expecting all the Azure internal IP addresses will be removed and my public IP will be removed, but the existing web app IP will remain.

Go back to the Azure Portal and check the firewall settings. As we expected, all internal Azure IP addresses have been blocked (pointed by red arrow), my public IP has been removed, and other outbound IPs have been registered.

Unfortunately, there is no SDK ready for Azure Database for MySQL at the time of this writing. Instead, in order to apply this approach for it, we should use REST API to register outbound IP addresses.

Converting to a Timer Trigger

Once you confirm this works fine, you can simply copy and paste all the code bits into a timer trigger function so that this is triggered in a scheduled manner. The following code snippet says the timer function is triggered once a day at midnight in UTC.

So far, we have walked through how to check Azure Web App instances’ outbound IP addresses regularly and register them into the firewall rules of Azure SQL Database instance. As I stated above, once Azure Event Grid is applied to Azure Web App, this would be much easier.

Azure Functions with IoC Container

I’ve been talking about managing dependencies and unit testing in Azure Functions quite a few times in those articles:

Throughout my articles, the service locator pattern always took the centre of dependency management. The combination of Common Service Locator and Autofac certainly convinced me this would be the only way to handle dependencies for Azure Functions.

A few weeks back, I was asked to take a coding test before being engaged with a client. The topic was simple – given a JSON payload as a source of truth, I need to build an application to process the payload to display an instructed result. I, of course, decided to use Azure Functions to fulfill their requirements. Because the test itself was pretty straight forward, it could be done within a couple of hours with full of spaghetti code. However, they also wanted a sort of over-engineering including dependency injections, SOLID principles, unit testing, etc.

So, I started writing an Azure Functions application for it. As soon as I started, I realised that:

“Why can’t I upgrade my Autofac version? Is it because of the common service locator locks-in the Autofac version?”

This means that Azure Functions doesn’t yet support assembly binding redirects out-of-the-box. Apparently, it’s possible for libraries used internally. However, this is not applied to my case, if my Azure Functions app has dependencies that need binding redirects. Even though, there is an workaround for this concern, I was reluctant using this approach for Autofac.

What if I can use Autofac directly, without relying on Common Service Locator? Can I do this? It would be worth trying, yeah? Let’s move on.

Here’s my coding test repository as an example.

No More ServiceLocatorBuilder

In my previous post, I introduced ServiceLocatorBuilder for Autofac integration like:

This was called within FunctionFactory like:

It seemed to be redundant. I wasn’t happy about that, but justified myself this would be the only way to do it. Now this is the time to rewrite. Let’s do it.

New FunctionFactory

In the constructor of the new FunctionFactory class, instantiate the Autofac.IContainer instance directly from Autofac.ContainerBuilder.ContainerBuilder instance. Then, within the Create<TFunction>() method, the given type of function instance is resolved directly from the Autofac.IContainer instance. Here’s the code.

HttpTrigger with FunctionFactory

The basic usage is the same as the previous version of FunctionFactory. Simply create an instance and use it within the function method.

With this approach, you don’t need to use service locator pattern any longer for your dependency management. Hope this helps.


Finally, the new website has now launched!

When my Azure Subscription was about to expire, I was unable to backup blog posts for migration, which was shame. Eventually, I lost the old DevKimchi blog. Fortunately, I had a backup of posts themselves so managed to publish them using GitHub pages. There are still some images missing, though.

My initial plan with this renewed blog was:

  1. To restore all the blog posts from the GitHub pages, and
  2. To run this one as if nothing happened.

However, life was not that easy. The restore process didn’t work very well. Therefore, Plan B was executed, which was:

  1. To keep the existing GitHub pages as is, with a different domain name,, and
  2. To run this new one as a sort of Reboot.

Now, you can see my old blog posts through and this will be filled with new posts.

Stay tuned!

Copyright © 2017 DevKimchi

Theme by Anders NorenUp ↑